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

# Implementing Agent Governance with TrueFoundry

> How each pillar of the agent governance blueprint maps to TrueFoundry features — what to configure today, and which capabilities are coming soon.

This page maps the [governance blueprint](/docs/agent-platform/agent-governance/governance-blueprint) onto TrueFoundry. The short version: the **Agent Registry** implements register-and-own, **agent identities** implement authenticate, the **Agent Gateway and MCP Gateway** implement authorize-and-scope, and **AI Monitoring** implements audit. Discovery and several deeper controls are marked **coming soon** below.

<Info>
  Capabilities are rolling out incrementally. Anything marked *coming soon* describes the target behavior and may change before release — talk to your TrueFoundry contact for current availability.
</Info>

## The pillar-to-feature map

| Blueprint pillar     | TrueFoundry feature                                                                                                         | Availability            |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
| 1. Discover          | Agent discovery across gateway traffic, clouds, and identity providers                                                      | **Coming soon**         |
| 2. Register and own  | [Agent Registry](/docs/agent-platform/agent-governance/agent-registry) — registration with owner and collaborators          | Today                   |
| 3. Authenticate      | [Agent Identity](/docs/ai-gateway/agents/agent-identity) — TrueFoundry-backed or identity provider-backed                   | Today (beta)            |
| 4. Authorize         | Collaborator grants per agent, per MCP server, per model; [gateway access control](/docs/ai-gateway/gateway-access-control) | Today                   |
| 4. Scope (tools)     | [Virtual MCP Servers](/docs/ai-gateway/mcp/virtual-mcp-server) today; per-agent tool scope                                  | Today / **Coming soon** |
| 4. Exchange (tokens) | Per-hop token exchange — OBO, ID-JAG, gateway-issued scoped tokens                                                          | **Coming soon**         |
| 4. Guard             | [Guardrails for agents](/docs/agent-platform/agent-governance/agent-guardrails) — pre/post-call content checks at every hop | Today                   |
| 5. Audit             | [Agent observability](/docs/agent-platform/agent-governance/agent-observability) — metrics and traces per agent, per user   | Today                   |
| 5. Respond           | Revoke by removing grants or deleting the agent; instant per-agent kill switch                                              | Today / **Coming soon** |
| 5. Certify           | Access certification campaigns and drift detection                                                                          | **Coming soon**         |

## What to set up today

