Skip to main content
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.
Diagram of an agentic call path: Jane, a support engineer, asks her support copilot for a refund summary for ticket 4521. The copilot calls a planner agent, which branches to a research agent calling Zendesk MCP and Jira MCP, and a billing agent calling Stripe MCP. Labels note one human request, six machine-to-machine calls, and that only the first hop has a human behind it

One human request fans out into a tree of machine-to-machine calls — only the first hop has a human behind it

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:

Who is this call for?

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?

Who is making it?

Which agent, under what authority? A bearer token proves possession of a credential, not which of your two hundred agents is holding it.

What may it do?

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.
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:

​
Where to go next

Key concepts

The vocabulary: agent identity, delegation vs. impersonation, token exchange, ID-JAG, access control vs. guardrails.

The governance blueprint

The ideal end-to-end model: discover, register, authenticate, authorize every hop, audit and respond.

Implementing with TrueFoundry

How each pillar maps to TrueFoundry features — what works today and what is coming soon.

Identity provider scenarios

TrueFoundry as the identity broker, Okta, Okta for AI Agents, Microsoft Entra, and SPIFFE.