Using NIST AI RMF to Build an AISecOps Program

I recently organized an AISecOps program around eight control domains:

1. Governance and inventory
2. Secure development and deployment
3. Identity and access
4. Data protection
5. Threat detection and monitoring
6. MCP and tool governance
7. Incident response and adversarial testing
8. Vulnerability and supply chain management

The first reference I added was the NIST Artificial Intelligence Risk Management Framework. It is the piece that gives the program an operating model.

NIST AI RMF is not an agent-security checklist. It does not tell an engineer exactly how to scope an MCP token or detect a poisoned tool response. Its job is broader. It creates a repeatable way to decide what needs protection, how risk should be measured, who owns the decision, and what evidence is required throughout the AI lifecycle.

That makes it a useful foundation for an AISecOps program, but not the only framework the program needs.

What NIST AI RMF is

AI RMF 1.0 is a voluntary, use-case-agnostic framework for organizations that design, develop, deploy, or use AI systems. Its Core has four functions:

• Govern establishes policy, accountability, risk tolerance, roles, and repeatable practices.
• Map documents the system’s purpose, context, actors, dependencies, impacts, and risks.
• Measure evaluates the system and the effectiveness of its controls.
• Manage prioritizes risk, chooses a response, monitors the result, and improves the program.

Govern is cross-cutting. It should shape Map, Measure, and Manage rather than appear once at the start of a project.

The framework also defines trustworthy AI characteristics such as validity, reliability, safety, security, resilience, accountability, transparency, explainability, privacy, and managed harmful bias. An AISecOps team may concentrate on security and resilience, but it cannot pretend those other characteristics belong to completely separate systems. A security control can affect privacy. A safety guardrail can reduce explainability. A model update can change reliability and invalidate a previous security test.

One important current detail: NIST says AI RMF 1.0 is being revised. Programs should keep the framework version in their control mappings instead of treating the current text as permanent.

What the four functions look like for agents

The four functions become much more useful when they produce specific artifacts.

Govern

Govern should establish the program charter, the eight domains, control ownership, risk acceptance authority, exception handling, and the minimum evidence required before deployment.

It should also define the agent inventory. An inventory record needs more than a project name. It should identify the owner, intended purpose, autonomy level, models, tools, identities, data classes, memory, outside inputs, deployment environment, and current risk tier.

Without that record, every later decision begins with discovery.

Map

Map turns a general AI policy into a system-specific threat model.

For an agent, I would document:

• the decision or task it is meant to perform;
• the people and systems affected by its output;
• every tool and downstream service it can reach;
• what information can enter through users, retrieval, files, messages, or other agents;
• what persists in memory;
• which actions are reversible;
• where human approval is required;
• the largest credible blast radius.

This is also where risk-tiering becomes defensible. A chat interface that drafts text is not equivalent to an agent that can send messages, modify infrastructure, or approve a transaction. Model choice matters, but capability and consequence usually matter more.

Measure

Measure asks for evidence instead of a statement that guardrails exist.

Evidence can include adversarial evaluations, prompt-injection tests, authorization tests, data-loss checks, tool-parameter validation, behavioral baselines, detection coverage, rollback tests, and incident exercises. Results should be tied to a system version, because a model, tool, prompt, or retrieval change can alter the result.

The useful output is not a pass badge. It is a measurement record with scope, method, result, limitations, owner, and expiration or retest condition.

Manage

Manage turns the mapped and measured risk into a decision.

The program might reduce privileges, add approval gates, isolate a tool, accept a documented residual risk, delay deployment, or retire the workload. It should also define what will be monitored after launch and which events force reassessment.

This is where AISecOps avoids becoming a review queue. The secure path should be built into normal delivery, with only high-risk exceptions requiring a separate decision.

Mapping the framework to eight domains

NIST’s functions do not replace the domains. They tell the domains how to operate.

AI RMF function	Primary AISecOps use	Domains most directly involved
Govern	Charter, ownership, inventory, policy, risk tiers, exceptions	1, with requirements across all eight
Map	System context, autonomy, data, identities, tools, dependencies, blast radius	1, 3, 4, 6, 8
Measure	Evaluations, control testing, telemetry validation, red-team results	2, 4, 5, 7, 8
Manage	Treatment decisions, monitoring, incidents, recovery, continuous improvement	1, 5, 7, with remediation across all eight

This prevents a common framework mistake. A team should not assign Govern to governance, Map to architecture, Measure to testing, and Manage to operations, then let each group work alone. Every domain participates in the cycle.

Add the Generative AI Profile

The NIST Generative AI Profile, NIST AI 600-1, is a companion to AI RMF 1.0. It narrows the broad framework toward risks that are specific to or amplified by generative AI.

For an agent program, the profile is useful when defining evaluation requirements, third-party risk, content provenance, data privacy, information integrity, and incident scenarios. It helps bridge the gap between a general AI risk process and the technical threat lists supplied by OWASP and MITRE.

A practical implementation sequence

I would introduce AI RMF into an AISecOps program in this order:

1. Define the eight domains, owners, risk authority, and common language.
2. Create one agent inventory schema that captures capability and consequence.
3. Establish risk tiers based on autonomy, data sensitivity, reach, and reversibility.
4. Create a standard Map worksheet for each workload.
5. Define minimum measurements for every tier and additional tests for specific risks.
6. Record deployment, exception, and risk-acceptance decisions in one system of record.
7. Set events that require reassessment, including model, tool, identity, memory, data, and architecture changes.
8. Review the framework mapping on a schedule because AI RMF and the underlying technology are both changing.

Where NIST stops

AI RMF can tell the program to identify, measure, and manage prompt injection. It does not supply the full engineering test plan. It can require threat-informed monitoring, but it does not provide the attack techniques a detection engineer should emulate.

That is why I use it with three other references:

• OWASP Top 10 for LLM Applications for LLM application risks;
• OWASP Top 10 for Agentic Applications for autonomy, tools, identity, memory, and delegation;
• MITRE ATLAS for adversary behavior, detection, testing, and response.

NIST AI RMF supplies the program rhythm. The other frameworks provide much of the technical threat content that moves through it.