Why Traditional AI Governance Is Not Enough for AI Agents

A model that recommends a refund and an agent that issues one are governed by completely different questions. For the model you ask whether the output is accurate, fair and explainable. For the agent you ask which tools it could call, whose credentials it used, how many steps it took before anyone looked, and who could have stopped it halfway through.

Most enterprise AI governance programs were built to answer the first set. They were written for systems that produce outputs a human then acts on. Agents removed that human step, and in doing so they moved the entire risk surface from the prediction to the action. The Cloud Security Alliance now puts the median enterprise ratio of machine identities to human users at 45 to 1, up from 17 to 1 in its 2023 baseline. Very few of those identities sit inside a governance program that was designed with them in mind.

This article covers exactly where traditional AI governance breaks under agentic workloads, what NIST and OWASP have published to close the gap, and the nine controls US compliance and security teams should be able to evidence right now.

Model Governance Reviews Decisions. Agent Governance Has to Control Actions.

The distinction that matters is not autonomy. It is reversibility.

Traditional AI governance is fundamentally a review discipline. You assess a system before deployment, document the risk treatment, validate performance against a test set, and re-review on a cadence or when something material changes. The control point is a gate. That design works because a human sits between the model output and the consequence, and that human is the real backstop. If a credit model scores an applicant badly, an underwriter still has to act on it.

Agents collapse that gap. The system that reasons is the same system that executes, and it executes across tools, APIs and production data stores using delegated authority. A gate at deployment tells you almost nothing about what the agent did at 2:14 on a Tuesday in the fourteenth step of a plan nobody wrote down. Governance for agents has to be a control discipline that operates at runtime, not a review discipline that operates at release.

The NIST AI Risk Management Framework holds up better than most people expect here. Its Govern, Map, Measure and Manage structure is an operating model, not a checklist, and it survives the shift. What does not survive is the set of assumptions most organizations quietly built underneath it.

These limitations explain why organizations need a dedicated agentic AI governance approach designed specifically around autonomous actions, delegated authority, tool access, persistent memory, and runtime controls.

Five Assumptions That Stopped Being True

Every AI governance program encodes assumptions about the system it governs. Those assumptions are rarely written down, which is why nobody notices when they expire. Here are the five that agentic deployments invalidate.

Table 1: Where traditional AI governance assumptions fail under agentic workloads

Assumption	Why it held for models	Why it fails for agents	Control implication
Inputs are known at design time	Training and inference data were curated and version controlled	Agents ingest untrusted content at runtime from web pages, documents, emails and tool responses	Treat every retrieved artifact as untrusted input, not as context
A human acts on the output	The model produced a score or a recommendation, not a state change	The agent writes to the CRM, moves the money, merges the pull request	Approval gates must be attached to actions, not to deployments
The unit of risk is one inference	Fairness, accuracy and drift are all measurable per prediction	The unit of risk is a multi-step plan where each step is individually reasonable	Evaluate trajectories and outcomes, not single responses
The system acts under a human identity	The application called the model on behalf of a logged-in user	Agents hold their own credentials, tokens and OAuth grants	Per-agent identity with attribution back to an accountable owner
The system is static between releases	Model weights and interfaces changed only through a release process	Memory accumulates and tool catalogs expand without a code change	Change control has to cover memory state and tool registration

Read those control implications together and a pattern shows up. Not one of them is satisfied by a better impact assessment. They all require engineering controls that produce evidence continuously, which is a different budget line and usually a different team than the one that owns the AI policy.

The Blast Radius Problem Nobody Scoped For

An agent’s real risk exposure equals every credential, tool and API it can reach. That is the whole calculation, and it is the number most AI risk registers do not contain.

Consider a support agent with read access to a shared mailbox, write access to the CRM, and permission to issue account credits under a threshold. Each permission passed review on its own merits. Together they describe an attacker’s ideal foothold: a single poisoned email in that mailbox can redirect the agent’s objective, and the agent then acts with legitimate credentials through legitimate API calls that no data loss prevention rule will flag. Nothing in that chain is anomalous at the network layer. The agent is doing precisely what it is authorized to do, toward a goal it was manipulated into adopting.

The empirical picture supports treating this as a present-tense problem rather than a theoretical one. NIST research published in January 2025 found that novel attack strategies against AI agents succeeded at a rate of 81 percent in red-team exercises, compared with 11 percent against baseline defenses. That is not a gap you close with policy language.

Multi-step autonomy is what makes this different from ordinary application security. A conventional exploit gets one shot at a response. An agent compounds a compromise across an entire plan, and each subsequent step inherits the corrupted objective while looking locally sensible. Static analysis and software composition analysis cannot see any of it, because prompts, tool calls, memory writes and agent-to-agent traffic live in a layer that application security tooling was never pointed at.

