Agent Governance Key Concepts

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

{
  "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 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) — productized by Okta as Cross App Access (XAA) — solves this in two legs:

Mint the ID-JAG at the identity provider

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.

Redeem it at the resource's authorization server

The requesting app presents the ID-JAG to the resource’s authorization server (grant_type=jwt-bearer, RFC 7523). 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 (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 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 and Guardrails.

The lifecycle concepts

Identity and tokens govern calls; four more concepts govern the agent over time:

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.

​The actors on the call path

​Agent identity: a third kind of principal

​Ownership and defined authority

​Identity, authorization, enforcement: three distinct roles

​Delegation vs. impersonation

​Token exchange: carrying identity across hops

​Within one trust domain: On-Behalf-Of (RFC 8693)

​Across trust domains: ID-JAG / Cross App Access

​Workload identity: deriving identity from where the agent runs

​Access control and guardrails: whether vs. what

​The lifecycle concepts

​The vocabulary in one table

The actors on the call path

Agent identity: a third kind of principal

Ownership and defined authority

Identity, authorization, enforcement: three distinct roles

Delegation vs. impersonation

Token exchange: carrying identity across hops

Within one trust domain: On-Behalf-Of (RFC 8693)

Across trust domains: ID-JAG / Cross App Access

Workload identity: deriving identity from where the agent runs

Access control and guardrails: whether vs. what

The lifecycle concepts

The vocabulary in one table