What is the NIST AI RMF? From AI governance principles to security evidence

AI governance often starts with policies, committees, and risk statements. The harder part is connecting those high-level decisions and documents to the systems actually running across the organization and finding answers to practical questions:

• Which applications use artificial intelligence? 
• Which models, frameworks, agents, APIs, and data stores do they depend on? 
• What can those systems access or change? 
• Have their exposed interfaces been tested? 
• Which findings represent real risk, and who is responsible for fixing them?

The NIST Artificial Intelligence Risk Management Framework provides a structure for answering those questions. Its four core functions – Govern, Map, Measure, and Manage – help organizations move from accountability and context to evidence, prioritization, and action.

Application security does not cover the entire framework, but it plays a central role in operationalizing security-related outcomes. AI systems are delivered through applications, APIs, software components, data pipelines, identity controls, and infrastructure. Weaknesses in those layers can undermine security, resilience, privacy, reliability, and safety even when the underlying model works as intended.

Invicti supports this part of the AI risk management process by helping organizations identify AI-related application components, discover exposed applications and APIs, test deployed systems, validate applicable vulnerabilities, and manage remediation.

The connection is simple:

NIST defines the AI risk management outcomes. AppSec supplies part of the technical evidence needed to achieve them.

Key takeaways

• The NIST AI Risk Management Framework, or AI RMF, is a voluntary framework for managing risks across the AI lifecycle. It is broader than cybersecurity and does not provide certification.
• Its four functions are Govern, Map, Measure, and Manage. Govern applies across the organization, while the other functions help teams assess and manage individual AI systems.
• AI governance requires operational evidence, including system inventories, technical context, test results, risk treatment decisions, and remediation records.
• Application security supports selected AI RMF outcomes by identifying AI-related components, mapping exposed applications and APIs, testing deployed systems, validating vulnerabilities, and tracking remediation.
• Invicti connects these activities through AI-BOM, application and API discovery, DAST, proof-based scanning, and application security posture management (ASPM).
• Model evaluation, fairness, privacy, legal review, safety engineering, and human oversight are separate concerns that require additional people, processes, and tools.

What is the NIST AI Risk Management Framework?

The NIST AI RMF is a voluntary framework for identifying, assessing, prioritizing, and managing risks associated with the design, development, deployment, and use of AI systems.

Published as NIST AI 100-1, the framework is sector-agnostic and use-case agnostic. Organizations can adapt it to their size, resources, objectives, and risk tolerance. It applies to the people and organizations that design, build, acquire, deploy, operate, or evaluate AI systems.

The framework provides a shared structure and vocabulary rather than a mandatory set of controls – it is not a law, regulation, certification scheme, prescriptive control checklist, or technical testing standard. It covers all areas of AI, not only high-profile generative AI technologies like large language models (LLMs). 

The flexibility makes the AI RMF widely applicable, but it also places responsibility on each organization to select appropriate policies, controls, measurements, testing methods, and evidence. This creates a practical gap between understanding the framework and using it.

Note: As of this writing, AI RMF 1.0 remains the current framework, but NIST is revising it. Organizations should always check the NIST AI Resource Center for updates when establishing or reviewing their programs. 

Where application security fits into the NIST AI RMF

The AI RMF covers risks that extend well beyond software security. It addresses model performance, human impacts, privacy, fairness, explainability, transparency, reliability, and safety.

In practice, AI capabilities commonly reach users and other systems through applications, APIs, and supporting software. A production AI implementation can include:

• Web and mobile applications
• Public and internal APIs
• Model providers
• Agent frameworks and tools
• Retrieval systems and vector databases
• Data stores and pipelines
• Identity and access controls
• Open source packages
• Cloud services and infrastructure

A weakness in any of these layers can affect several AI RMF outcomes at once.

For example, an insecure API could expose private prompts and responses. An injection vulnerability could let an attacker manipulate an AI-enabled workflow. Excessive agent permissions could turn misleading output into unauthorized action. And an undocumented AI package could leave governance teams unaware of an AI-related dependency that warrants investigation.

