AI Agent Governance: A Complete Business Guide

A survey of enterprises published in early 2026 found that only around 28% could trace agent actions back to a human sponsor across all their environments.

In roughly three-quarters of organisations, AI agents are taking actions with valid credentials and no accountable principal. When the security team asks who owns the agent that just attempted an unauthorised access, the honest answer is frequently nobody — and that answer fails every compliance framework it encounters.

This guide covers what agent governance actually consists of, why existing identity programmes do not cover it, and how to implement it without stopping deployment.

AI Governance and Agent Governance Are Different Problems

The distinction that most organisations get wrong, and it determines whether your controls work.

AI governance evaluates model outputs — accuracy, bias, hallucination, appropriateness. It is a content review problem, and most enterprise AI policies are built for it.

Agent governance controls agent actions — which systems the agent reaches, which operations it can perform, under what conditions a human must approve. It is an access control problem.

An agent that produces a perfectly accurate, unbiased recommendation and then executes it against a production database using inherited credentials nobody can trace has passed your AI governance review and failed everything that matters.

Content-review controls applied to an access-control problem is the single most common structural mistake in this field.

Why Existing IAM Does Not Cover It

Three reasons your identity programme was not built for this.

Scale. Non-human identities now substantially outnumber human ones in most enterprises, with ratios commonly cited anywhere between 40:1 and 100:1. Identity governance programmes designed around employee lifecycles do not operate at that magnitude.

Speed. A developer creates an agent in hours. A governance programme reviews it in months. By the time review completes, the agent has been in production for a quarter.

Architecture. Early agent deployments typically make one of two mistakes:

• Treating the agent as a service account. A long-lived principal with broad permissions. This works technically and destroys user-level accountability — every action appears as the agent’s, with no record of whose authority it was exercising.
• Treating the agent as user impersonation. Handing the agent the user’s actual token. Now agent actions and human actions are indistinguishable in your logs, which is precisely what auditors will ask you to separate.

The correct model is neither: a distinct identity for the agent, carrying a traceable link to the human authority under which it acts.

The Five Controls

Agent governance reduces to five things. Everything else is implementation detail.

1. Identity. Every agent gets its own identity and one named human custodian. No shared API keys across agents, no generic service accounts, no credentials inherited from a departed employee.

2. Permissions. Least privilege, scoped to the task rather than the system. An agent that reads invoices does not need write access to the ledger because both live in the same platform.

3. Approval thresholds. Define which actions execute autonomously, which require human approval, and where the boundary sits. Monetary limits, data sensitivity, and irreversibility are the usual axes.

4. Logging. Records that distinguish agent actions from human actions, capture which authority the agent acted under, and survive long enough to satisfy your retention obligations.

5. Termination. A defined path to revoke credentials and stop an agent, tested rather than assumed. If the answer to “how do we turn this off at 2am” is unclear, the agent is not governed.

Anchor to a Recognised Framework

Building from scratch is unnecessary. Four references are most useful, and anchoring to them helps with both internal alignment and external audit.

Two developments worth tracking. NIST launched an AI Agent Standards Initiative in February 2026, with an accompanying concept paper stating the gap plainly — agents are commonly treated as generic service accounts without dedicated identity, authorisation, or accountability controls. And Singapore’s IMDA published a Model AI Governance Framework for Agentic AI in January 2026, the first comprehensive framework of its kind, requiring each agent to carry a verifiable digital identity and an audit trail of which agent acted under whose authorisation.

For EU exposure specifically, Article 12 (logging) and Article 14 (human oversight) of the AI Act are the provisions most directly relevant to agent design. High-risk obligations for standalone Annex III systems apply from 2 December 2027 following the Digital Omnibus adopted in June 2026.

Nobody Governs Across Platforms

A structural problem worth planning around rather than discovering.

Microsoft, Salesforce, ServiceNow, Amazon, and Google have each introduced their own model of agent identity, credentials, and tool authorisation. Each is necessary for governing agents inside its own ecosystem.

None of them governs agents running on the others.

If your agents span platforms — and at any scale they will — platform-native controls give you several partial views and no complete one. You need an inventory layer above them, which in practice means extending your existing identity governance catalogue to include agents rather than relying on each vendor’s console.

Find the Agents You Do Not Know About

Shadow agent deployment is the norm, not an exception, because deploying one is faster than requesting permission.

Detection requires combining four signals, since no single source is sufficient:

1. OAuth grant records in your identity provider
2. SaaS and AI application spend in finance data
3. Admin logs from agentic platforms you already license
4. Browser-level signals for platforms with no admin API

Detection alone does not solve it. The durable fix is a sanctioned path that is fast enough that developers and business users have a reasonable alternative to going around you. A governance programme that takes three months to approve an agent guarantees shadow deployment.

Orphaned Agents

A specific failure mode worth naming.

An orphaned agent is one whose accountable human owner has left the organisation or can no longer be identified, while its credentials remain active. It continues executing actions with valid permissions and nobody to justify them.

This is simultaneously a security exposure and a direct audit finding under standard access control requirements. The scale of the underlying problem is visible in credential hygiene data: research on non-human identity risk found millions of leaked credentials on public code repositories, with a substantial proportion of older ones still valid years later.

The fix is process, not technology. Agent ownership must be part of your joiners-movers-leavers workflow. When someone leaves, their agents need reassignment or termination in the same sweep as their accounts.

What Auditors and Buyers Will Ask

The commercial pressure is arriving from two directions.

Procurement. Enterprise buyers began asking vendors directly about their agent authentication story in 2025. By 2026 it has become a table-stakes question rather than a differentiator. Any B2B product allowing customers’ agents to act on their behalf needs registered OAuth clients, scoped short-lived tokens, per-task authorisation, and logs that distinguish agent actions from human ones.

Audit. Practitioners widely expect explicit agent access control findings to start appearing in standard audit procedures. The documentation is cheap to produce now and expensive to reconstruct retroactively after the first audit cycle asks for it.

A Phased Implementation

1. Inventory. Combine the four detection signals. You cannot govern what you have not found, and the count will surprise you.
2. Assign ownership. Every agent gets a named human custodian. Anything unclaimed is a candidate for termination.
3. Scope permissions down. Start with your highest-privilege agents. Over-privileged identities and long-lived secrets are the two most exploited weaknesses in this class.
4. Instrument logging. Ensure logs distinguish agent from human action and record the authority chain.
5. Define approval thresholds by risk, not uniformly.
6. Test termination. Actually revoke an agent in a controlled exercise.
7. Fold agents into access reviews on the same cadence as human accounts.

Do Not Govern Uniformly

One caution. Applying identical controls to a low-risk retrieval agent and one that touches customer records either over-restricts the first or under-protects the second.

Tier by what the agent can do — data sensitivity, action reversibility, financial exposure, and whether it operates customer-facing. Uniform governance is what produces both stalled low-risk projects and unmonitored high-risk ones.

Final Thoughts

Agent governance is not a new discipline so much as an existing one applied to a population it was never sized for.

The five controls are unglamorous: identity, permissions, thresholds, logging, termination. What makes them urgent is that agents are being deployed considerably faster than governance is being extended, and the accountability gap that creates is already visible in the audit data.

Start with the inventory. Most organisations do not know how many agents they are running, and that number is the beginning of every other answer.