WARNINGThe shared service account anti-pattern The fastest way to make agent activity unauditable is to run several agents under one service account, which is what most pilots do because it is the path of least resistance. When something goes wrong you can prove the account acted but not which agent, under whose authority, or in response to which request. Verizon’s 2026 DBIR cohort found that 31 percent of identity-related breaches traced back to a non-human credential that nobody on the current team could identify as theirs. Fix identity before you scale agent count, not after.

Agent Identity Is the Gap Auditors Will Find First

Identity and access management has assumed for twenty years that a principal is a person. Joiner, mover, leaver. A human arrives, gets entitlements, changes role, and eventually gets deprovisioned. Agents break every step of that lifecycle. They are created by product and engineering teams rather than IT, provisioned through API keys and OAuth grants that never touch the corporate directory, spawned and retired in seconds, and frequently acting on behalf of several users at once.

The measurements are consistent across independent sources even when the exact ratios differ. Entro Security’s research on non-human identities found that 97 percent of them carry excessive privileges. A January 2026 CSA and Oasis Security survey found 79 percent of IT professionals feel ill-equipped to prevent attacks that come through non-human identities. A 2026 CSA analysis of token sprawl found that more than 16 percent of organizations do not track the creation of AI-related identities at all. Perhaps the most operationally damning number: a 2026 Palo Alto survey found only 37 percent of organizations can revoke an AI agent’s credentials.

If you cannot revoke it, you do not govern it. That sentence is worth putting in front of a risk committee, because it reframes agent identity from an IAM housekeeping item into a control failure with a named owner.

The standards work here is further along than most teams realize. The National Cybersecurity Center of Excellence published a concept paper in February 2026 on accelerating the adoption of software and AI agent identity and authorization. Its proposal is deliberately unexciting: apply the identity standards that already work, including OAuth 2.0, OpenID Connect and SPIFFE/SPIRE, to agents treated as distinct non-human identities with enterprise-grade lifecycle management. There is no new protocol to wait for. The building blocks are in your stack already.

What per-agent identity looks like in practice

• One credential per agent instance, never a shared service account across agents or environments
• Short-lived tokens with automated rotation, scoped to the minimum tool set the agent’s task actually requires
• A recorded chain of authority linking the agent, the human owner accountable for it, and the request that triggered the run
• Deprovisioning tied to the agent’s retirement, tested the same way you test offboarding for staff
• Agents registered in the same inventory system as other privileged identities, not in a spreadsheet held by the platform team

Addressing these gaps should begin with an AI agent risk assessment that evaluates what an agent can access, what it can execute, how far a failure could spread, and how quickly the organization can detect and contain the problem.

The Risk Categories Your Framework Does Not Name

ISO/IEC 42001 tells you to run a risk assessment. It does not tell you which risks to assess for an agent, and neither does the AI RMF at the level of specificity a threat model needs. That layer arrived in December 2025.

The OWASP GenAI Security Project published the Top 10 for Agentic Applications 2026 on 9 December 2025, developed with more than 100 practitioners and researchers. It uses the designations ASI01 through ASI10 and covers ten domains: agent planning and goal hijack, tool misuse, identity, supply chain, unsafe code execution, memory, inter-agent communication, cascading failures, human-agent trust, and rogue agents. The list deliberately pivots away from the passive model risks in the LLM Top 10 and treats agents as principals with goals, tools, memory and inter-agent protocols, each of which is its own attack surface.

Two of those categories deserve attention because they have no analogue in traditional AI risk taxonomies. Memory poisoning is persistent: a corrupted memory entry survives the session, shapes future planning, and produces harmful behavior long after the injection point is forgotten. Cascading failure is systemic: in a multi-agent workflow, one agent’s bad output becomes another agent’s trusted input, and the error propagates with increasing apparent authority as it moves down the chain. Neither is a fairness problem, an accuracy problem or a drift problem. Your existing model risk taxonomy has no field for either.

Practically, treat OWASP’s taxonomy as the threat input to your ISO/IEC 42001 clause 6.1 risk assessment. Compliance is still determined by the regulation and the standard, not by a community list. But the list gives your risk assessment something concrete to assess against, which is what most agent risk registers are currently missing.

Once these risks are understood, organizations need practical controls for governing autonomous AI actions, including unique agent identities, permission boundaries, meaningful human intervention, action-level authorization, and complete audit trails.

What NIST Has Shipped and What It Has Not