Five steps take you from ungoverned to Level 2 of the [maturity model](/docs/agent-platform/agent-governance/governance-blueprint#a-maturity-model).

<Steps>
  <Step title="Register every agent">
    Add each agent to the [Agent Registry](/docs/agent-platform/agent-governance/agent-registry) — wherever it runs (Bedrock, LangGraph, custom HTTP, A2A, copilots embedded in SaaS). Agents with a callable URL are **proxied** through the Agent Gateway; embedded agents with no URL are registered **governance-only**, so their outbound calls are still governed. See [registering an agent](/docs/agent-platform/agent-governance/agent-registry#registering-an-agent) for the full walkthrough.

    Set the **Owner** team on the Access Control step — this is the accountability anchor the blueprint requires.
  </Step>

  <Step title="Give each agent an identity">
    The Agent Identity step of registration decides how the agent proves who it is:

    * **TrueFoundry-backed** — TrueFoundry issues and signs the token. Right default for agents you run yourself. See the [TrueFoundry as identity broker scenario](/docs/agent-platform/agent-governance/scenarios/truefoundry-identity-broker).
    * **Identity provider-backed** — the agent authenticates with a token from Okta, Microsoft Entra, or any OIDC provider (including a SPIFFE/SPIRE OIDC endpoint), mapped to the agent via claim values. See the [Okta](/docs/agent-platform/agent-governance/scenarios/okta), [Entra](/docs/agent-platform/agent-governance/scenarios/microsoft-entra), and [SPIFFE](/docs/agent-platform/agent-governance/scenarios/spiffe) scenarios.
  </Step>

  <Step title="Grant least-privilege access">
    Access is allow-list based everywhere:

    * **Who may call the agent, and whom it may act for** — the agent's collaborators. **Agent Access** grants both invoking the agent *and* being acted for by it; scope it to the teams that actually use the agent rather than `everyone`.
    * **What the agent may reach** — add the agent as a collaborator on each MCP server and model it needs, exactly like a user (subject `agent:<name>`). No grant, no access, `403`.
    * **Which tools within a server** — until per-agent tool scoping ships, curate a tool subset as a [Virtual MCP Server](/docs/ai-gateway/mcp/virtual-mcp-server) and grant the agent access to that instead of the full server.
  </Step>

  <Step title="Carry identity on every call">
    A delegated call carries two bearer tokens — the user in `Authorization`, the agent in `x-tfy-agent-authorization` — on every surface (LLM Gateway, MCP Gateway, Agent Gateway). Each agent in a chain replaces the agent header with its own identity while passing the user's token through, so the gateway checks *every* hop against the agent actually making it. See [passing the identity in your code](/docs/ai-gateway/agents/agent-identity#passing-the-identity-in-your-code).
  </Step>

  <Step title="Turn on guardrails and monitoring">
    Attach [guardrails](/docs/agent-platform/agent-governance/agent-guardrails) (PII, prompt injection, secrets, unsafe arguments) to the servers and models agents use, and use [agent observability](/docs/agent-platform/agent-governance/agent-observability) to see per-request records attributed to the agent and the user it acted for.
  </Step>
</Steps>

The result, end to end — every arrow passes a gateway check, and no hop inherits its caller's reach:

```mermaid theme={"dark"}
sequenceDiagram
    participant Jane as Jane (user)
    participant GW as Agent / MCP Gateway
    participant A1 as planner-agent
    participant A2 as research-agent
    participant MCP as Zendesk MCP Server

    Jane->>GW: Authorization: Jane
    Note over GW: Jane may call planner-agent?
    GW->>A1: Invoke planner-agent
    A1->>GW: Authorization: Jane + agent: planner-agent
    Note over GW: planner may call research? may act for Jane?
    GW->>A2: Invoke research-agent
    A2->>GW: Authorization: Jane + agent: research-agent
    Note over GW: research allowed on Zendesk? may act for Jane?
    GW->>MCP: Call search_tickets
    MCP-->>GW: Jane's tickets
    GW-->>Jane: Result
```

## Coming soon

These close the gap between Level 2 and Level 3 of the maturity model. Where behavior is not yet final, the description below is the intended design.

<AccordionGroup>
  <Accordion title="Agent discovery" icon="magnifying-glass">
    **Coming soon.** Continuous discovery of agents that exist but are not registered, surfaced as a triage queue in the Agent Registry:

    * **Gateway traffic analysis** — callers reaching models and MCP servers with user or virtual-account credentials whose traffic patterns are agentic (tool-call loops, model round-trips) get flagged as candidate shadow agents.
    * **Cloud and identity provider scanning** — connectors enumerate agent principals in AWS Bedrock, Azure AI / Entra Agent ID, Google Cloud, and OAuth clients in Okta/Entra, and reconcile them against the registry.
    * **Enforcement ramp** — start in *observe* mode (flag unregistered callers), then flip to *enforce* (deny anything without a registered agent identity), turning registration into the chokepoint the blueprint requires.
  </Accordion>

  <Accordion title="Per-hop token exchange (OBO, ID-JAG, gateway-issued)" icon="right-left">
    **Coming soon.** Today the agent's identity travels as a second header and outbound authentication to targets is unchanged. In the target model, the gateway exchanges the incoming token at each hop for a delegated token — user as `sub`, agents nested in `act`, audience and scope narrowed to the next callee — using OBO within a trust domain, ID-JAG across domains, or a TrueFoundry-issued scoped token when the target can't participate in exchange. The [identity provider scenarios](/docs/agent-platform/agent-governance/scenarios/truefoundry-identity-broker) describe the flow per provider.
  </Accordion>

  <Accordion title="Per-agent tool scoping" icon="sliders">
    **Coming soon.** Restrict an agent (or user) to a subset of an MCP server's tools directly on the grant — for example, 3 of the server's 10 tools — with the scope applied when the downstream token is minted. Until then, Virtual MCP Servers achieve the same end.
  </Accordion>

  <Accordion title="Attribute-based policies (Cedar)" icon="file-code">
    **Coming soon.** [Cedar](https://www.cedarpolicy.com/) policies evaluated at both gateways on every request, expressed as (principal, action, resource, context) — for rules an allow-list can't state, such as *only during business hours*, *only for low-risk tools*, or *block destructive tools for any agent more than two hops deep in a chain*.
  </Accordion>

  <Accordion title="Credential lifecycle" icon="rotate">
    **Coming soon.** Scheduled expiry, auto-rotation, expiry notifications, and secret-manager sync for TrueFoundry-backed agent tokens, plus SPIFFE binding for per-instance credentials.
  </Accordion>

  <Accordion title="Kill switch and certification" icon="power-off">
    Today, revocation works by removing the agent's collaborator grants or deleting the agent — effective immediately at the gateway. **Coming soon:** a one-click suspend that freezes all of an agent's access while preserving its registration and history, plus periodic access-certification campaigns where owners re-attest each agent's grants against actual usage, and drift alerts when behavior diverges from the agent's defined authority.
  </Accordion>
</AccordionGroup>

## Which scenario applies to you

The mechanics of identity and token exchange depend on where your agents' identities live. Pick the scenario that matches your estate — mixed estates combine them per agent.

<CardGroup cols={2}>
  <Card title="TrueFoundry as the identity broker" icon="shield-halved" href="/docs/agent-platform/agent-governance/scenarios/truefoundry-identity-broker">
    No agent-capable identity provider, or you want the fastest path: TrueFoundry issues agent identities and brokers all access.
  </Card>

  <Card title="Okta" icon="key" href="/docs/agent-platform/agent-governance/scenarios/okta">
    Agents and apps registered in Okta — base Okta with Cross App Access (ID-JAG), and the paid Okta for AI Agents product.
  </Card>

  <Card title="Microsoft Entra (Azure AD)" icon="microsoft" href="/docs/agent-platform/agent-governance/scenarios/microsoft-entra">
    Agents registered as Entra Agent IDs, with the agent-aware On-Behalf-Of flow.
  </Card>

  <Card title="SPIFFE / SPIRE" icon="certificate" href="/docs/agent-platform/agent-governance/scenarios/spiffe">
    Workload identity: agents get short-lived attested credentials from their runtime instead of distributed secrets.
  </Card>
</CardGroup>