For the past two years, the cybersecurity conversation around AI has focused on the wrong question. We have debated model safety, prompt injection filters, and output guardrails as though AI systems were simply more sophisticated chatbots. That framing is now dangerously obsolete.
AI agents have moved from recommendation to action. They do not just suggest a reply; they send the email. They do not just flag a suspicious transaction; they freeze the account. They do not just summarize a document; they delete the file. This shift from advisory to operational changes everything about how we manage risk.
The NIST AI Risk Management Framework was not designed specifically around today’s agentic architectures. But its four core functions, Govern, Map, Measure, and Manage provide a useful foundation for adapting AI risk management to systems that can plan, use tools, and take action. In February 2026, NIST launched its AI Agent Standards Initiative, a program focused on developing interoperable and secure standards and protocols for autonomous AI agents. The UC Berkeley Agentic AI Risk Management Standards Profile, also published in February 2026, explicitly organizes agentic AI guidance around NIST’s four functions.
The challenge is that the Manage function, long treated as the least glamorous of the four, suddenly carries disproportionate weight. Manage is where those risk decisions have to become operational controls. For agentic systems, that can mean defining which tool calls require approval, where the blast radius must be capped, and when human oversight becomes an enforceable control rather than a slogan.
How the Four Functions Apply to Agents
Before diving into implementation, it helps to see how each NIST function translates to agentic systems.
NIST describes Governance as cross cutting and emphasizes that the four functions work together rather than as a simple sequence. For agents, that means Manage cannot function without the policies established in Govern, the context identified in Map, and the evidence generated in Measure.
The Blast Radius Problem
Traditional security teams understand blast radius. A compromised service account can only do what that account is authorized to do. The damage is bounded by permissions. The agent era does not eliminate this principle, but it introduces a complication: agents dynamically select and invoke tools across a dozen systems, often within a single execution cycle.
An agent tasked with “researching and drafting a report” might query a search API, retrieve data from a CRM, delegate a formatting task to a sub-agent, and iterate on outputs all without pausing for human review. By the time a threshold based checkpoint triggers, the consequential decisions have already been made.
For agents with meaningful access to systems, data, or consequential actions, runtime guardrails are not optional. Static, pre-deployment reviews cannot catch an agent that behaves correctly in testing and then encounters a manipulated input in production.
For agents with meaningful access to systems, data, or consequential actions, the Manage function should translate risk decisions into controls that can inspect and, where appropriate, block a tool call at the moment it happens.
The most effective blast radius reduction combines identity discipline with policy enforcement. Least privilege for agents means credentials and authorization policies scoped to the specific tools, data, and actions a task requires, rather than granting the agent its full potential reach. Just-in-time access issues elevated permissions only for the duration of a specific task, then automatically withdraws them. Short lived credentials replace static API keys and standing tokens, carrying built-in expiration and a standard revocation path.
But identity controls alone are insufficient. An agent with perfect least privilege credentials can still be manipulated into using those credentials for malicious purposes. This is where a governance layer becomes essential.
The Governance Layer: One Implementation of NIST Principles
One practical implementation of these principles is a governance layer between the agent and the tools it invokes. This architecture intercepts every tool call, validates it against a developer defined policy, and logs the decision before the action executes. Allowed actions run immediately. High risk actions require human approval. Prohibited actions are blocked. Every decision is recorded with a tamper evident and verifiable audit trail.
This architecture matters because it separates policy from agent code. The agent cannot modify its own constraints. The governance layer enforces them externally. When the agent attempts an action beyond its policy whether through error, manipulation, or emergent goal seeking the layer catches it.
The policy can evolve as incident data, testing, and operational experience reveal new risks or patterns. Changes should remain subject to the organization’s change control and governance processes.
For auditors, this architecture produces the kind of contextual evidence an external auditor or investigator may need to reconstruct what happened and why. Not all logs serve this purpose equally. System level logs tell you that the HR system was accessed at 14:32:07. An agent level audit trail tells you that Agent ID A-4721, running system prompt version 3.2, accessed the HR system to retrieve specific fields for a specific employee, as part of a specific task initiated by a specific user under a specific authorization record.
Human-in-the-Loop Is Not a Checkpoint
The Berkeley Center for Long Term Cybersecurity's Agentic AI Risk Management Standards Profile offers a cautionary lesson, recommending human oversight checkpoints triggered by thresholds like duration of unsupervised activity, number of API calls, or requests outside a predefined scope. For highly autonomous agents, however, checkpoint based oversight may not provide sufficient granularity if consequential actions occur across multiple tool calls before a checkpoint is reached. As Stanford Law's CodeX independently argues, agentic architectures strain traditional oversight models.
The distinction matters: a checkpoint can be a prospective control, but its effectiveness depends on where it is placed and what action it is authorized to approve. For high stakes decisions such as moving funds, deleting data, changing permissions, or exporting customer lists organizations may need approval gates positioned directly before consequential actions, rather than relying solely on broader thresholds like API call counts. These gates should be enforced at the governance layer, outside the agent’s reasoning loop, so the agent cannot circumvent them.
From Checklists to Living Controls
The NIST AI RMF is deliberately non-prescriptive. It tells you what outcomes to pursue, not which specific control to deploy. For agents, that means the framework does not specify concrete permission models, does not define what least privilege looks like for a tool calling agent, and does not prescribe runtime enforcement mechanisms.
Organizations that treat AI RMF as a complete control checklist will find gaps in exactly the areas where agentic risk concentrates. Closing those gaps means pairing AI RMF with frameworks built for agent level detail. The OWASP Top 10 for Agentic Applications identifies risks including Agent Goal Hijack, Tool Misuse and Exploitation, Identity and Privilege Abuse, and Memory and Context Poisoning. These categories give security teams a concrete taxonomy for threat modeling agentic systems.
NIST itself has acknowledged the gap. The AI Agent Standards Initiative focuses on developing standards for interoperability and security. The NCCoE concept paper on agent identity and authorization proposes applying existing identity standards, OAuth 2.0, OpenID Connect, SPIFFE/SPIRE, and Zero Trust architecture to agents as a distinct non-human identity class. The paper specifically asks how organizations can apply identity, authentication, authorization, auditing, non-repudiation, least privilege, and human-in-the-loop authorization to software and AI agents.
But standards take time. The Manage function cannot wait for perfect guidance. The governance layer, the approval gates, the audit trails, organizations should begin building these capabilities now, before the first agent incident forces the conversation.
The central insight is not that NIST is inadequate. It is that an AI risk framework is only useful for agentic systems if risk decisions become enforceable controls at the point where an agent can actually take action. NIST gives organizations the risk management structure. The agentic era forces them to operationalize it at runtime.
What is the highest risk action your organization would allow an AI agent to take autonomously today? And more importantly who decided that was acceptable?