Skip to main content
Coming Soon — this page is a work in progress. It will document how TrueFoundry integrates with Okta for AI Agents so that agents carry first-class Okta identities and the gateway performs ID-JAG exchange at every hop.

​
Overview

When an agent calls another agent, which calls an MCP server, the request that started as “summarize my open tickets” becomes a chain of calls made by software, not by the user. If each hop simply forwards the user’s token, the resource at the end sees only the user — it cannot tell which agent acted, under whose authority, or whether that agent was allowed to. Attribution and scoped-down access both disappear at the first hop. Okta for AI Agents closes the identity half of that gap. An agent is registered in Okta’s Universal Directory as a first-class non-human identity — with a human owner, a managed lifecycle, and the entitlement to perform agent-to-agent token exchange. Each hop mints a fresh ID-JAG audienced to the next callee’s authorization server, keeping the user as sub while nesting the acting agent into the act chain. TrueFoundry closes the enforcement half. The Agent Gateway and MCP Gateway sit on every hop of the call path and perform the exchange on the chain’s behalf — so no agent author writes a two-legged token exchange, and policy, scope, and audit stay consistent no matter which framework built the agent. Together they give you:
Okta AI Agents is a separate, paid Okta product, distinct from Cross App Access (XAA). If you are not licensed for it, the single-hop XAA and OBO patterns still work on base Okta with a custom authorization server — see Limitations and the agent governance blog for the fallback patterns.

​
Okta application vs Okta AI Agent

The rest of this guide leans on two Okta terms that are easy to conflate. They are different kinds of principal, and which one you register determines what a hop can do. Okta application — a client or resource that Okta knows about, registered as an OIDC/OAuth client. In an exchange it plays the requesting app (the thing acting for a signed-in user) or the resource app (the protected target). Registering an application is base Workforce Identity functionality — no AI-agent product required. Okta AI Agent — an autonomous actor registered as a first-class non-human identity in Okta’s Universal Directory through Okta for AI Agents. It is still an OAuth client underneath, but registering it as an agent adds an owner (a human accountable for it) and — the part this guide depends on — the entitlement to perform agent-to-agent token exchange, the onward per-hop ID-JAG minting a multi-agent chain needs. The short version: an Okta application is any client or resource Okta knows about; an Okta AI Agent is that plus first-class agent identity, ownership, and onward token exchange.

​
Which one to register for each hop

In a chain like client app → Agent A → Agent B → MCP server:
  • The client app is an Okta application (the requesting app) — the user signs into it and it obtains the Okta ID token that seeds the chain.
  • Agent A and Agent B are Okta AI Agents, because each one both receives a call and makes the next one. Only an AI Agent can mint the onward ID-JAG.
  • The MCP server is an Okta application in the resource-app role — it is a target, not an actor, so it does not need to be an AI Agent.
Register as an AI Agent only what genuinely acts. A terminal MCP server is a resource; making it an AI Agent adds licensing cost and lifecycle overhead without adding capability.

​
Delegations and resource connections

Once an agent exists in Okta, two settings on its detail page define the edges of the chain it can participate in. They are the inbound and outbound halves of the same relationship, and both must be in place for a hop to work: For the hop Agent A → Agent B, that means a delegation on Agent B naming Agent A, and a resource connection on Agent A pointing at Agent B. Okta collapses this for you in one case:
When you delegate an AI agent to another AI agent, Okta automatically creates the matching resource connection between them. For every other delegation type — a user signed into an app, or a non-human identity such as a service — you configure the resource connection separately.
A resource connection also carries a type, and the type decides which token the agent ends up presenting downstream:
The Authorization server and Resource server types are the two that change the shape of the flow. With Authorization server, Okta mints an ID-JAG audienced to that server and the gateway redeems it for a scoped token. With Resource server, Okta does not mint an ID-JAG — it brokers a token issued by the third party instead. That distinction is why the terminal hop differs between an Okta-fronted and a third-party MCP server.
Configuring delegations for non-human identities requires a custom authorization server — that is what registers the AI agent as a protected resource other agents and services can call. An agent without one can make outbound calls but cannot be the target of an agent-to-agent hop.

​
Prerequisites

In Okta, you need:
  • An Okta for AI Agents subscription — the separate paid product that provides agent registration and the agent-to-agent token exchange this flow depends on.
  • Admin access to register AI agents and create custom authorization servers.
In TrueFoundry, you need permission to register an agent, an identity provider, and an MCP server.

​
How it works

Sequence: user ID token → ID-JAG audienced to the callee’s custom authorization server → redeemed access token → next hop seeded by the previous hop’s access token, with act nesting at each step.

​
Okta setup

1

Register each agent as an Okta AI Agent

Universal Directory registration, assigning a human owner, and the OAuth client that backs the agent identity.
2

Give each agent a custom authorization server

Why the AS issuer becomes the audience of the ID-JAG minted for calls into that agent; when to share one AS versus one per agent.
3

Register the terminal MCP server as a resource

Connected-resource types and which one applies to an Okta-fronted MCP server versus a third-party one.
4

Authorize the connections along the chain

client → Agent A, Agent A → Agent B, Agent B → MCP. Each connection is what lets Okta mint a fresh ID-JAG for that hop.

​
TrueFoundry setup

1

Configure ID-JAG Auth Data on each agent

Auth Type, Grant Type = ID-JAG (Okta AI Agent), Resource Token URL, Resource Client ID, Private Key, Issuer URI.
2

Configure ID-JAG Auth Data on the MCP server

Same grant type, pointed at the MCP’s custom authorization server for the final hop.
3

Grant access along the chain

Collaborators / virtual accounts that authorize each caller to invoke the next agent or MCP server.

​
Configuration reference

Field-by-field table for the ID-JAG (Okta AI Agent) Auth Data form.

​
Verifying the setup

How to confirm the exchange is happening: what to look for in the gateway logs, the claims to expect on the downstream token (sub, nested act), and common failure modes.

​
Limitations

What requires the paid Okta AI Agents product, what falls back to OBO or plain OAuth, and where the actor chain breaks.

​
FAQ

TODO
TODO
TODO
Related reading: Agent Identity & OBO, Agent Identity, and the Agent Governance section.