A mature application security program supports the framework by providing evidence across a connected workflow to let you:

1. See which AI-related systems and components exist
2. Understand where they are exposed and what they can access
3. Test running applications and APIs for relevant weaknesses
4. Validate and prioritize findings
5. Assign remediation and verify the result

As an application security platform vendor, Invicti supports this technical workflow through its AI-BOM, application and API discovery, DAST, proof-based scanning, and ASPM capabilities. These contribute evidence to the framework and support the broader governance program.

What does trustworthy AI mean?

NIST describes seven characteristics of trustworthy AI:

NIST treats validity and reliability as a foundation for the other characteristics, while accountability and transparency cut across all of them.

Improving individual characteristics may require tradeoffs. For example, increasing transparency may introduce privacy concerns, while simplifying a system for interpretability could affect performance. The framework does not decide these tradeoffs for the organization.

On the face of it, security is only one of the seven items, but an insecure AI-enabled application can undermine several characteristics at once. An attacker who is able to alter inputs, steal sensitive data, manipulate an agent, or exploit an API may affect reliability, privacy, safety, and accountability at the same time.

The four NIST AI RMF functions: Govern, Map, Measure, Manage

The operational core of the framework consists of four main functions. These are broken down into categories and subcategories that organizations can map to their own policies, processes, controls, and evidence.

The functions should be applied iteratively rather than treated as one-time compliance actions. Govern applies throughout the organization and lifecycle. Map, Measure, and Manage can then be applied to individual systems and revisited as technology, dependencies, uses, and risks change.

Govern: Establish ownership and visibility

The Govern function creates the organizational conditions needed to manage AI risk. It includes:

• Policies and procedures
• Roles and accountability
• Risk tolerance
• Legal and contractual requirements
• Staff training
• Documentation
• Third-party risk management
• Monitoring and review
• AI system inventories

Govern is a cross-cutting function, not a preliminary paperwork stage. NIST describes it as a continual requirement that enables the other functions. One especially practical subcategory is Govern 1.6:

Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.

An inventory is a prerequisite for meaningful governance. Organizations cannot assign ownership, apply policy, assess exposure, or monitor change when they do not know where AI is in use. 

A governance inventory should include business context such as purpose, owner, users, data, and risk classification. It also needs technical evidence about the components found inside applications. Invicti AI-BOM can contribute the technical evidence part by identifying and categorizing AI-related dependencies across an application portfolio. This may include machine learning frameworks, model providers, agentic libraries, retrieval technologies, vector databases, Model Context Protocol components, and embedded model files.

Practical question to ask: Do we know which applications and APIs use AI, what they depend on, and who owns them?

Practical output: An owned AI inventory, governance policy, and defined risk tolerance.

Map: Understand context and exposure

The Map function establishes the context around an individual AI system. Teams should consider:

• The intended purpose and expected benefits
• Users and affected stakeholders
• Data sources and flows
• Deployment environment
• Human oversight
• Third-party services
• Foreseeable misuse
• Potential impacts and harms
• Whether development or deployment should proceed

Mapping prevents organizations from assessing risk in isolation from context. For example, a chatbot that answers questions about public documentation presents a very different risk profile from an agent that can access customer records, call internal services, or modify cloud resources. The technology may be similar, but the exposure and consequences are not.

From an AppSec perspective, mapping should capture the technical boundaries of the system:

• Which application exposes the AI capability?
• Which APIs receive or return AI-related data?
• What authentication and authorization controls apply?
• Which data sources can the system query?
• What tools or downstream services can an agent call?
• Which third parties process data or generate output?
• Which outputs are passed into browsers, databases, shells, or other systems?

Application, API, technology, and dependency discovery can help teams establish this context. Features like AI-BOM can add AI-specific categorization that a generic dependency list may not provide.

Practical question to ask: How is the AI capability exposed, what can it access, and where are its trust boundaries?

Practical output: A documented system boundary, use context, trust boundaries, and go/no-go decision. 

Measure: Produce security evidence

