For years, the biggest concern with generative AI was whether the model would produce the wrong answer.
Agentic AI changes that equation.
An AI assistant might recommend that you delete a file. An AI agent may actually delete it.
It might query a database, modify a cloud configuration, approve a workflow, send an email, create code, invoke an API, or initiate another agent. Increasingly, AI systems are moving beyond generating information and into taking actions inside real environments.
That transition changes the security question from “Can we trust the answer?” to “What happens if the agent makes the wrong decision?”
For CISOs and cybersecurity teams, that distinction is enormous.
And this is where one part of the NIST AI Risk Management Framework deserves much more attention: the Manage function.
From AI Output to AI Action
The NIST AI RMF organizes AI risk management around four functions: Govern, Map, Measure, and Manage.
Manage is where identified and measured risks are prioritized, treated, monitored, and responded to. NIST describes the function as including risk response, recovery, continuous monitoring, incident management, and mechanisms for disengaging AI systems when their behavior exceeds acceptable tolerances.
That language becomes especially relevant when the AI system is an agent.
NIST itself has recognized the shift. In February 2026, its Center for AI Standards and Innovation announced an AI Agent Standards Initiative, specifically addressing AI systems capable of autonomous action and interaction with external systems. NIST noted that agents increasingly perform activities such as coding, managing email and calendars, and interacting with other digital services.
The security problem is straightforward.
Every tool an agent can call becomes part of its attack surface.
Every permission it receives increases its potential blast radius.
Every autonomous decision creates an opportunity for an incorrect, manipulated, or unexpected action.
Manage 1: Decide How Much Risk the Agent Is Allowed to Create
NIST MANAGE 1 calls for organizations to prioritize risks based on impact, likelihood, organizational tolerance, and available mitigation resources.
For agentic systems, this should translate into something practical: not every action deserves the same level of autonomy.
Consider an enterprise agent capable of reading support tickets, searching an internal knowledge base, issuing refunds, modifying customer accounts, and disabling user credentials.
Those actions do not carry equivalent risk.
Reading a knowledge article might require little supervision.
Issuing a $10 refund may be acceptable within predefined limits.
Issuing a $100,000 refund should probably never happen without human authorization.
Disabling an administrator account should likely require an entirely different approval process.
Instead of treating an agent as either “autonomous” or “not autonomous,” organizations can establish risk tiers for actions.
Low impact actions can execute automatically.
Moderate impact actions can execute within tightly defined thresholds.
High impact actions require human approval before execution.
Critical actions may simply be unavailable to the agent.
This converts abstract AI risk tolerance into enforceable technical controls.
Manage 2: Put Limits Around the Blast Radius
MANAGE 2 focuses on implementing strategies that minimize negative impacts and establishing mechanisms to respond when systems behave unexpectedly.
NIST specifically recommends controls such as authentication, throttling, business rules that restrict AI outputs, continuous monitoring, testing, and mechanisms for deactivating systems when risks exceed established tolerances.
For autonomous agents, these concepts can become blast radius controls.
Imagine an AI agent responsible for maintaining cloud infrastructure.
Giving that agent unrestricted administrator privileges may be convenient, but convenience is not a security architecture.
A safer design could restrict the agent to specific cloud resources, cap the number of resources it can modify during a single session, prohibit deletion of production systems, require approval for privilege changes, impose API rate limits, and automatically suspend the agent when unusual behavior is detected.
This is essentially the principle of least privilege applied to machine autonomy.
OWASP identifies the opposite condition as Excessive Agency, where an AI system has unnecessary functionality, permissions, or autonomy. OWASP warns that manipulated prompts, hallucinations, compromised tools, or other failures can cause agents to perform damaging actions when those controls are missing.
Its newer Agentic AI guidance also identifies Tool Misuse and Exploitation as a distinct risk, where an agent uses a legitimate tool in an unsafe or unintended way even while operating within its assigned permissions.
That distinction matters.
An agent does not necessarily need to “break into” a system to cause an incident.
It may already have permission.
Human in the Loop Is Necessary, But It Is Not Enough
Human approval is frequently proposed as the solution to agentic AI risk.
For high consequence actions, it remains an important safeguard.
But organizations should avoid treating a pop up confirmation box as a complete security control.
Approval interfaces themselves can be misleading. OWASP has documented attacks in which untrusted content influences the information presented to the human reviewer, potentially causing the person to approve an action without understanding what will actually occur.
A stronger approval workflow should show the actual operation being requested.
What system will be modified?
What account will be used?
What data will leave the environment?
What permissions are required?
What is the expected impact?
Can the action be reversed?
The person approving the operation should be reviewing the transaction, not merely the agent’s explanation of the transaction.
Manage 3: Your Agent Is Also a Supply Chain
Agentic systems rarely operate alone.
They may depend on foundation models, APIs, plugins, Model Context Protocol servers, databases, third party tools, external data sources, and other agents.
NIST MANAGE 3 explicitly addresses risks introduced through third party AI resources and calls for monitoring, documentation, testing, and contingency planning for those dependencies.
For security teams, that means an agent inventory should include more than the underlying model.
Organizations should know which tools an agent can invoke, which credentials it uses, which external services receive data, which models participate in decisions, what permissions each component holds, and what happens when one of those dependencies changes.
Agent governance is quickly becoming a form of software supply chain governance.
Manage 4: Build the Kill Switch Before You Need It
Perhaps the most relevant portion of the AI RMF for autonomous systems is MANAGE 4.
NIST calls for post deployment monitoring, incident response, recovery, override mechanisms, change management, and decommissioning. It also recommends procedures for bypassing or disabling AI systems when performance or risk moves outside established tolerances.
For agentic AI, organizations should translate that into real operational capability.
Security teams need to be able to immediately revoke an agent’s credentials, terminate active sessions, disable specific tools, block outbound connections, suspend autonomous workflows, preserve logs for investigation, and return critical operations to human control.
A kill switch that exists only in a governance document is not a kill switch.
It must work at runtime.
The Security Architecture Is Moving Outside the Model
The most important lesson may be that securing agentic AI is not primarily about making the model perfect.
No model will be perfect.
The safer architecture assumes the model will eventually misunderstand something, hallucinate, encounter malicious input, choose the wrong tool, or make a decision outside its intended context.
The surrounding system should prevent that mistake from becoming a catastrophe.
That means combining AI risk management with familiar cybersecurity principles: least privilege, separation of duties, transaction limits, strong identity, logging, continuous monitoring, approval gates, incident response, and rapid credential revocation.
NIST’s AI RMF was intentionally designed as a voluntary and technology neutral framework rather than a prescriptive checklist.
That flexibility may turn out to be particularly valuable for agentic AI.
The challenge now is translating the framework from governance language into controls that operate at the exact moment an agent tries to act.
Because the future security question will not simply be whether your AI produced the wrong answer.
It will be:
How much damage was it capable of doing before anyone could stop it?
As AI agents gain access to your organization’s email, databases, cloud infrastructure, APIs, and business processes, which actions would you allow them to perform autonomously, and which ones would you never permit without a human in the loop?
Marcus, this is an excellent article.
I just returned from Riyadh, where I spoke about many of these same questions from the business and governance side. I wasn’t discussing NIST specifically, but the underlying problem was remarkably similar.
Two lines especially stood out to me:
**“The challenge now is translating the framework from governance language into controls that operate at the exact moment an agent tries to act.”**
This is almost word for word the question I raised in my presentation. Governance cannot remain a policy layer sitting above the system. The critical question is what happens at the moment of action — where the control actually sits, what it can stop, and when.
And this:
**“The person approving the operation should be reviewing the transaction, not merely the agent’s explanation of the transaction.”**
Absolutely. But it also raises another question I’ve been thinking about: if a human rejects 15 “creative solutions” proposed by an agent, does the human eventually become part of the puzzle the agent is trying to solve?
That is where human-in-the-loop becomes much more interesting than simply adding an approval gate.
Wonderful piece, Marcus. Fascinating to see the same problem emerging from the cybersecurity and business governance sides.