AI Agent Governance: Five Pillars You Build, Not Write

What agent governance is actually governing

Jane, a support engineer, types one sentence into a support copilot: prepare a refund summary for ticket #4521. The copilot hands it to a planner agent, which calls a research agent (Zendesk ticket, linked Jira bug) and a billing agent (Stripe payment record). One human request, six machine-to-machine calls, most made by software that decided on its own to call more software.

That chain — user → application → agent → sub-agent → MCP tool — is the agentic call path, and it is what agent governance has to control. Every enterprise access model rests on three assumptions: a user sits at the front of the request, the thing making the call is that user, and the scope is what the user consented to. By the third hop all three are false, so three questions stop having answers:

• Who is this call for? The user authenticated three hops ago. Is their identity still on the request, or did a service account replace it?
• Who is making it? A bearer token proves possession of a credential, not which of your two hundred agents holds it.
• What may it do? A token minted for the first callee is over-privileged for every callee after it.

Answering all three at every hop, with evidence, is what agentic AI governance means — five systems, not a paragraph on responsible use.

The agent is a third kind of principal

Most teams reach for one of two shortcuts: let the agent forward the user’s token, or give it a shared service account. Both are wrong, because an agent is neither.

Giving each agent its own verifiable identity is the decision everything else hangs off. It buys attribution, because the receiver can tell which agent called; per-agent policy, because Jane’s copilot reading Jira and her engineering agent writing to it are different principals even though both act for Jane; and no anonymous agents, because a tool reachable only by a registered identity makes registration the enforcement point.

The urgency is unglamorous: machine identities already outnumber human users in most enterprises by more than 40 to 1, and agents multiply faster than service accounts ever did — anyone with a framework and an API key can make one.

The five pillars

Complete governance is five capabilities in a loop. The first two run before an agent makes a single call, the middle two on every call, the last continuously — feeding back into the second.

Pillar 4 is where governance meets the wire. At each hop the gateway resolves the caller, checks whether this agent may call this target and may act for this user, mints a new token scoped to exactly the next callee, runs guardrails, then forwards and records. Three properties fall out for free: per-hop attribution, least-privilege tokens (a leaked one is good for one callee and one scope), and central revocation.

Why the gateway, not the IdP

Each pillar could live in a different tool. What holds the model together is enforcement at a gateway on the call path — the only component that sees every hop regardless of framework or cloud, carries identity forward, narrows authority at each step, and is platform-neutral. Entra governs Entra agents, Okta governs Okta apps, Bedrock governs Bedrock agents; the gateway governs the path across all of them, which is where the risk lives — a point we develop in governing AI agents across multiple platforms. An identity provider without a gateway issues perfect credentials that then get forwarded promiscuously; a registry without a gateway is documentation.

Where teams get this wrong

Treating the registry as a spreadsheet. A registry agents can ignore only inventories the agents you already knew about. It has teeth when it is the chokepoint: no registered identity, no call.

Forwarding one powerful token everywhere. The fastest way to make calls work and the fastest route to a breach. Agents can be prompt-injected into misusing whatever credential they hold, so it must never be broader than the next call needs.

Reviewing accounts instead of chains. Three agents in a procurement flow — one creates vendor records, one reads supplier banking data, one initiates payments — look acceptable alone. Chained, they form a payment path no reviewer would have approved: separation of duties, re-created by software.

Assuming an agent’s scope is static. A finance agent granted a new ERP module may start acting on data its scope never covered, not from a defect but because adapting is what agents do. Behaviour has to be compared with defined authority continuously, not quarterly.

Want this as a running system rather than a diagram?

Register an agent, give it an identity, and grant it one MCP server.

Get started free

The hard part: two answers to “who did this?”

When the research agent reads Jane’s Jira issues, the honest answer to who did this is both Jane and the research agent. Drop either and you lose something real. There are two ways to carry that on a token, and the choice decides whether you have an audit trail at all.

For agents you almost always want delegation. The delegated token keeps the user as sub and names the actor in act; chained calls nest the claims, outermost being the most recent actor:

{
  "sub": "jane@acme.com",
  "aud": "https://mcp.internal/jira",
  "scope": "issues.read",
  "act": {
    "sub": "agent:research-agent",
    "act": { "sub": "agent:planner-agent" }
  }
}

Two companion claims split the job. may_act is the forward-looking gate — may this actor act for this subject — checked before the token is minted. act records who actually did. Authorize on the current actor plus subject plus policy; keep the nested chain for forensics.

The mechanism underneath is token exchange. RFC 8693 defines it: present a subject token and optionally an actor token, receive a new token scoped to a target audience. Vendors call it On-Behalf-Of. One property is worth memorising — an exchange never amplifies authority. The issued token grants the intersection of what the user may do, what the agent may do, and what the target accepts, so every hop is more constrained than the last. Across trust domains the IETF’s ID-JAG grant (Okta’s Cross App Access) takes over, minting a short-lived grant at your IdP that the target’s own authorization server redeems.

How this works in TrueFoundry

TrueFoundry maps the five pillars onto product surfaces. Being plain about what exists today matters more than a complete-looking table, so availability is marked honestly.

The registry

Every agent gets an entry, whatever it runs on — Bedrock, Vertex, LangGraph, a custom HTTP service, an A2A agent, a copilot in someone else’s SaaS. Nothing moves, nothing is rewritten.

