Gartner’s 2026 CIO and Technology Executive Survey found that 17 percent of organizations have deployed AI agents, while more than 60 percent expect to within two years. The same firm expects more than 40 percent of agentic AI projects to be cancelled by the end of 2027, with inadequate risk controls named among the three main causes. Those figures describe one problem from two directions. Agents are being handed real authority over real systems faster than anyone is writing down what that authority covers.
Agentic AI governance is what closes the distance. It is not model governance with a new label, and it is not a policy document. It is a control set: agent identity, bounded authority, action-level authorization, human oversight that survives contact with autonomy, and an audit trail that can reconstruct who instructed an agent to do what, and when.
Agentic AI Governance, Defined
Agentic AI governance is the practice of controlling delegated authority in AI systems that plan and execute actions on their own. It establishes which agents exist inside an organization, what identity each one carries, which tools and data it can reach, how far it can go before a person approves, and what record it leaves behind. Conventional AI governance asks whether a model’s output is accurate, explainable and fair. Agentic AI governance asks a harder question: was the action this system already took authorized, and can you prove it.
The shift is in the unit of control. For a predictive model or a chatbot, the governable artifact is an output. A person reads it, evaluates it, and decides what to do. For an agent, the governable artifact is an action that has already changed something outside the model: a refund issued, a record updated, a pull request merged, an email sent to a customer. Review after the fact is still useful, but it is no longer prevention.
This is why the standards community treats agents as a distinct category rather than a bigger version of generative AI. ISO/IEC 42001:2023 applies across AI system types, including predictive machine learning, generative AI and agentic systems, but its Annex A controls describe governance obligations rather than runtime enforcement. The gap between a documented obligation and an enforced runtime boundary is precisely where agentic programs fail.
A working definition that holds up in an audit: agentic AI governance is the set of policies, technical controls and evidence practices that determine what an autonomous system is permitted to do, under whose authority it acts, and how that authority is verified, constrained, logged and withdrawn.
Before organizations allow AI agents to operate with meaningful autonomy, they need a structured way to understand what those agents can access, what actions they can perform, and what happens when something goes wrong. An AI agent risk assessment helps evaluate factors such as tool access, autonomy levels, blast radius, reversibility, and detection lag.
Four Properties That Break Traditional AI Governance
A chatbot that gives bad advice produces a bad answer. An agent that acts on bad advice produces a bad transaction. Earlier generation systems operated in bounded, largely read-only contexts, and their failure modes stayed inside the output. Four properties change that calculus, and each one invalidates a governance assumption that most enterprise AI policies were written on.
Autonomy over multi-step plans
An agent decides its own sequence. You specify a goal, and it selects the steps. That means the control surface is not a single prompt and response but a trajectory that may run for minutes or hours across dozens of intermediate decisions, none of which a person saw. Approval at the goal level is not approval of every step taken to reach it.
Tool access and write permissions
Agents call APIs, execute code, query databases and trigger workflows. The moment an agent holds a write credential, its blast radius equals the permissions attached to that credential. Most enterprise deployments inherit an over-permissioned service account because that was the fastest path to a working pilot, and nobody revisited it before production.
Persistent memory
Agents that retain state across sessions carry contamination forward. A single poisoned memory entry can shape behavior for weeks, which turns a one-time injection into a durable compromise. Traditional model governance has no equivalent concept, because a stateless model forgets the attack the moment the context window clears.
Delegation to other agents
Multi-agent orchestration means one agent can instruct another, and that second agent may sit outside your organization entirely. Accountability becomes a chain rather than a point. KPMG’s Q2 2026 AI Quarterly Pulse found that orchestration of multiple agents doubled in a single quarter, from 9 percent to 18 percent of large US organizations, which means the chain problem is arriving faster than most governance functions expected.
| WATCH OUT: The service account problem: NIST’s National Cybersecurity Center of Excellence stated the core gap plainly in its February 2026 concept paper: AI agents are commonly treated as generic service accounts with no dedicated identity, authorization or accountability. If your agents share a credential with a batch job, you cannot answer the first question any auditor will ask, which is which agent performed this action and on whose authority. |
What Actually Goes Wrong: The Agentic Risk Taxonomy
OWASP published the Top 10 for Agentic Applications 2026 on December 9, 2025, and it is currently the most usable shared vocabulary for agent risk. The ten categories run from ASI01 through ASI10 and cover agent goal hijack, tool misuse, memory poisoning and rogue agents, among others. The prefix stands for Agentic Security Initiative, and the value of the list is less the ranking than the fact that it gives security, risk and audit teams a common set of labels for incidents that previously had none.
Goal hijack sits at the top for a reason. It happens when an attacker redirects an agent’s objective through content the agent reads rather than code the agent runs. The agent believes it is still pursuing the user’s goal. The defining case is EchoLeak, tracked as CVE-2025-32711 with a CVSS score of 9.3, the first known zero-click attack on an AI agent: a single crafted email carried hidden instructions that Microsoft 365 Copilot later processed. No user clicked anything.
NIST recognized this class of problem in its adversarial machine learning taxonomy update, AI 100-2 E2025, which classifies agentic systems as a distinct attack surface and adds dedicated treatment of prompt injection, tool misuse and action hijacking. The taxonomy makes an important point that governance teams tend to miss: these techniques are not new, but their severity compounds when the model is connected to real-world execution capability. A prompt injection against a chatbot yields a rude paragraph. The same injection against an agent with database write access yields a data integrity incident.
Then there is the risk that shows up before any attacker does. Surveys through 2026 consistently put unsanctioned AI tool use among employees near two thirds, and agent frameworks are now easy enough to stand up that a motivated analyst can deploy one over a weekend. The result is agents operating against production systems that no risk register lists. You cannot govern an inventory you do not have, and shadow agents are the reason most first-time agent risk assessments understate exposure by a wide margin.
Worth separating clearly: the failure modes above are security failures. Agents also produce governance failures with no adversary at all. An agent that correctly executes a badly specified goal, at scale, without a person noticing for three weeks, is not a security incident. It is a control failure, and it is the more common one.
Where US Regulation Stands on AI Agents Right Now
No US federal statute regulates AI agents as a named category. What exists instead is a standards effort moving quickly at NIST, a set of state laws that reach agents through what they do rather than what they are, and sector rules that already apply whether or not anyone updated them for autonomy.
The federal standards track
NIST’s Center for AI Standards and Innovation launched the AI Agent Standards Initiative on February 17, 2026, the first US government program dedicated explicitly to interoperability and security standards for agentic systems. It is organized around three pillars: industry-led standards development including US participation in ISO/IEC work on agent interoperability, open-source protocol development, and security and identity research. You can follow the initiative directly through the NIST AI Agent Standards Initiative page, which lists the current requests for information and draft concept papers.
Two workstreams matter most for compliance planning. The NCCoE concept paper published February 5, 2026, titled Accelerating the Adoption of Software and AI Agent Identity and Authorization, proposes applying established identity standards including OAuth, OpenID Connect, SPIFFE/SPIRE and SCIM to AI agents treated as identifiable enterprise entities. Separately, the COSAiS project is developing SP 800-53 control overlays for securing AI systems, with dedicated treatment of single-agent and multi-agent architectures. Those overlays are not final. Organizations that complete their SP 800-53 mapping now will be able to demonstrate conformance quickly once they publish, and audit cycles will not pause for the publication schedule.
State law reaches agents through their effects
Texas TRAIGA, House Bill 149, has been in force since January 1, 2026 and applies to any developer or deployer doing business with Texas residents, with no compute or revenue threshold. It is conduct-based, prohibiting behavioral manipulation, unlawful discrimination and certain deepfake categories, and it is enforced solely by the state attorney general. Notably for governance teams, substantial compliance with the NIST AI RMF supports an enforcement safe harbor, which is the clearest current example of a US state converting a voluntary framework into legal force.
Colorado repealed and replaced its 2024 AI Act. Governor Polis signed SB 26-189 on May 14, 2026, replacing SB 24-205 with an automated decision-making technology regime effective January 1, 2027. The mandatory risk management program, annual impact assessment and NIST/ISO affirmative defense are gone. What remains is a disclosure framework built on pre-use consumer notices, adverse-outcome explanations within 30 days, meaningful human review and developer documentation, with a 60-day cure period and exclusive attorney general enforcement. If an agent influences a consequential decision for a Colorado resident, including employees and job applicants, that regime applies to the agent.
Around those two: California’s SB 53 and AB 2013 took effect January 1, 2026, with CPPA automated decision-making technology obligations for significant decisions starting January 1, 2027. New York’s RAISE Act is effective January 1, 2027. Illinois HB 3773 made AI-driven employment discrimination a civil rights violation as of January 1, 2026, and New York City Local Law 144 has required bias audits for automated employment decision tools since 2023. State AI statutes generally attach to the people a system touches rather than where the company sits, so an agent hosted in Virginia that screens an applicant in Illinois is inside the Illinois regime.
The EU position, for US companies with European exposure
The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on July 24, 2026 and entered into force on July 27, 2026. It defers stand-alone Annex III high-risk obligations from August 2, 2026 to December 2, 2027, and Annex I embedded systems to August 2, 2028. The deferral is narrower than the headlines suggested. Article 50 transparency duties, general-purpose AI provider obligations and the Article 5 prohibited practices all kept their original dates, and Article 50 has been live since August 2, 2026. An agent that interacts with people in the EU has a disclosure obligation now, regardless of the high-risk timeline.
Sector rules deserve a line of their own because they are frequently forgotten. HIPAA, SEC cybersecurity disclosure requirements, FedRAMP, SOC 2 and CMMC 2.0 do not contain the word agent, and they apply anyway. An agent with access to protected health information is a workforce member’s access path under HIPAA. An agent-triggered incident that is material is disclosable under the SEC rules. Nothing about autonomy creates an exemption.
The Frameworks You Can Build On Today
No single framework covers agentic AI end to end, and waiting for one is not a strategy. What works is a stack: a management system that carries the accountability and audit structure, a risk framework that supplies the vocabulary regulators recognize, a control catalog that maps to your existing security program, and a threat model that describes what attackers actually do to agents.
| Framework | What it governs | Agent-specific coverage | Best used for |
|---|---|---|---|
| ISO/IEC 42001:2023 | AI management system: leadership, planning, operation, evaluation, improvement | Applies to agentic systems but describes obligations, not runtime enforcement | Certifiable accountability structure and third-party assurance |
| NIST AI RMF (AI 100-1) and GenAI Profile | Risk across Govern, Map, Measure, Manage functions | General; extended by the AI Agent Standards Initiative | Common risk vocabulary and Texas TRAIGA safe harbor alignment |
| NIST SP 800-53 with COSAiS overlays | Security and privacy controls for federal and regulated systems | Overlays in development for single-agent and multi-agent systems | Mapping agents into an existing control catalog before overlays finalize |
| NIST CSF 2.0 Cyber AI Profile (IR 8596) | Cybersecurity outcomes applied to AI systems | AI-specific threat and response outcomes | Connecting agent risk to an existing CSF-aligned security program |
| OWASP Top 10 for Agentic Applications 2026 | Agent-specific threats, ASI01 to ASI10 | Purpose-built for autonomous agents | Threat modelling, red teaming and security requirements |
| IMDA Model AI Governance Framework for Agentic AI | Practical governance for autonomous agents | First dedicated agentic framework; updated May 20, 2026 | Design patterns for multi-agent, third-party agents and automation bias |
Table 1. Framework stack for agentic AI governance in the United States, as of September 2026
The ISO and NIST pairing is the practical base for most US organizations. ISO/IEC 42001 supplies the management system: documented roles, a statement of applicability, internal audit, management review and corrective action. The NIST AI RMF supplies the risk language that state attorneys general and federal agencies already use. OWASP supplies what neither does, which is a concrete threat model. Singapore’s IMDA framework is worth reading even though it carries no US legal weight, because it was the first framework written for agents specifically and its May 2026 update added real case studies on multi-agent systems, third-party agents and automation bias.
The need for these additional controls becomes clearer when examining why traditional AI governance is not enough for AI agents. Unlike conventional AI systems that primarily generate outputs, autonomous agents can use tools, modify systems, retain memory, and delegate tasks to other agents.
The Six Control Domains of an Agentic AI Governance Program
Frameworks describe outcomes. Programs need controls. Six domains cover the substance of what an agentic AI governance program has to enforce, and a program missing any one of them has a gap that will show up either in an audit or in an incident.
| Control domain | What good looks like | Framework anchor |
|---|---|---|
| Agent identity and authentication | Every agent holds a unique, non-human identity distinct from the user and from shared service accounts, issued and revocable through the identity provider | NCCoE agent identity concept paper; SP 800-53 IA family; ISO/IEC 42001 A.4 resources |
| Least agency and bounded authority | Autonomy is assigned by tier, not by default. Scope, spend, record count and time window are capped per agent, and expanding them is a change with an approver | OWASP ASI guidance on least agency; SP 800-53 AC family |
| Action and tool authorization | Permission is evaluated per action at runtime, not once at session start. Irreversible and high-value actions route to an approval gate | OWASP ASI02 tool misuse; ISO/IEC 42001 A.6 lifecycle controls |
| Memory and data governance | Memory writes are validated and attributable, retention is bounded, and memory can be inspected, exported and purged on demand | OWASP memory poisoning; ISO/IEC 42001 A.7 data for AI systems |
| Observability and the audit trail | Action-level logging that captures the agent identity, the triggering instruction, the tool called, the parameters, the outcome and the human authority behind it | NIST CSF 2.0 Cyber AI Profile; EU AI Act Article 12 logging |
| Interruption, containment and escalation | A tested path to suspend one agent, a class of agents, or all agents, with a measured mean time to disable and a named on-call owner | NIST AI RMF Manage function; ISO/IEC 42001 A.10 incident response |
Table 2. Six control domains, what good looks like, and where each anchors
Two of these deserve expansion, because they are where most programs are weakest.
Least agency is not least privilege
Least privilege governs what an identity can access. Least agency governs how much freedom it has to act on that access without checking back. They are different axes, and an agent can pass a least privilege review while failing badly on agency. An agent granted read and write on a single CRM object has narrow privilege. If it can execute an unlimited number of writes, in any order, across any record, for eight hours without a checkpoint, its agency is effectively unbounded.
The practical control is a tier model. Tier one agents are read-only and advisory. Tier two agents write to reversible, low-value records within a capped volume. Tier three agents touch money, customer-facing communications, production infrastructure or regulated decisions, and every tier three action either passes through an approval gate or lands in a review queue with a defined service level. Assign the tier at registration, and treat a tier change as a governed change with an approver and a record.
The audit trail has to answer a specific question
Most agent logging captures model inputs and outputs. That is observability for debugging, not evidence for governance. The question an auditor, a regulator or an incident responder will ask is a chain-of-authority question: this action happened, which agent did it, what instruction triggered it, which human or system delegated that authority, what permissions were checked, and what changed as a result. If reconstructing that requires correlating four systems by timestamp, you do not have an audit trail. You have logs.
| PRO TIP: Start with the registry, not the policy – Teams that begin with a written agentic AI policy usually spend six weeks on a document that governs an unknown population. Teams that begin by inventorying every agent, its owner, its credentials and its tool access typically find between two and four times more agents than the risk register listed, and the policy writes itself afterward because you now know what you are governing. |
Human Oversight When Nobody Is Watching Every Step
Human in the loop was a workable control when a model produced one recommendation and a person accepted or rejected it. It does not survive an agent that executes four hundred steps an hour. Insisting on it anyway produces one of two outcomes: the agent is throttled until it delivers no value, or reviewers start approving in bulk without reading, which is worse than no review because it manufactures an audit trail of approvals that nobody actually performed.
Three oversight patterns work at agent speed, and mature programs use all three concurrently rather than choosing one.
Pre-action gates apply to the small set of actions that are irreversible or high consequence: payments above a threshold, external communications, production deployments, adverse decisions about a person. The gate is narrow by design, because a gate on everything is a gate on nothing.
Statistical sampling applies to high-volume reversible actions. Define a sampling rate, a review service level and an escalation threshold, then track whether the error rate in the sample stays inside tolerance. This is quality control logic borrowed from manufacturing, and it is the only oversight model that scales linearly with agent volume.
Post-hoc reconciliation applies where reversal is possible within a window. Nightly reconciliation against source systems catches drift that neither gates nor sampling detect, particularly the slow kind where an agent performs correctly against a subtly wrong specification.
Automation bias is the failure mode that undermines all three. Reviewers approve agent recommendations at markedly higher rates than they approve identical recommendations from a colleague, and the effect strengthens as the agent’s accuracy record improves. IMDA’s updated framework added explicit treatment of automation bias in May 2026 for exactly this reason. The design test is simple and uncomfortable: in the last ninety days, how many agent actions did your reviewers reject? If the answer is close to zero, you do not have oversight. You have a rubber stamp with a timestamp.
This matters legally as well as operationally. Colorado’s SB 26-189 requires meaningful human review, and EU AI Act Article 14 places the human oversight duty on the deploying party rather than on the model provider or the protocol. In both cases, meaningful implies the reviewer has the context to disagree, the authority to override and a path to reverse. A reviewer who can only click approve is not oversight in either regime.
Agent Inventory and the AIBOM
An AI bill of materials covering agents, tools and Model Context Protocol servers is becoming the expected inventory artifact, in the same way a software bill of materials became expected for application security. It is also the single highest-value thing a governance team can build in its first month, because every other control depends on knowing the population.
A registry entry that supports real governance carries eleven fields:
- Agent identifier, unique and issued by the identity provider rather than chosen by the team that built it.
- Named human owner and an accountable business function. Not a team inbox.
- Business purpose in one sentence, stated as an outcome the agent is authorized to produce.
- Underlying model and version, including whether it is hosted internally or by a third party.
- Tools, APIs and MCP servers the agent can call, with the specific scopes attached to each.
- Data classes the agent can read and write, mapped to your existing classification scheme.
- Credentials held, their permission scope and their rotation schedule.
- Autonomy tier and the specific caps that apply: volume, value, time window, record scope.
- Human oversight mode: pre-action gate, sampling rate, or reconciliation cadence.
- Deployment date, last review date and next scheduled review.
- Decommission trigger and the tested procedure for disabling it.
Finding the agents is harder than recording them. Four discovery methods together produce a reasonably complete picture: identity provider queries for non-human identities created in the last twelve months, egress and API gateway analysis for traffic patterns consistent with agent frameworks, expense review for AI platform and orchestration spend outside the approved catalog, and a no-blame amnesty window where teams register what they built without consequence. The amnesty matters. Discovery frameworks that begin with enforcement produce hidden agents, not fewer agents.
One practice separates registries that hold up from registries that decay: treat each agent as a first-class risk asset in the same register as applications and third parties, not as a line item inside an AI model inventory. Agents change faster than models, they acquire permissions incrementally, and they are frequently modified by people who do not consider the modification a change. A quarterly attestation from the named owner, confirming the tool list and permission scope are still accurate, keeps the record honest at a cost of about fifteen minutes per agent per quarter.
Multi-Agent Systems, MCP and Third-Party Agents
Governance for a single agent is a permissions problem. Governance for a chain of agents is an accountability problem, and it gets harder at every hop.
The Model Context Protocol has become the common interface between agents and tools since being donated to the Linux Foundation’s Agentic AI Foundation in December 2025, and it is now a meaningful part of the supply chain. Security analysis published in 2026 by BlueRock covering more than seven thousand MCP servers found roughly 37 percent carried server-side request forgery vulnerabilities. Those servers sit inside agent workflows with credentials attached. Any organization connecting agents to third-party MCP servers has inherited a dependency it probably has not inventoried, let alone assessed.
The accountability question is the one most legal and compliance teams have not yet been asked. When your orchestrator agent instructs a vendor’s agent, which then calls a third party’s tool, and the outcome harms a customer, four parties can each point at another. Contractual clarity has to be established before the incident, not after. Three provisions cover most of the ground: an obligation on the vendor to maintain agent-level identity and provide action-level logs on request, a defined notification window for agent behavior changes and model version changes, and an explicit statement of which party holds the human oversight duty for decisions affecting your customers.
Architecturally, the pattern that scales is a single mediation point. Every tool call from every agent, internal or delegated, passes through one authorization layer that evaluates the request against policy, records it, and can refuse it. Agents delegate to each other; they do not delegate around the boundary. That is more work to build than embedding credentials in each agent, and it is the difference between a program where you can answer questions about agent behavior and one where you cannot.
One more constraint worth stating explicitly: an agent should never be able to grant another agent permissions it does not itself hold, and a delegation chain should carry the original human authority forward rather than resetting at each hop. Chains that reset are how a low-privilege request ends up executing with an orchestrator’s privileges, which is the classic confused deputy problem wearing new clothes.
A 90-Day Sequence and How to Measure It
Programs that stall usually stall because they tried to write policy for a population they had not counted. This sequence front-loads discovery and containment, then builds controls on top of a known base.
Days 1 to 30, establish the population and the emergency stop. Run the four discovery methods, build the registry, assign an owner to every agent, and classify each one by autonomy tier and blast radius. Then test the kill switch on a production agent and measure how long it actually takes to disable. Most teams find that their first measured mean time to disable is counted in hours, not seconds, and that number alone reframes the risk conversation with the board.
Days 31 to 60, fix identity and agency on the highest tier. Issue unique non-human identities to every tier three agent, remove shared service account credentials, apply volume and value caps, and route irreversible actions to approval gates. Do not attempt this across the whole population at once. The top tier is usually five to fifteen agents, and finishing it completely is worth more than starting it everywhere.
Days 61 to 90, build the evidence layer and the oversight design. Stand up action-level logging with the chain-of-authority fields, define the sampling rates and review service levels, write the agent incident runbook and rehearse it once, then update your policy set and, if you operate an ISO/IEC 42001 management system, your statement of applicability and risk treatment plan. Policy written at this point reflects a system that exists.
Six metrics tell you whether any of it is working. Track the percentage of registered agents holding a unique identity, the measured mean time to disable a single agent, the percentage of tier three actions passing an approval gate or review, action-level log coverage as a percentage of executed actions, the rejection rate on reviewed agent actions, and the number of previously unregistered agents found per discovery cycle. That last one is the honest measure of program maturity. When it approaches zero for two consecutive quarters, your inventory is real.
Report those six to the risk committee monthly. They are more informative than a maturity score, and they are the numbers that hold up when an auditor asks how you know your agents are controlled.
Defining governance principles is only the first step. Organizations also need practical controls for governing AI agents that can take autonomous actions, including agent identity, bounded permissions, human oversight, action-level authorization, and auditability.
Frequently Asked Questions
What is the difference between AI governance and agentic AI governance?
AI governance controls what a model produces. Agentic AI governance controls what an autonomous system does. The first evaluates outputs for accuracy, bias and explainability before a person acts on them. The second constrains actions the system takes on its own, which means identity, permission scope, action authorization and audit trails become primary controls rather than supporting ones.
Does ISO/IEC 42001 cover AI agents?
Yes. ISO/IEC 42001:2023 applies across AI system types including predictive machine learning, generative AI and agentic systems, and its Annex A controls cover accountability, data governance, lifecycle management and incident response for all of them. What it does not provide is runtime enforcement. You still need technical controls for agent identity, action authorization and containment underneath the management system.
Is there a US law that regulates AI agents specifically?
No US law names AI agents as a regulated category. State laws reach them through effect instead: Texas TRAIGA has applied since January 2026, Colorado SB 26-189 takes effect January 1, 2027, and Illinois HB 3773 and NYC Local Law 144 apply to employment decisions regardless of autonomy. Sector rules including HIPAA and the SEC cybersecurity disclosure requirements apply already.
What is least agency and how is it different from least privilege?
Least privilege limits what an identity can access. Least agency limits how much an agent can do with that access without a checkpoint. An agent can hold narrow permissions and still have unbounded agency if it can perform unlimited actions across unlimited records without review. Effective programs cap volume, value, time window and record scope alongside permission scope.
How do you give an AI agent its own identity?
Issue a non-human identity through your existing identity provider rather than reusing a service account. NIST’s NCCoE concept paper from February 2026 proposes applying OAuth, OpenID Connect, SPIFFE/SPIRE and SCIM to agents as identifiable enterprise entities. Practically, that means a distinct principal per agent, scoped credentials, a rotation schedule and revocation that takes seconds rather than a ticket.
What should an agent audit log capture?
Enough to reconstruct the chain of authority for any single action: the agent identity, the instruction that triggered the action, the human or system that delegated the authority, the tool called, the parameters passed, the permission check performed, the outcome and the resulting state change. Model prompts and completions alone are debugging telemetry, not governance evidence.
Who is liable when an AI agent causes harm?
In current US practice, the deploying organization. Autonomy does not transfer liability, and no state statute creates an agent exemption. Where a vendor agent is involved, allocation depends on your contract, which is why agent-level logging obligations, model change notification windows and an explicit statement of who holds the human oversight duty belong in the agreement before deployment.
How many agents should require human approval before acting?
Approval gates should cover actions, not agents, and only those that are irreversible or high consequence: payments above a threshold, external customer communication, production changes and adverse decisions about individuals. In most enterprises that is a small fraction of total actions. High-volume reversible actions are better governed by sampling with a review service level and nightly reconciliation.
Final Takeaway
The organizations struggling with agents in 2026 are not struggling with the technology. They are struggling because they granted authority without defining it, then tried to govern the result with policies written for systems that only produced text. Agentic AI governance corrects that in a specific order: count the agents, give each one an identity, cap what it can do, decide where a human genuinely intervenes, and log the chain of authority behind every action.
Start with the count. Run the four discovery methods this week and compare the result against your risk register. The gap between those two numbers is your actual exposure, and it is usually the most persuasive thing you can put in front of a risk committee.
If you are building the capability formally, GAICC’s Agentic AI Governance Professional credential and the ISO/IEC 42001 certification pathways cover this control set in depth, from the management system through to agent-level implementation.
