> ## Documentation Index
> Fetch the complete documentation index at: https://www.truefoundry.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Why Agent Governance
> Why AI agents break the enterprise access model, the risks that appear the moment agents call other agents and tools, and the questions governance must answer.
A year ago, "an AI feature" meant one model behind one API key. Today it looks like this: Jane, a support engineer, types one request into her support copilot — *"Prepare a refund summary for ticket #4521."* The copilot's planner agent delegates to a research agent, which pulls the ticket from Zendesk and the linked bug from Jira, and to a billing agent, which fetches the payment record from Stripe. One human request fans out into six machine-to-machine calls — each agent and MCP server possibly owned by a different team or a different vendor, and most of the calls made by software deciding, on its own, to call more software.
Call this chain — **user → application → agent → sub-agent → … → MCP tool** — the **agentic call path**. It is the unit that agent governance has to control, and every page in this section returns to it.
## What breaks
Every enterprise access model was built on one assumption: there is a **user** at the front of every request, the thing making the call **is** that user, and the scope of the call is what the user **consented** to. The agentic call path breaks all three at once. By the third hop, these questions have no clear answer:
Whose data, whose permissions? The user authenticated three hops ago — is their identity still on the request, or has it been replaced by a service account?
Which agent, under what authority? A bearer token proves possession of a credential, not which of your two hundred agents is holding it.
What scope? A token minted for the first callee is over-privileged for every callee after it.
Answering all three — at *every hop of the agentic call path*, with a complete audit trail — is what agent governance means.
## The risks, concretely
Each of these appears the moment teams go from two agents to twenty, and each maps to a control in the [governance blueprint](/docs/agent-platform/agent-governance/governance-blueprint).
Teams build agents on whatever they like — LangGraph, CrewAI, Bedrock, a homegrown HTTP service, a copilot embedded in a SaaS product. Nothing forces them to declare those agents anywhere, so security has no inventory of what exists, who owns it, or what it can reach.
**Example:** a growth team ships a CrewAI agent that queries the Salesforce MCP server with a shared API key. It works — and no central system knows the agent exists, so it can't be discovered, audited, rate-limited, or shut off.
When an agent forwards the user's token or impersonates the user, downstream logs show only "the user". When it uses a shared service account, logs show only "a service". Either way, "the retrieval agent leaked data" becomes impossible to prove after the fact.
Agents don't just hold access — they **assemble** it on the fly through delegation. Consider three agents in a procurement flow: one creates vendor records, one retrieves supplier banking data, one initiates payments. Each looks acceptable alone. Chained together they form an end-to-end payment path that no human reviewer would ever have approved — and no single system saw the whole chain, because each only sees the activity inside its own boundary.
This is the separation-of-duties problem, re-created by software. Governance has to see and review the **delegation chain end to end**, not each account in isolation.
The user authenticates to the first agent, but that agent calls a second agent, which calls an MCP server. Unless identity is deliberately carried forward, the MCP server sees nothing (and fails) or a shared service account (and over-grants). Per-user permissions, audit trails, and data isolation all collapse.
**Example:** a planner agent calls a research agent that reads Confluence for Jane. By the second hop "Jane" is gone, so the research agent reads with a service account that can see *everyone's* pages.
The simplest way to make calls work is to forward one powerful token everywhere — and the fastest way to a breach. A token minted for "Jane, in the planner agent" should not be replayable by a downstream agent against an unrelated MCP server. Agents can be prompt-injected into disclosing or misusing whatever credential they hold, so the credential must never be broader than the single next call needs.
Unlike a service account, which runs against a fixed configuration, an agent adapts at runtime: it interprets context, selects tools, and chains actions. A finance agent given access to a new ERP module may start acting on data its scope never covered — not because of a defect, but because agents do what they were designed to do in environments that change underneath them. Behavior has to be compared against the agent's defined authority continuously, not at quarterly reviews.
When something goes wrong you need to answer "which agent did this, on whose behalf, through which chain?" and revoke a single agent instantly — without taking everything else down, and without grepping through five frameworks' logs to reconstruct what happened.
## Why this is urgent
* **Non-human identities already dominate.** In most enterprises, machine identities outnumber human users by more than 40:1 — and agents multiply faster than service accounts ever did, because anyone with a framework and an API key can create one.
* **Agents are identities that make decisions.** A service account does what its configuration says. An agent interprets an objective and picks its own path — including, in documented incidents such as the 2025 Comet browser prompt-injection demonstration, a path an attacker wrote into a webpage. Identity governance can't stop prompt injection, but it is what stops the *chain of unauthorized actions that follows*.
* **Regulators are converging on the same expectation.** The EU AI Act, NIST's AI Risk Management Framework, and the OpenID Foundation's work on agentic identity all point one direction: organizations must produce documented, traceable evidence that every agent action stayed within an authorized boundary — as agents operate, not reconstructed after the fact.
* **Every platform is building its own agent identity silo.** Microsoft has Entra Agent ID, Okta has Okta for AI Agents, AWS Bedrock and Google both issue their own agent principals. Each governs agents inside its own ecosystem — and none governs agents running on the others. An agent that starts a task in Salesforce, calls a tool in AWS, and writes back through Microsoft Graph leaves a chain no platform-native registry can reconstruct. You need a control layer that is independent of any one platform.
## The five questions governance must answer
Everything in this section exists to make these five questions answerable at any moment, for every agent, with evidence:
| # | Question | The control that answers it |
| - | ------------------------------------ | --------------------------------------------------------------------------------------------------------- |
| 1 | **What agents exist?** | Discovery and a mandatory registry — nothing acts without a registered identity. |
| 2 | **Who is accountable for each one?** | A human owner and a defined authority scope recorded at registration. |
| 3 | **What can each agent reach?** | Least-privilege grants per agent, per target, per tool — not inherited from a user or a shared account. |
| 4 | **On whose behalf is it acting?** | Delegation that carries the user across every hop and records every acting agent. |
| 5 | **What did it actually do?** | Per-hop audit of subject, actor chain, decision, and scope — plus a kill switch when the answer is wrong. |
## Where to go next
The vocabulary: agent identity, delegation vs. impersonation, token exchange, ID-JAG, access control vs. guardrails.
The ideal end-to-end model: discover, register, authenticate, authorize every hop, audit and respond.
How each pillar maps to TrueFoundry features — what works today and what is coming soon.
TrueFoundry as the identity broker, Okta, Okta for AI Agents, Microsoft Entra, and SPIFFE.