> ## 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.
# The Agent Governance Blueprint
> The ideal end-to-end model for governing every agent: discover, register and own, authenticate, authorize and scope every hop, then audit and respond.
This page describes the target model — what complete agent governance looks like, independent of any product. It assumes the [key concepts](/docs/agent-platform/agent-governance/key-concepts); the [next page](/docs/agent-platform/agent-governance/truefoundry-implementation) maps each piece onto TrueFoundry.
## Five pillars
Complete governance is five capabilities arranged in a loop. The first two happen before an agent makes a single call; the middle two run on every call; the last one runs continuously across all of them.
### 1. Discover: you can't govern what you can't see
Agents appear wherever teams can run code: cloud accounts, SaaS platforms with embedded copilots, developer laptops, CI pipelines. Discovery means continuously scanning those surfaces to build one inventory — including the **shadow agents** nobody declared — and flagging anything that is acting but not registered.
| Surface | What discovery finds there |
| --------------------------------- | -------------------------------------------------------------------------- |
| Cloud platforms (AWS, Azure, GCP) | Bedrock/Vertex/Foundry agents, service principals used by agent frameworks |
| SaaS applications | Embedded copilots, Agentforce-style platform agents |
| Identity providers | OAuth clients and service accounts whose traffic patterns look agentic |
| Gateway traffic | Callers hitting models and MCP servers without a registered agent identity |
| Endpoints and repos | Local MCP configurations, agent frameworks in code |
Discovery is a funnel, not a one-time census: found → triaged (owner assigned, purpose identified) → registered, and anything that skips the funnel gets denied at pillar 3.
### 2. Register and own: registration is the enforcement point
Every agent — however it was built, wherever it runs — gets a registry entry that carries four things:
The credential the agent presents on every call. Issued by the platform, by your identity provider, or attested from the workload's runtime (SPIFFE).
A human or team that answers for the agent from creation to retirement.
The tools and data it may reach, the actions it may take, and whom it may act for — the boundary all behavior is measured against.
Credential rotation and expiry, periodic re-certification, and a deprovisioning path.
The registry only has teeth if it is also the **chokepoint**: an agent that cannot present a registered identity cannot reach any model, MCP server, or other agent. That single rule converts the registry from documentation into enforcement — nothing acts anonymously, and the inventory is complete by construction.
### 3. Authenticate: resolve every identity on every call
At each hop, the enforcement point resolves *all* identities present — the user the request is for, and the agent making the call. They are different principals and both matter. Two refinements harden this in production:
* **Per-agent vs. per-instance.** The registered identity is the stable principal you govern. Each running *instance* can additionally carry a short-lived attested credential (a SPIFFE SVID) bound to that identity — giving you a surgical kill switch for one rogue instance without invalidating the fleet.
* **Sender-constrained tokens.** A bearer token can be replayed by whoever steals it — a real risk for agents that can be prompt-injected. Where the target supports it, bind tokens to the sender with mTLS ([RFC 8705](https://www.rfc-editor.org/rfc/rfc8705.html)) or DPoP ([RFC 9449](https://www.rfc-editor.org/rfc/rfc9449.html)).
### 4. Authorize and scope: the per-hop loop
This pillar is where governance actually meets the wire, and it is a fixed five-step loop the gateway runs at **every** hop of the agentic call path:
Resolve the user and the calling agent from the credentials on the request. No registered identity, no call.
Evaluate access control *before any token is minted*: may this agent call this target? May it act on behalf of this user? Is this specific tool within the agent's allowed scope? Attribute-based rules (time of day, chain depth, environment) layer on top.
Mint a new token scoped to exactly the next callee — user as `sub`, agent(s) in `act`, scope narrowed to the minimum the next hop needs. [OBO](/docs/agent-platform/agent-governance/key-concepts#within-one-trust-domain-on-behalf-of-rfc-8693) within a domain, [ID-JAG](/docs/agent-platform/agent-governance/key-concepts#across-trust-domains-id-jag--cross-app-access) across domains, or a gateway-issued scoped token when the target can't participate in exchange. Never forward a token unchanged.
Run content guardrails — pre-tool checks on the request (PII, prompt injection, unsafe arguments) and post-tool checks on the response (secrets, redaction).
Forward the scoped token to the callee — which enforces its own policy on top — and record the hop: subject, actor chain, decision, scopes.
Watch the token transform across a real path — a planner agent, acting for Jane, calls a research agent, which calls the Jira MCP server:
| Hop | Subject (`sub`) | Actor chain (`act`) | Audience (`aud`) | Scope |
| ------------------- | --------------- | ------------------- | ---------------- | -------------------- |
| Jane → Planner | Jane | — | Planner | (full user context) |
| Planner → Research | Jane | Planner | Research agent | narrowed to Research |
| Research → Jira MCP | Jane | Research → Planner | Jira MCP | `issues.read` only |
```mermaid theme={"dark"}
sequenceDiagram
participant Jane as User Jane
participant GW as Gateway
participant STS as IdP / Authorization Server
participant Research as Research Agent
participant Jira as Jira MCP
Jane->>GW: Summarize my open Jira issues
GW->>GW: Planner may act for Jane? may call Research?
GW->>STS: Exchange sub=Jane act=Planner aud=Research
STS-->>GW: Delegated token audienced to Research
GW->>Research: Forward request
Research->>GW: Call Jira tool as Research, for Jane
GW->>GW: Research allowed on Jira? may act for Jane? tool in scope?
GW->>STS: Exchange sub=Jane act=Research,Planner aud=Jira scope=issues.read
STS-->>GW: Scoped delegated token
GW->>Jira: Forward with scoped token
Jira->>Jira: Validate and enforce Jane's permissions
Jira-->>GW: Jane's open issues
GW-->>Jane: You have 4 open issues
```
Because every hop is an explicit, authorized exchange, three properties fall out for free: **per-hop attribution** (who did what, for whom, through which path), **least-privilege tokens** (a leaked token is good for one callee and one scope), and **central control** (who-can-call-what lives in one place, revocable instantly).
### 5. Audit and respond: close the loop
Every hop the gateway forwards, it also records — which turns governance from a policy document into an operational system:
| Capability | What it answers |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| **Unified audit trail** | "Which agent did this, on whose behalf, through which chain?" — one record across all frameworks and clouds. |
| **Drift detection** | Is the agent's actual behavior still inside its defined authority? Divergence triggers constraint or suspension and notifies the owner. |
| **Kill switch** | Revoke one agent (or one instance) instantly, without touching anything else. |
| **Certification campaigns** | Owners periodically re-attest that grants still match purpose — with usage data showing which grants are actually exercised. |
| **Decision evidence** | Auditor-ready proof, produced as agents operate, that every action mapped to an authorized scope. |
## Why the gateway is the enforcement point
Each pillar could in principle live in a different tool. What makes the model coherent is placing enforcement at a **gateway on the call path**, because it is the only component that:
* **sees every hop** — agents, sub-agents, and tools all pass through it, regardless of framework or cloud;
* **can carry identity forward** — it drives the token exchange at each hop, so the user is never lost and the actor chain always grows;
* **can narrow authority at each step** — it mints the scoped credential for exactly the next callee;
* **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 actually lives.
An identity provider without a gateway can issue perfect credentials that are then forwarded promiscuously. A registry without a gateway is documentation. The gateway is what makes both of them enforceable.
## A maturity model
Use this to locate where you are and what to build next. Each level is useful on its own; each is a prerequisite for the next.
| Level | Name | What it looks like | Key risk remaining |
| ----- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| 0 | **Ungoverned** | Agents share user tokens and service-account keys; no inventory. | Everything on the [risk list](/docs/agent-platform/agent-governance/overview#the-risks-concretely). |
| 1 | **Inventoried** | Every agent is registered with an identity and an owner; gateway requires registration to act. | Agents are known but over-privileged; user identity still lost across hops. |
| 2 | **Least-privileged** | Per-agent grants on every target and tool; delegation rules define whom each agent may act for; guardrails on content. | Tokens still broad within a grant; attribution is per-call, not per-chain. |
| 3 | **Fully attributed** | Token exchange at every hop: subject preserved, actor chain recorded, scope narrowed; unified audit and kill switch; drift detection and certification running. | Residual risk shifts to model behavior itself — which guardrails and human-in-the-loop address. |
Level 1 is achievable in a day and removes the largest risk (anonymous agents). Levels 2 and 3 are incremental — nothing at a lower level has to be redone.
## Next
See [Implementing agent governance with TrueFoundry](/docs/agent-platform/agent-governance/truefoundry-implementation) for how each pillar maps to product features — including which are available today and which are coming soon — and the [identity provider scenarios](/docs/agent-platform/agent-governance/scenarios/truefoundry-identity-broker) for how the model lands on TrueFoundry-brokered identity, Okta, Microsoft Entra, and SPIFFE.