What Are Governed AI Agents?
A governed AI agent is an AI agent operated as a first-class principal: it holds its own workload identity, receives scoped and ephemeral credentials, carries an autonomy tier assigned per action, and leaves a full audit trail that makes every action attributable and reversible.
An agent is governed when those four properties hold at runtime rather than in a policy document. The agent authenticates as itself through platform attestation, so every action resolves to a named principal and a specific build instead of a shared service account. Its credentials are issued by a broker, scoped to the task in front of it, and expire in minutes, so a compromised agent holds very little for very long. Every action it can take carries an autonomy tier: read-only work runs freely, reversible internal writes run under sampled review, and anything touching money, people, or legal commitments is blocked until a named human approves the exact parameters. An append-only ledger records the triggering input, the principal chain, the tool call, the policy verdict, and the result, so an auditor or an incident responder can reconstruct what happened without engineering help.
Most enterprise AI agents fail that test. They run under a shared service account with broad standing permissions, no per-action logging, and no named owner. They demo well and stall in production, not because of the model, but because nobody can answer the three questions a security reviewer asks: which agent did this, what was it allowed to do, and how do we stop it.
What makes an AI agent governed?
Governance is four load-bearing mechanisms, each of which fails independently.
- Identity. Each agent is its own principal with an attested workload identity rather than a shared key. SPIFFE defines the identity format and SPIRE is its production implementation: a SPIRE agent verifies the node and then the workload through attestation, and issues a short-lived SVID that rotates automatically. Identity is derived from what the platform observes, not from a secret the agent stores, so there is no API key to leak into a log or exfiltrate through a prompt. The full stack is covered in workload identity for AI agents.
- Scoped, ephemeral credentials. Credentials are broker-issued, audience-bound, and near task duration in lifetime. OAuth 2.0 Token Exchange (RFC 8693) carries user context alongside agent identity, producing an
actclaim that records the delegation chain, so a downstream system authorizes the user and the agent together instead of trusting a broad service principal. Sender-constrained tokens (mTLS binding under RFC 8705, or DPoP) close the replay gap where the target supports them. - Tiered autonomy. Autonomy is a property of the action, not of the agent. The same agent should be free to search an index, supervised when it updates an internal record, and hard-stopped from issuing a refund.
- Attributable audit trail. Every consequential action is written to an append-only ledger with the principal chain, the tool and parameters, the policy decisions, and the result. Denied calls and guardrail blocks are recorded too, because during an incident what the agent tried to do is often more informative than what it managed.
How are autonomy tiers assigned?
Tiers attach to a tool and its parameters, not to a tool alone. The classification rule that resolves most arguments is simple enough for a non-engineer to apply: any action that moves money, affects a person, or creates a legal commitment is human-gated, with no exceptions for volume or deadline pressure. Everything else is sorted by reversibility.
| Tier | What the agent may do | Enforcement point | Example action |
|---|---|---|---|
| T1 autonomous | Read and report, no state change outside its own scratch space | Executes and logs | Query a vector index, read a ticket, run a report |
| T2 supervised | Reversible writes to internal systems of record inside scoped credentials | Pre-checks, then execute, log, and sample for human review | Update a ticket status, post an internal summary, commit behind a feature flag |
| T3 human-gated | Propose only; a named approver releases the exact parameters | Blocked at the tool gateway until approval, timeout defaults to deny | Send a customer message, change a permission, apply a fee, delete unrecoverable data |
Two implementation details decide whether the table is a control or a wish. The tier must be resolved outside the model, in a tool gateway that checks every call in deterministic code, because a tier stated in a system prompt is a suggestion an injected instruction can talk past. And the gateway, not the agent process, holds the credentials for gated systems, so an agent that decides to call a blocked tool has nothing to call it with. The classification and enforcement patterns are worked through in the autonomy tiers guide.
What evidence does a governed agent have to produce?
The core artifact is a session ledger: one append-only record per agent session, from the triggering request to the final response. Each event carries a hash of the previous event, so editing history breaks the chain visibly, and the ledger is written to storage the agent itself cannot modify. Payloads are stored by hash with the content held in access-controlled storage on its own retention clock, which keeps the ledger queryable for years while sensitive material expires on schedule.
Attribution rests on a principal chain recorded on every action: the human or system that initiated the session, the specific agent name and version acting, and the credential used for the call. Agent identity is versioned, so a new prompt or model produces a new identity string and behaviour is attributable to a specific build. Session identifiers propagate into downstream systems, giving correlation from either direction.
A stop mechanism has to exist at more than one level, because a single switch that shuts everything down is one nobody pulls in time. Four levels work: pause intake so running sessions finish, freeze writes while reads continue helping responders, revoke credentials at the identity provider so enforcement happens outside the agent process, and finally scale to zero. Triggering any level is itself a ledger event. The design detail sits in audit trails for AI agents.
Governed versus ungoverned: what actually changes
| Property | Ungoverned agent | Governed agent |
|---|---|---|
| Identity | Shared service account | Attested per-agent principal, versioned |
| Credentials | Long-lived static key with standing privilege | Broker-issued, audience-bound, task-scoped, minutes to live |
| Authorization | Agent identity only | Agent and on-behalf-of user, evaluated per call |
| Autonomy | All or nothing | Per action, enforced at the tool gateway |
| Evidence | Application logs under one service identity | Append-only session ledger with principal chain |
| Containment | Full shutdown, or nothing | Four graded kill-switch levels, drilled |
| Review outcome | Security blocks it | Security can approve it |
What does governance cost to run?
Governance is not free, and pretending otherwise is how programmes get sold and then abandoned. The real costs are a credential broker somebody operates, an approval queue somebody staffs, an evaluation suite that gates prompt and model changes, and single-digit milliseconds of gateway latency on every tool call. The failure mode to watch for is review load: an approval that humans click through without reading is worse than no approval, because it manufactures false audit evidence. Median time to decision measured in seconds with a total approval rate is the signature, and the fix is to move high-volume medium-risk work into the supervised tier with automated pre-checks rather than to weaken the gate.
Against that, governance is what makes the deployment expandable. Regulated buyers in healthcare, financial services, government, and energy run AI through the same review as any other production system, and the evidence a governed agent produces maps cleanly onto ISO/IEC 42001 and the NIST AI Risk Management Framework, as set out in the ISO 42001 and NIST AI RMF mapping. Teams that build the controls first walk into the approval conversation with artefacts instead of promises, which is the point made in how to get AI agents through enterprise security review.
How does Citadel build governed agents?
Citadel runs SIAS, a catalog of 506 governed AI agents across 8 domains, each engineered around these four properties and grounded in your own corpora inside your tenancy. Agents are designed, secured, hosted, and monitored by Citadel, and you set the autonomy tier per agent and per action. The identity plane, the credential broker, the tool gateway, and the session ledger are platform services every agent consumes rather than things each team rebuilds. See enterprise AI agents, AI agent security, and zero trust for AI for how the pieces fit, and LLMOps vs MLOps for the operational discipline underneath them.
Start with an assessment
The Agent Assurance Assessment is a fixed-scope, fixed-price three-week engagement that inventories the agents already running in your environment, maps them to NIST AI RMF and ISO/IEC 42001, and leaves one governed agent running on a real workflow. If you want the control set first, the Enterprise AI Agent Blueprint is a free governance guide covering identity, credentials, autonomy tiers, audit, and shutdown. To talk it through, book a discovery call or read the enterprise consulting overview.