US federal standards activity on agents accelerated sharply between mid-2025 and early 2026. Knowing precisely what exists today and what is still in draft is the difference between a defensible compliance roadmap and a plan built on documents that have not been published.

NIST’s Center for AI Standards and Innovation launched the AI Agent Standards Initiative on 17 February 2026, organized around three pillars: industry-led standards development, community-led open-source protocol work, and foundational security and identity research. Its request for information on agent security threats and vulnerabilities closed on 9 March 2026, and sector-specific listening sessions began in April 2026 targeting healthcare, financial services and education. Those three sectors were chosen because HIPAA, the Gramm-Leach-Bliley Act and FERPA were all written without any concept of a system that reads, modifies and transmits regulated data on its own initiative.

The most operationally useful output is still in progress. The Control Overlays for Securing AI Systems project, created in July 2025 with a concept paper in August 2025, is developing SP 800-53 control overlays for five AI deployment use cases. Two of them are explicitly agentic: single-agent systems and multi-agent systems. The first discussion draft, published 8 January 2026 with feedback closing 13 February, addressed predictive AI rather than agents. Agentic overlays are expected in subsequent drafts, with full publication tracking toward late 2026 into 2027.

The gap between now and then is the thing to plan around. Audit cycles do not pause for publication schedules. FedRAMP and Department of Defense assessments in 2026 are already producing questions about AI-specific control evidence, and “the overlay is not final” is not an answer that closes a finding. The concept paper is detailed enough that security architects can map existing SP 800-53 implementations against the identified gap areas now, which is a materially better position than starting the analysis when the final document lands.

Two other pieces round out the picture. The Cyber AI Profile, released in December 2025 as IR 8596, connects AI risk to the Cybersecurity Framework 2.0. And OMB Memoranda M-25-21 and M-25-22, issued in April 2025, already impose governance and procurement requirements on federal agencies under a High-Impact AI classification that captures many agentic deployments today, with no agent-specific rule needed. If you sell into the federal market, those memoranda are current obligations rather than future ones.

ISO/IEC 42001 Is the Right Backbone at the Wrong Resolution

Nothing about agentic AI invalidates an AI management system. ISO/IEC 42001 remains the most practical way to make AI governance auditable, and organizations that already run an AIMS are considerably better positioned than those starting from an AI policy document.

What the standard gives you transfers cleanly. Clause 5 establishes leadership accountability and named ownership, which is exactly what an agent inventory needs at the top. Clause 6 requires risk assessment and treatment, giving agentic threats a home. Clause 8 covers operational planning and control across the AI lifecycle. Clause 9 mandates internal audit and management review, which is how you keep the agent estate honest as it grows.

The limitation is granularity. An AIMS does not specify an agent inventory schema, define autonomy tiers, describe a tool permission model, require a kill switch, or set trust boundaries between cooperating agents. It was written in 2023 for AI systems as they were then understood, and it operates at the management system layer by design. Expecting it to enumerate agent controls is expecting the wrong thing from it, in the same way that ISO/IEC 27001 does not tell you how to configure a firewall.

The extension is straightforward and worth doing before your next surveillance audit. Name agents explicitly in the AIMS scope statement rather than letting them sit implicitly under “AI systems.” Add agent-specific interpretations to your Annex A control set, particularly around lifecycle, third-party tools and human oversight. Feed the OWASP agentic categories into clause 6.1 as threat inputs. Extend clause 9.1 monitoring to cover action-level telemetry rather than model performance metrics alone. None of that requires a new certification. It requires your existing one to actually cover what you deployed.

The US Regulatory Position Heading Into 2027

There is no federal law in the United States that regulates AI agents specifically. That fact gets misread as an absence of obligation, which is wrong in three separate ways.

First, state law. Colorado’s trajectory is the clearest signal of where US regulation is heading. Governor Polis signed Senate Bill 26-189 on 14 May 2026, repealing and replacing the 2024 Colorado AI Act. The replacement takes effect 1 January 2027 and is substantially narrower than its predecessor, dropping the duty of care, mandated risk management programs and annual impact assessments in favor of a notice-and-transparency framework built around automated decision-making technology. Attorney General rulemaking is mandatory and must be completed by 1 January 2027, and the AG has stated he will not enforce until that rulemaking concludes. A 60-day right to cure runs until 1 January 2030. The context matters too: xAI filed a constitutional challenge in April 2026, the Department of Justice intervened in support, and a federal magistrate stayed enforcement of the predecessor law on 27 April 2026.