Registration is a four-step wizard: Metadata, Agent Identity, Config, Access Control.

Identity

Step two decides how the agent proves who it is. TrueFoundry-backed means TrueFoundry issues and signs the token, the right default for agents you run yourself. Identity provider-backed means the agent presents a token from Okta, Entra, any OIDC provider, or a SPIFFE/SPIRE endpoint, with claim values mapped to the agent.

The Config step decides whether the Agent Gateway sits in front. Proxy via Gateway means callers hit a TrueFoundry URL and the gateway authenticates, enforces and forwards. Embedded means governance-only: an identity and grants, no inbound proxying. That is how you govern a copilot inside a third-party product — you cannot control its front door, but its outbound calls still pass your gateways.

Agent access control

Access is allow-list based; there is no deny setting, because absence is the deny. Collaborators can be a user, a team, or another agent, with Agent Manager (view and edit) or Agent Access (invoke, and be acted for by it). Owner is a separate optional field that must be a team — the accountability anchor.

Note what that one list does: it defines both who may call the agent and whom the agent may act for. Granting it to the built-in everyone team hands the agent tenant-wide delegation reach — wider than most agents need.

The other direction works identically: add the agent as a collaborator on each MCP server or model, subject agent:<name>, in the same picker as users and teams.

To restrict an agent to a subset of a server’s tools, curate that subset as a Virtual MCP Server and grant access to that instead; per-agent tool scoping on the grant is coming.

Guardrails, at every hop

Access control decides whether a call happens. Guardrails decide what it may contain, and are indifferent to who is calling. Agents raise the stakes for one reason: a chatbot with a bad response embarrasses you, an agent with a bad response acts on it. Every tool result re-enters the model’s context and can carry an injection, so inputs need checking even when the user is trusted.

A workable baseline: PII redaction and prompt-injection detection on LLM input, secrets detection on output, SQL sanitizer and code-safety linter pre-tool, redaction post-tool. Start every rule in Audit mode, then promote — one blocked hop can fail a whole chain.

Audit

Because enforcement and observation happen in the same place, the trail is complete by construction. Each trace records which agent made the call and which user it acted for — both halves of the two-answer problem.

Every guardrail that ran appears as its own span: what it checked, whether it passed, what it found or redacted. Blocked requests are logged too — a denied hop is evidence, not a gap.

Above the traces, one dashboard covers every registered agent wherever it runs: request counts, latency percentiles, error rates, usage over time. Drift detection and anomaly alerts build on this and are coming soon.

A worked example

Govern the refund-summary copilot from the top of this post.

Register the agents. Planner, research and billing each get an entry with a description and an Owner team. The vendor copilot is registered Embedded — no URL, governance only, but its outbound calls are now governed.

Give each an identity. TrueFoundry-backed for the three you run; the embedded copilot points at your IdP, claim value mapped.

Grant least privilege, both directions. On the research agent, add the support team with Agent Access — both who may invoke it and whom it may act for. Then add agent:research-agent as a collaborator on the Zendesk and Jira MCP servers, and nothing else. Billing gets Stripe. Neither reaches the other’s tools, because absence of a grant is a 403.

Carry identity on every call. A delegated call carries two bearer tokens: the user in Authorization, the agent in x-tfy-agent-authorization. Each agent swaps in its own agent header and passes the user’s token through, so the gateway checks every hop against the agent actually making it.

Turn on guardrails and watch. Attach prompt-injection detection to the models and post-tool redaction to the servers, then confirm in Request Traces that a research-agent call shows research-agent as caller and Jane as the user it acted for.

One honest limit: today the user’s token passes through alongside the agent header rather than being exchanged for a fresh audience-scoped token at each hop. Full per-hop exchange is coming soon.

Ready to put an agent behind a real enforcement point?

Register it, scope it to one MCP server, and read the trace.

Start free on TrueFoundry

Gotchas worth knowing

An agent cannot complete an OAuth2 authorization-code flow. There is no human to approve the consent screen, and the token would belong to that person anyway. Such a server returns MCP server authentication required for an agent token even when the agent is a collaborator. Use client credentials instead.

Output guardrails are skipped on streamed responses. They need the complete response to evaluate, so for agent steps whose output feeds a tool call, prefer stream: false.

The agent’s token is the agent. Keep it out of source control and out of anything the model can read back. An agent that can be prompted into disclosing its own token can be impersonated.

Related reading

• Governing AI Agents Across Multiple Platforms — when governance stops at the platform edge
• Graph Engineering for AI Agents — evaluating the node versus governing the edges
• MCP Access Control with an MCP Gateway — tool- and server-level permissions
• RBAC vs ABAC for AI Agents — the access model underneath the grants
• Building an AI Governance Framework — the wider policy picture

Conclusion

Most writing on enterprise AI agent management treats governance as a drafting exercise: define acceptable use, assign a committee, publish the standard. None of it survives the third hop of a call path, where the question is not whether an action was appropriate but whether your infrastructure can say who took it.

The five pillars are useful precisely because each names a system rather than a principle. Discovery is a scanner. Registration is a database the gateway refuses to bypass. Authentication is two credentials on a request. Authorization is a grant that returns 403 when absent. Audit is a trace with both the agent and the user on it. Build those and the hard question — who did this, and on whose behalf — has an answer you can point at.

Govern your first agent on TrueFoundry

Free to start