The Measure function turns mapped risks into usable evidence. NIST uses the broad term “test, evaluation, verification, and validation” (TEVV) for the technical and nontechnical assessments that can take place throughout the AI lifecycle. Depending on the system, this TEVV work may include:

• Model performance testing
• Reliability and robustness evaluation
• Security testing
• Privacy assessment
• Bias analysis
• Safety testing
• Human factors evaluation
• Benchmarking
• Red teaming
• Monitoring for drift or unexpected behavior
• Independent review

The framework specifies desired outcomes but generally does not prescribe the exact testing methods or tools needed to achieve them. For example, it says organizations should measure security and resilience. It does not prescribe specific tools or methods for doing that – based on the framework alone, you won’t get a testing procedure for prompt injection, insecure output handling, excessive agent permissions, API authorization flaws, or conventional web vulnerabilities in an LLM-backed application.

AppSec practices and tools can provide part of that missing “how” for application and API security. For example, dynamic application security testing (DAST) examines running applications from the outside, using the same interfaces available to legitimate users and attackers. DAST provides the outside-in application view, while API security capabilities extend testing to the endpoints that connect models, data, services, and application functionality.

For applicable AI-enabled systems, automated testing may cover:

• Prompt injection
• Prompt leakage
• Insecure output handling
• Command injection
• LLM-driven server-side request forgery
• Unsafe tool interactions
• Model and response exposure
• Authentication and authorization weaknesses
• Traditional web application and API vulnerabilities

With its DAST and API security capabilities, the Invicti Platform can produce runtime evidence for the application security portion of Measure. Proof-based scanning can even safely confirm many vulnerabilities by demonstrating exploitability, giving teams stronger evidence for triage and remediation.

At the same time, it’s important to be clear about the scope of evidence provided by security testing. DAST can test a deployed application and its reachable interfaces, but you need other methods to determine whether the underlying model is fair, sufficiently explainable, statistically valid, or appropriate for a specific business decision.

Practical question to ask: What evidence shows that the deployed application and its APIs resist relevant attacks?

Practical output: A system-specific assessment plan, test results, limitations, and monitoring metrics. 

Manage: Prioritize risk and act

The Manage function is where evidence turns into decisions and action. It covers:

• Risk prioritization
• Selection of risk treatments
• Resource allocation
• Residual risk documentation
• Monitoring of deployed systems
• Response and recovery planning
• Third-party risk management
• System modification or decommissioning

Risk treatments may include mitigation, transfer, avoidance, or acceptance. The organization should document unresolved and accepted risk rather than assuming that treatment removes uncertainty.

For AppSec teams, the practical challenge for security management is maintaining an unbroken and efficient process chain from discovery through resolution:

1. Identify the system or component
2. Test the deployed application or API
3. Validate the finding where possible
4. Add business and asset context
5. Assign an accountable owner
6. Track remediation
7. Retest
8. Report the resulting posture

This becomes difficult when findings are scattered across DAST, static application security testing (SAST), software composition analysis (SCA), container scanning, cloud security, and other tools. 

AppSec platforms use application security posture management (ASPM) to centralize and correlate findings across security sources. Invicti ASPM helps teams deduplicate results, add application and business context, prioritize risk, route issues, enforce remediation policies, track service-level agreements, and report on application security posture. Invicti’s DAST-first approach can strengthen this process further by adding runtime evidence. When a static tool reports a theoretical weakness, dynamic testing may help establish whether it is actually reachable and exploitable in the running application.

Practical question to ask: Can we distinguish actionable risk from noise, assign it to the right team, and verify remediation?

Practical output: Prioritized treatments, accountable owners, residual-risk records, and retest status. 

How the framework functions work together

A practical AI RMF cycle looks like this:

• Govern defines expectations, accountability, inventory requirements, and risk tolerance.
• Map identifies what a system does, how it is exposed, and what could go wrong.
• Measure produces evidence about those risks.
• Manage prioritizes treatment and tracks the result.
• New information feeds back into governance, context mapping, and measurement.

This cycle should continue as models, prompts, application code, APIs, components, permissions, data sources, users, and deployment environments change.