The relevant point for agent governance is that SB 26-189 defines automated decision-making technology by what it produces and how that output is used, not by how autonomous the system is. An agent that assists a hiring or lending decision falls inside the definition on the same terms as a static model. Autonomy neither triggers nor exempts anything. It just makes the disclosure and record-keeping obligations harder to satisfy, because you have to reconstruct what the agent did.

Second, sectoral regulation already applies. An agent with access to protected health information is a HIPAA problem. An agent touching customer financial data sits under GLBA. An agent-caused outage or data exposure at a public company is a cybersecurity incident under the SEC disclosure rules, and the materiality clock does not offer an exemption because the actor was software.

Third, extraterritorial reach. US organizations serving EU users remain in scope of the EU AI Act. Under the digital omnibus agreement, obligations for several Annex III high-risk categories were deferred to 2 December 2027, with AI embedded in regulated products following on 2 August 2028. Article 14 on human oversight and Article 15 on accuracy, robustness and cybersecurity are where agentic evidence will be tested, and the OWASP categories map usefully onto both.

Nine Controls That Close the Gap

The following control set is deliberately mapped across frameworks, because the same evidence should satisfy more than one obligation. If you can only implement three this quarter, implement inventory, identity and action logging. Everything else depends on them.

Table 2: Agent control domains mapped to NIST AI RMF, ISO/IEC 42001 and SP 800-53

Control domain	What it means for agents	AI RMF function	ISO/IEC 42001 anchor	SP 800-53 family
Agent inventory and ownership	Every agent registered with a named accountable human owner and a documented purpose	Govern	Clause 5.3	PM, CM
Per-agent identity	Distinct non-human identity with short-lived, rotatable credentials	Manage	Clause 8.1	IA
Scoped tool permissions	Least privilege applied to the tool catalog, not just the data store	Manage	Clause 8.1	AC
Autonomy tiering	Documented tiers defining what the agent may do unattended versus with approval	Govern	Clause 6.1	PM
Approval gates on irreversible actions	Human confirmation required for payments, deletions, external communications and privilege changes	Manage	Clause 8.1	AC, PM
Memory integrity	Validation and expiry of persisted memory, with provenance on what wrote each entry	Measure	Clause 8.3	SI
Action-level audit logging	Every tool call logged with agent, owner, originating request and outcome	Measure	Clause 9.1	AU
Kill switch and rollback	Tested capability to halt a running agent and reverse its changes	Manage	Clause 8.1, 10.1	IR, CP
Continuous red teaming	Adversarial testing of goals, tools and memory before and after deployment	Measure	Clause 9.2	CA, RA

PRO TIPStart with autonomy tieringIf you implement one control from this table this quarter, make it autonomy tiering. It is cheap, it is a policy artifact rather than an engineering project, and it forces the conversation that every other control depends on: which actions can this agent take without a human, and who decided that. McKinsey’s 2025 State of AI survey found that 65 percent of high-performing AI organizations have defined human-in-the-loop validation processes, against 23 percent of everyone else. Tiering is how that definition gets made concrete rather than aspirational.

The Evidence an Auditor Will Actually Ask For

Governance programs are assessed on artifacts, not intentions. For agents, the artifacts are different from the ones your model governance program produces, and most teams discover this during an audit rather than before one.

An assessor testing agent controls will ask for a specific and predictable set of things:

1. A current agent inventory showing owner, purpose, autonomy tier and tool permissions for each entry, with a defined refresh cadence
2. Evidence that each agent holds a distinct identity, plus a demonstration that you can revoke one on request
3. Action logs for a sampled agent over a defined window, attributable to the agent, the accountable owner and the originating request
4. The approval gate configuration for irreversible actions, and log evidence that gates fired when they should have
5. A risk assessment that names agent-specific threats such as goal hijack, memory poisoning and cascading failure, with documented treatments
6. Red team results covering goal manipulation, tool misuse and memory integrity, dated within the assessment period
7. A kill switch procedure with evidence of a live test, not a documented intention to test
8. Change records covering tool registrations and memory schema changes, since these alter agent capability without a code release
9. Management review minutes showing the agent estate was discussed with metrics attached

Item two is where most programs fail. Revocation is easy to claim and hard to demonstrate, which is why only 37 percent of organizations could do it in the Palo Alto survey. Run the test internally before someone external asks.

A 90-Day Sequence for Teams Starting Now

Sequencing matters more than completeness. Attempting all nine controls at once tends to produce nine partial implementations and no defensible evidence. This order front-loads the controls that everything else depends on.

Days 1 to 30: establish the denominator

