Everyone is talking about AI governance. Boards are adopting AI policies. Legal teams are reviewing AI risk frameworks. Vendors are releasing AI governance platforms.
But when AI systems start acting in the world — booking meetings, executing code, calling APIs, making purchases — a different set of problems emerges. Principles and policies aren't enough. You need infrastructure.
That's agent governance.
What agents actually do
A language model that answers questions is a passive system. You ask; it responds. The worst outcome from a hallucination is a bad answer that a human might act on.
An AI agent is different. An agent has:
- Tools — the ability to call external APIs, write to databases, execute shell commands, send emails
- Memory — persistent context across interactions
- Autonomy — the ability to decide what to do next without asking for permission each step
When an agent has write access to production infrastructure, the worst outcome from a mistake isn't a bad answer — it's a deleted S3 bucket, a runaway credit card charge, or a disclosed customer record.
The governance problem scales with agency. The more an AI system can actually do, the more important it is to control what it's allowed to do, verify that it did what it claimed, and be able to stop it when something goes wrong.
The four pillars of agent governance
1. Identity
Which agent did this? Not "which user ran the agent," but which specific agent instance, at which version, with which toolset, operating on behalf of which principal chain?
Human identity is well-solved. We have OAuth, SAML, LDAP, Okta. Agent identity is not. Most organizations today track agents by the API key they were loaded with at startup — which conflates the agent's identity with a human administrator's credential.
A proper agent identity framework gives each agent definition a stable, cryptographically verifiable identifier. Each invocation gets a short-lived session credential derived from that root identity. The credential carries scope: what this agent is authorized to do in this session.
2. Authorization
Before an agent calls a tool or API, something needs to answer: is this agent allowed to perform this action on this resource, right now, given what we know about its trust level and context?
This is not the same as authentication. Authentication establishes who is calling. Authorization decides what they can do. Authorization is harder, because the answer depends on policy — and policy needs to be versioned, auditable, and changeable without redeploying your agent.
The standard pattern is a Policy Decision Point (PDP): a dedicated service that receives an authorization request ({ agent, action, resource, context }) and returns a decision (ALLOW, DENY, or REVIEW_REQUIRED). Every agent action passes through the PDP before executing.
3. Audit
After an agent acts, you need to be able to answer: what did it do, why was it allowed, and what was the state of the policy at the time?
This sounds simple. It's not. Most agent frameworks log what the agent did — tool calls, outputs, errors. They don't log why it was authorized to do it, what policy was active, what the trust score was, or whether a delegation chain was involved.
A governance-grade audit artifact contains:
- The agent's verified identity
- The action requested and the decision made
- The policy version that produced the decision
- A trust score and risk score at decision time
- A cryptographic signature so the record can't be altered after the fact
Without this, you cannot answer a compliance auditor's questions. You also cannot investigate an incident — because you don't know what the agent was authorized to do, only what it attempted.
4. Lifecycle
Agents need to be managed across their full operational lifetime: creation, testing, staging, production, suspension, and retirement.
Most teams manage this informally: there's a .env file with the API key, and when something goes wrong, someone revokes the key. That's not a lifecycle — it's a fire drill.
A governed lifecycle means:
- Agents are registered with verified metadata before they can operate
- State transitions are explicit and logged (active → suspended → retired)
- Suspension can cascade: revoking a parent agent immediately suspends all agents delegated from it
- Retirement leaves a tamper-proof historical record
Why this is different from general AI governance
General AI governance focuses on model-level questions: bias, fairness, explainability, output quality. These matter, but they're primarily about what the model says.
Agent governance focuses on infrastructure-level questions: what the agent does, what it's allowed to do, and what happens when something goes wrong. These are the same questions we've been answering in IAM and security for decades — but for a new class of system.
The good news is that the underlying patterns are well-understood. Identity, authorization, audit, and lifecycle management are solved problems for humans and services. The work is adapting those patterns to the constraints of autonomous agents: ephemerality, delegation, instruction-following, and scale.
What "not ready" looks like
Most organizations deploying agents today have one or more of these gaps:
- No agent identity — agents run with shared API keys or service account tokens; there's no way to distinguish one agent instance from another
- No authorization layer — tools are available to agents without runtime policy checks; the only control is what's in the system prompt
- No audit trail — logs capture what the agent called but not why it was authorized; incident investigation requires reconstructing context from scattered logs
- No revocation path — if an agent misbehaves, the only option is to kill the process and hope the damage is contained
If your organization has any of these gaps, your agents are operating outside your control. That's acceptable during exploration. It's not acceptable in production.
Getting started
The path to agent governance doesn't require rebuilding your stack. The minimal viable foundation:
- Register your agents — give each agent definition a stable identifier with verified metadata (model, toolset, deploying org)
- Add an authorization checkpoint — before every tool call, ask a PDP whether this agent is allowed to perform this action
- Emit signed audit artifacts — for every decision, record agent identity, action, decision, and policy version in a tamper-proof log
- Wire revocation — make sure you can suspend any agent instantly, with cascade to its delegated children
That's the foundation. Everything else — trust scoring, behavior analytics, access reviews, compliance reports — builds on top of it.
The Agent Governance Foundation maintains open protocols for agent identity, trust, and lifecycle. The AGF Authorization Service implements these protocols as a managed service. Get started with the quick-start guide →