Purely from an AppSec perspective, the same cycle can be expressed as:

• See what AI-related technology exists.
• Test the applications and APIs that expose it.
• Manage and verify remediation.

The same approach is the thread connecting AI-BOM, DAST, API security, proof-based scanning, and ASPM on the Invicti platform.

The NIST AI RMF is more than one document

The core framework is only one part of a broader set of NIST resources.

AI RMF Playbook

The AI RMF Playbook provides suggested actions for the framework’s individual categories and subcategories. It is the primary companion resource for teams looking for more practical implementation ideas. Like the framework, the Playbook is voluntary and designed to be adapted to each organization’s needs.

AI RMF profiles

Profiles adapt the framework to a specific use case, sector, system type, or organizational state. An organization can create:

• A current profile describing existing practices
• A target profile describing the desired state
• A gap analysis identifying prioritized improvements

For example, a target profile for customer-facing generative AI could require:

• A named business and technical owner
• An inventory of models and AI components
• Defined data access rules
• Authentication and authorization controls
• Application and API security testing
• Output validation
• Usage monitoring
• Incident response procedures
• Regular reassessment

Generative AI Profile

The NIST Generative Artificial Intelligence Profile supplements the core AI RMF with risks and recommended actions specific to generative AI. Relevant areas include:

• Confabulation
• Prompt injection
• Data privacy
• Harmful or misleading output
• Model and component provenance
• Intellectual property
• Third-party model risk
• Abuse and misuse
• Information security

Note that the profile is additive – organizations still use Govern, Map, Measure, and Manage, but apply them with generative AI risks in mind.

NIST also maintains roadmap and crosswalk resources that connect the AI RMF to related standards and frameworks. The core document is intended to remain a living resource that develops alongside technology and standards.

Is the NIST AI RMF mandatory?

The NIST AI RMF is a voluntary framework. Using it does not result in any official NIST certification, and the framework does not define a universal state of “AI RMF compliance.” Rather than claiming explicit compliance, organizations should use it to support:

• Internal governance
• Customer assurance
• Procurement reviews
• Vendor assessments
• Contractual requirements
• Regulatory preparation
• Alignment with other standards

ISO/IEC 42001 is often used as a complementary standard because it defines requirements for an AI management system and supports formal certification.

When discussing technology, the accurate wording is that a product supports selected AI RMF outcomes or contributes evidence to an AI RMF program. In practice, no single security tool can implement the complete framework.

How to implement the NIST AI RMF in practice

The AI RMF is flexible, but your implementation of it still needs some concrete outputs.

1. Assign ownership and build the inventory

Define organizational and system-level accountability. Create an AI inventory that records:

• System purpose
• Business and technical owners
• Models and providers
• AI frameworks and components
• Data sources
• APIs
• Deployment locations
• Access permissions
• Risk classification

Do not limit the inventory to approved AI products. Developers can introduce models, frameworks, agents, and AI services through ordinary application dependencies.

Capabilities like AI-BOM can help expose this technical layer, while governance teams add the ownership, purpose, impact, and policy context required for a complete inventory.

2. Map purpose, access, and potential impact

Document:

• What the system is intended to do
• Who uses it
• Who may be affected
• What data it processes
• Which systems it can access
• Which actions it can perform
• How humans supervise it
• What misuse is foreseeable
• What failure would mean

The result should be a defined system boundary and a reasoned decision about whether and how to proceed.

3. Select meaningful measurements

Choose assessment methods based on the risks identified during mapping. Security-related measurements may include:

• Application and API vulnerability status
• Authentication and authorization coverage
• Internet exposure
• Exploitability
• Sensitive data exposure
• Third-party component risk
• Prompt injection resistance
• Output handling
• Agent permissions
• Mean time to remediation
• Policy and service-level agreement compliance

Avoid relying on activity metrics alone – a high scan count or a large number of closed tickets does not prove that the organization has reduced its most important risks.

4. Prioritize, assign, and verify treatment

Combine technical evidence with business context. Prioritization should consider:

• Exploitability
• Exposure
• Data sensitivity
• Business criticality
• User impact
• System permissions
• Available mitigations
• Compensating controls
• Downstream dependencies

Every unresolved or accepted risk should have an accountable owner and a documented rationale. ASPM capabilities can help connect findings to applications, owners, policies, remediation workflows, and retesting.

5. Monitor change and update the target state

Reassess systems after changes to:

• Models or model versions
• System prompts
• Agent tools
• Application code
• APIs
• Data sources
• Permissions
• Dependencies
• Infrastructure
• Users or business purpose

Use current and target profiles to turn the gap between present practices and desired outcomes into a prioritized improvement plan.

What AI-specific application security adds

AI-enabled applications introduce new components and behaviors that are added on top of all the familiar software risks. Teams still need to address:

• Injection vulnerabilities
• Broken access control
• Authentication weaknesses
• Data exposure
• Insecure APIs
• Vulnerable components
• Server-side request forgery
• Configuration errors
• Unsafe data handling

In addition, they also need to account for AI-specific trust boundaries:

• Prompts and model responses
• External model providers
• Retrieval systems
• Vector databases
• Agentic frameworks
• Tools available to agents
• Model Context Protocol (MCP) servers and clients
• Outputs passed to downstream systems

This combination is why model-only evaluation is insufficient. Having a model behaving exactly as designed doesn’t guarantee security if the application that uses it exposes data, mishandles output, grants excessive permissions, or contains exploitable vulnerabilities. Any mature AI security program therefore needs both AI-specific evaluation and established AppSec practices.

How Invicti supports selected AI RMF outcomes

Together, these capabilities support a technical evidence flow:

1. AI-BOM helps show where AI-related components exist
2. Discovery identifies the applications and APIs that expose them
3. DAST and API security test deployed systems
4. Proof-based scanning helps distinguish confirmed vulnerabilities from uncertain findings
5. ASPM connects the evidence to prioritization, ownership, remediation, and reporting

This supports the inventory, technical security, and risk-management portions of an AI RMF program. Those still need to be accompanied by organizational governance, legal review, privacy assessment, model evaluation, fairness analysis, safety engineering, and human oversight.

Common NIST AI RMF implementation mistakes

• Using the framework like a universal checklist: The AI RMF supports risk-based decisions. Applying every subcategory without considering your system context can consume resources without improving outcomes.
• Treating a limited AI inventory of approved models as sufficient: AI can enter applications through libraries, frameworks, cloud services, agent tools, embedded models, and other dependencies. Procurement and inventory records provide only part of the picture.
• Focusing only on model behavior: A well-evaluated model can still operate inside an insecure application. Governance needs to cover the model and the wider system that exposes interfaces, processes data, and performs actions.
• Treating security as a one-time review: Applications, APIs, dependencies, configurations, models, and usage patterns can change frequently. Testing and monitoring need to continue after deployment.
• Measuring risk without managing it: Testing produces evidence for taking action, but actual risk reduction also requires prioritization, ownership, remediation, retesting, and documented decisions.

Conclusion: Effective AI governance requires operational evidence

Across its four functions, the NIST AI RMF gives organizations a practical structure for thinking about AI risk: Govern establishes accountability and visibility, Map provides context, Measure produces evidence, and Manage turns that evidence into decisions and action.

Application security is a crucial part of that system across multiple functions. AI capabilities run through applications, APIs, software components, data services, and infrastructure. Organizations need to know where those capabilities are, understand how they are exposed, test them in operation, and connect the results to accountable remediation.

Invicti helps provide some of the required technical evidence across the application portfolio:

• AI-BOM identifies and categorizes AI-related components
• Application and API discovery establish technical visibility
• DAST and API security testing probe exposed systems
• Proof-based scanning helps confirm exploitable vulnerabilities
• ASPM centralizes findings, prioritizes risk, and manages remediation

The AI RMF supplies the risk management structure. A mature and well-equipped AppSec program helps turn its security-related outcomes into measurable practice.

Request a demo to see how Invicti can discover AI-related components, test AI-enabled applications and APIs, and manage application risk from one platform.