• Inventory every agent in production and pre-production, including the ones built by teams outside engineering
• Assign a named human owner to each, with no exceptions and no team-level ownership
• Assign an initial autonomy tier and document which actions are permitted unattended
• Record the full tool and data permission set per agent, which usually reveals more access than anyone expected

Days 31 to 60: fix identity and visibility

• Split shared service accounts into per-agent identities with scoped, short-lived credentials
• Turn on action-level logging with agent, owner and originating request captured on every tool call
• Reduce tool permissions to the minimum the documented purpose requires, and remove standing access to anything irreversible
• Test credential revocation on one live agent and record the result

Days 61 to 90: prove the controls work

• Implement approval gates on payments, deletions, privilege changes and external communications
• Run a red team exercise against goal hijack, tool misuse and memory poisoning on your highest-tier agent
• Execute a kill switch drill on a production agent during business hours and document the recovery
• Update the AIMS scope statement, clause 6.1 risk assessment and clause 9.1 monitoring to cover agents explicitly

Ninety days will not give you a mature agent governance program. It will give you an inventory, attributable identities, action-level evidence and a tested stop mechanism, which is enough to answer the questions an auditor or a regulator would ask first, and enough to keep deploying without the risk position getting worse each month.

Frequently Asked Questions

Is ISO/IEC 42001 enough to govern AI agents?

It is necessary but not sufficient on its own. ISO/IEC 42001 gives you the management system: accountability, risk treatment, lifecycle control and internal audit. It does not specify agent inventories, autonomy tiers, tool permission models or kill switch requirements. Extend your AIMS by naming agents in the scope statement and adding agent-specific threats to your clause 6.1 risk assessment.

What is the difference between AI governance and AI agent governance?

AI governance evaluates whether a system’s outputs are accurate, fair and explainable before deployment. AI agent governance controls what an autonomous system is permitted to do at runtime, including which tools it can call, what it can change, and how it can be stopped. The first is a review discipline. The second is a control discipline that operates continuously.

Do we need a separate risk register for AI agents?

You need separate risk categories, not necessarily a separate register. Agent-specific threats such as goal hijack, memory poisoning, tool misuse and cascading multi-agent failure have no equivalent field in a model risk taxonomy built around fairness, accuracy and drift. Adding those categories to your existing register is usually cleaner than maintaining two.

Does the Colorado AI law apply to AI agents?

Yes, where the agent contributes to a consequential decision. Senate Bill 26-189 takes effect 1 January 2027 and defines automated decision-making technology by the output it produces and how that output is used, not by the system’s level of autonomy. An agent that assists a hiring or lending decision is in scope on the same terms as a static model.

What does per-agent identity actually mean?

Each agent instance holds its own credential rather than sharing a service account, with short-lived tokens scoped to the minimum tools its task requires. Every action traces back to that agent, its accountable human owner, and the request that started the run. NIST’s NCCoE proposes applying existing standards including OAuth 2.0, OpenID Connect and SPIFFE/SPIRE rather than waiting for new protocols.

How do we set an autonomy tier for an agent?

Start from reversibility. Actions that can be undone cheaply sit in the highest autonomy tier. Actions that move money, delete data, change permissions or communicate externally require a human approval gate regardless of how reliable the agent has been. Document the tier, the rationale and the approver, then review it when the agent’s tool permissions change.

Are the OWASP agentic risks a compliance requirement?

No. The OWASP Top 10 for Agentic Applications 2026 is a community-developed security taxonomy, not a regulation. Compliance is determined by the applicable law and standard. Its value is as a threat input: it gives your ISO/IEC 42001 risk assessment and your EU AI Act Article 15 evidence something specific to assess against.

When will NIST publish agent-specific security controls?

The COSAiS project is developing SP 800-53 overlays for single-agent and multi-agent deployments, with publication tracking toward late 2026 into 2027. The January 2026 discussion draft covered predictive AI rather than agents. Do not wait for the final documents, because FedRAMP and DoD assessment cycles are already asking for AI-specific control evidence.

Final Takeaway

The question that separates governed agent estates from ungoverned ones is not whether the model is trustworthy. It is whether you can name the owner of every agent in production, show what it did last Tuesday, and switch it off. Most organizations can answer none of those three today, which is a governance failure rather than a technology one. The frameworks you already run, ISO/IEC 42001 and the NIST AI RMF, are the right foundation. They just need to operate at the level of actions rather than predictions.

Start with the inventory. You cannot tier, scope, log or revoke what you have not counted, and the count almost always comes back higher than expected.

For compliance and security professionals building this capability formally, GAICC’s Agentic AI Governance Professional certification and its ISO/IEC 42001 pathways cover the control design, audit evidence and regulatory mapping this work depends on.