> ## 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.
# Agent Governance Key Concepts
> The vocabulary of agent governance: actors on the call path, agent identity, delegation vs. impersonation, token exchange, ID-JAG, access control, and guardrails.
This page builds the shared vocabulary the rest of the section relies on. Read it once; every later page links back here instead of re-explaining.
## The actors on the call path
Be precise about the entities first — everything downstream is easier.
| Actor | What it is | Identity it carries |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| **End user** | A human initiating a request (a chat, a click, an IDE action). | An SSO / OIDC identity from the enterprise identity provider. |
| **Application** | Conventional software the user signs into — a SaaS product, an internal app, an IDE. | Its own OAuth client identity; forwards the user's identity. |
| **Agent** | An autonomous actor that plans and calls other agents or tools on the user's behalf. | Its **own** verifiable identity, distinct from the user's. |
| **Sub-agent** | An agent invoked *by another agent* to do part of the work. | Its own identity; one more link in the actor chain. |
| **MCP server / tool** | The resource at the end of the path — a [Model Context Protocol](https://modelcontextprotocol.io/) server wrapping an API, database, or SaaS system. | Validates the token it receives and enforces its own policy. |
## Agent identity: a third kind of principal
Most teams let an agent act as "the user" (forwarding the user's token) or as a shared service account. Both are mistakes, because an agent is neither — it is a *third kind of principal* that needs its own first-class, verifiable identity.
| | User | Service account | Agent identity |
| --------------- | -------------- | ------------------------------ | ----------------------------------------------------------------------------------- |
| Represents | A person | A fixed service or application | A registered agent |
| Acts as | Itself | Itself | Itself, **or on behalf of a user or service** |
| Behavior | Human judgment | Fixed configuration | Autonomous — interprets context, picks tools, chains calls |
| Governance need | SSO, RBAC | Credential rotation, inventory | All of that, **plus** delegation rules, ownership, per-hop attribution, kill switch |
That one decision — a distinct identity per agent — unlocks the whole model:
* **Attribution.** The receiver of a call can tell whether the caller is a human, a service, or *which* agent — so actions are provable after the fact.
* **Per-agent policy.** One user drives many agents, and they should not all inherit the user's full reach. Jane's support copilot reading Jira and her engineering agent writing to it are *different principals*, even though both act for Jane.
* **No anonymous agents.** If an agent can only reach a tool by presenting a *registered* identity, registration becomes the enforcement point — you get an org-wide inventory for free, and you can revoke one rogue agent without touching the rest.
## Ownership and defined authority
An identity says *which agent*; governance also needs *who answers for it* and *what it was authorized to do*. Every registered agent should carry:
| Attribute | What it records |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| **Owner** | The accountable human or team — from creation to retirement. |
| **Business purpose** | Why the agent exists, in one sentence. |
| **Defined authority** | The tools and data domains it may touch, the actions it may and may not take, and the users or services it may act for. |
| **Review cadence** | When the scope is re-certified against actual behavior. |
The defined authority is the reference point everything else is measured against: delegation requests, runtime behavior, and audit evidence. Without it there is no declared boundary to compare against.
## Identity, authorization, enforcement: three distinct roles
Three control-plane services make governance possible. Two of them often live in the same product (Okta, Entra, Auth0, Keycloak all play multiple roles), but the *roles* are distinct, and confusing them causes most implementation mistakes.
| Role | Question it answers | What it does |
| ----------------------------------- | ---------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Identity provider (IdP)** | *Who is this?* | Authenticates users and workloads; issues identity assertions (OIDC ID tokens, SAML assertions). |
| **Authorization server (AS) / STS** | *What may this token do, for which audience?* | Issues and **exchanges** access tokens scoped to a specific audience and scope set ([RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html)). |
| **Gateway** | *Is this specific call allowed right now, with what credential?* | The chokepoint every hop passes through: resolves identities, evaluates policy, drives token exchange, applies guardrails, records the result. |
The gateway is the one component present at **every** hop of the agentic call path, which is why it is the natural enforcement point — regardless of which framework built the agent or which cloud runs it.
## Delegation vs. impersonation
An agent acting for a user can carry that fact two ways, and the difference decides whether you have an audit trail.
| | Impersonation | Delegation |
| --------------------- | ------------------------------------- | -------------------------------------------- |
| The token says | "I *am* the user." | "I am acting *on behalf of* the user." |
| Acting party visible? | No — indistinguishable from the user. | Yes — recorded in an `act` (actor) claim. |
| Audit trail | The agent disappears. | Full chain: user **and** every acting agent. |
For agents you almost always want **delegation**. The delegated token keeps the user as `sub` and names the actor in an `act` claim; chained calls nest the claims — outermost is the most recent actor:
```json theme={"dark"}
{
"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 govern who is *allowed* to do this:
* **`may_act`** — the forward-looking gate: "this actor is permitted to act on behalf of this subject", checked *before* a delegated token is minted.
* **`act`** — the after-the-fact record of who actually acted, carried on the issued token.
Authorize on the *current* actor plus the subject plus policy. Keep the *whole* nested chain for forensics.
## Token exchange: carrying identity across hops
Three tempting shortcuts, and why each fails:
| Shortcut | What downstream sees | What breaks |
| ----------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Forward the user's token everywhere | "The user", at every hop | Every downstream server gets an over-privileged token never minted for it; you cannot tell which agent acted. |
| Give each agent a service account | "A service", no user | The user vanishes — no user-level permissions, no record of whose data was touched. |
| Impersonate the user | "The user" (agent hidden) | Attribution destroyed. |
Only **delegation via token exchange** keeps both identities bound in a signed, audience-scoped, minimally-scoped token. Two mechanisms cover the two cases:
### Within one trust domain: On-Behalf-Of (RFC 8693)
[RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html) defines OAuth 2.0 **token exchange**: a client presents a `subject_token` (the party the request is for) and optionally an `actor_token` (the party doing the acting), and receives a new token scoped to a target `audience` and `scope`. "On-Behalf-Of (OBO)" is the common vendor name for this flow.
A key safety property: **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. If any of the three withholds a scope, the exchange fails — so every hop yields a token *more* constrained than the last.
### Across trust domains: ID-JAG / Cross App Access
Token exchange assumes one authorization server issues and validates the token. That fails the moment the next callee lives in a different domain (another vendor's SaaS, another cloud) — Domain B can't be expected to trust a foreign issuer, and you can't forward an ID token there because it is audience-bound to the app it was minted for.
The IETF's [Identity Assertion JWT Authorization Grant (ID-JAG)](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) — productized by Okta as **Cross App Access (XAA)** — solves this in two legs:
The requesting app presents an identity assertion (OIDC ID token or SAML assertion) to the IdP's token endpoint and receives a short-lived, signed **ID-JAG** JWT — audience-bound to the *target resource's* authorization server. It is an intermediate grant, not a usable bearer token.
The requesting app presents the ID-JAG to the resource's authorization server (`grant_type=jwt-bearer`, [RFC 7523](https://www.rfc-editor.org/rfc/rfc7523.html)). That server validates it against the IdP's keys, applies **its own** policy and scoping, and returns a normal access token it minted itself.
The resource domain only ever trusts tokens *its own* authorization server issued, and the user's identity crosses the boundary with integrity. ID-JAG is **single-hop by design** — a multi-domain path mints a fresh ID-JAG per hop.
**When to use which.** Human signing into an app → **SSO (OIDC/SAML)**. Service calling a service *inside the same trust domain* → **RFC 8693 token exchange (OBO)**. An app or agent calling *another domain's* API on the user's behalf, brokered by the enterprise IdP → **ID-JAG / Cross App Access**.
## Workload identity: deriving identity from where the agent runs
An agent is, at bottom, software running *somewhere* — a Kubernetes pod, a container, a VM. Rather than minting and distributing a static credential, you can derive the agent's identity from its runtime: the platform **attests** the workload and issues it a short-lived, automatically rotated credential. [SPIFFE](https://spiffe.io/) (with its reference implementation SPIRE) is the open standard for this — the agent never holds a long-lived secret at all. See the [SPIFFE scenario](/docs/agent-platform/agent-governance/scenarios/spiffe) for how this plugs into the governance model.
## Access control and guardrails: whether vs. what
Two policy layers run at the enforcement point, and you need both:
| | Access control | Guardrails |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Decides | *Whether* a call is allowed | *What* the call may contain |
| Evaluated on | The **(principal, action, resource, context)** tuple — *this agent*, *calling this tool*, *on this server*, *for this user, now, from here* | The request and response content — PII, prompt injection, secrets, unsafe tool arguments |
| Runs | **Before** any token is minted | **Around** the call (pre- and post-tool) |
| Identity-aware? | Yes — it is the point | No — indifferent to who is calling |
In TrueFoundry these are [Gateway access control](/docs/ai-gateway/gateway-access-control) and [Guardrails](/docs/ai-gateway/guardrails-overview).
## The lifecycle concepts
Identity and tokens govern *calls*; four more concepts govern the *agent over time*:
```mermaid theme={"dark"}
flowchart LR
Onboard[Register and define authority] --> Operate[Operate under policy]
Operate --> Monitor[Compare behavior to defined authority]
Monitor -->|Within scope| Certify[Periodic re-certification]
Certify --> Operate
Monitor -->|Drift detected| Respond[Constrain, suspend, notify owner]
Respond --> Operate
Certify -->|No longer needed| Retire[Deprovision identity and grants]
```
| Concept | One-line definition |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Certification** | A periodic, owner-signed review that the agent's grants still match its purpose — the same campaign model used for human access reviews. |
| **Runtime drift** | Divergence between what the agent *does* and what its defined authority *says* — detected by comparing telemetry against scope continuously. |
| **Decision evidence** | The audit record produced *as the agent operates*: who authorized it, what authority was defined, which tools and credentials were used, how each action mapped to scope. |
| **Kill switch** | Instant revocation of one agent's identity — surgical, not a platform-wide outage. |
## The vocabulary in one table
| Term | Definition |
| -------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| Agentic call path | The chain user → app → agent → sub-agent → … → MCP tool that governance must control at every hop. |
| Agent identity | A first-class, verifiable identity for an agent, distinct from any user or service account. |
| Delegation | Acting *on behalf of* a subject, with the actor recorded (`act`); the opposite of impersonation. |
| Token exchange / OBO | Trading an incoming token for a new one — subject preserved, actor recorded, audience and scope narrowed — within one trust domain (RFC 8693). |
| ID-JAG / XAA | Crossing a trust-domain boundary via an IdP-brokered grant redeemed at the resource's own authorization server. |
| Defined authority | The documented scope of what an agent may do, against which delegation, behavior, and audit are all evaluated. |
| Access control | Deciding whether a (principal, action, resource, context) is permitted, before any token is minted. |
| Guardrails | Inspecting request/response content independent of identity. |
| Workload identity (SPIFFE) | Deriving an agent's credential from attestation of its runtime instead of a distributed secret. |