Skip to main content
This page maps the 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.
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.

​
The pillar-to-feature map

​
What to set up today

Five steps take you from ungoverned to Level 2 of the maturity model.
1

Register every agent

Add each agent to the 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 for the full walkthrough.Set the Owner team on the Access Control step — this is the accountability anchor the blueprint requires.
2

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.
  • 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, Entra, and SPIFFE scenarios.
3

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 and grant the agent access to that instead of the full server.
4

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

Turn on guardrails and monitoring

Attach guardrails (PII, prompt injection, secrets, unsafe arguments) to the servers and models agents use, and use agent observability to see per-request records attributed to the agent and the user it acted for.
The result, end to end — every arrow passes a gateway check, and no hop inherits its caller’s reach:

​
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.
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.
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 describe the flow per provider.
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.
Coming soon. Cedar 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.
Coming soon. Scheduled expiry, auto-rotation, expiry notifications, and secret-manager sync for TrueFoundry-backed agent tokens, plus SPIFFE binding for per-instance credentials.
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.

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

TrueFoundry as the identity broker

No agent-capable identity provider, or you want the fastest path: TrueFoundry issues agent identities and brokers all access.

Okta

Agents and apps registered in Okta — base Okta with Cross App Access (ID-JAG), and the paid Okta for AI Agents product.

Microsoft Entra (Azure AD)

Agents registered as Entra Agent IDs, with the agent-aware On-Behalf-Of flow.

SPIFFE / SPIRE

Workload identity: agents get short-lived attested credentials from their runtime instead of distributed secrets.