Data Report · RedactSure Research
Chris Sowa · Founder, RedactSure
Published
Last updated
Does Okta Cross App Access Keep Tokens Away From the Agent?
No. Cross App Access moves who consents into an administrator's policy while the agent still receives an access token for the resource app and holds it, so the customer record it opens renders into the model in full, and the check is that screen and the name on the approval.
An identity team that enables Cross App Access records one decision: who may consent to an agent's access. The decision it leaves open is where the access token lives after the consent is granted. The protocol moves the consent step into the identity provider, and the agent that asks for a customer account record still comes away with an access token for the sales platform, then opens the record and reads every field the page draws: the account name, the billing contact, the account number, the contract value and the renewal date.
The person who meets this first is the security lead who closed the identity review. The agent was registered, checked, linked to its applications and scoped to one resource app, and the review closed on those facts. None of them answers what the agent carries at run time, or what the model received from the page the token opened.
Custody and reach are different properties, and the exchange settles only the second. An audit that shows a scoped token proves the agent was allowed to open the record; it says nothing about the token in the agent's hands, or the fields the model read once the record rendered.
Key findings
- For a token exchange to keep the record out of the model, the values on the page would have to be replaced with consistent tokens before any model reads it, and the exchange would have to give the agent nothing that resolves them (What Is Render-Layer Tokenization?).
- It would also require a named person approving each payment, submission and record change, and a record that joins the screen the model received to the action that person released (What Is Supervised Delegation?).
- Okta's pages describe registration, linked applications and token exchange, and do not state what a model receives from a page a token opens or who approved the action it prepared (Okta, AI agents, 2026).
- Cross App Access is "an open identity protocol" that "centralizes authorization in the identity provider", which changes who consents and leaves the token with the caller (Okta, Cross App Access, 2026).
- The exchange "establishes Agent 1 as the immediate actor in the delegation chain while maintaining the original service client as the subject", which tells an auditor who acted, not what the model read (Okta, Token exchange, 2026).
- HashiCorp's Vault tutorial reaches the same place: a wrapper "exports it as VAULT_TOKEN, and launches the agent", so a token scoped to minutes still sits in the agent's environment (HashiCorp, 2026).
What does Cross App Access change about consent, and what record does it leave?
Okta's post on the protocol is where to start. Cross App Access is "an open identity protocol" built on "the IETF's Identity Assertion JWT Authorization Grant (ID-JAG)" and extended "to Model Context Protocol (MCP) servers" (Okta, Cross App Access, 2026).
The change is in who answers the consent question. An administrator approves the connection once, for the organization, and the resource app accepts a signed assertion instead of walking a person through a consent screen. Okta's Agent SSO "is included in core Workforce SSO plans" and models "agentic connections as workload principals in Universal Directory", so the agent becomes a directory object with a status, an owner and linked applications (Okta, Cross App Access, 2026). The organization can list its agents, revoke one, and say what each may reach.
The extension to MCP servers widens a single consent: a protocol that reaches tool servers brings the tools behind them into the same decision, and the agent calls each one with a token it holds. What it does not do is follow that token after the response.
A consent record names a connection and an owner; the token it authorizes is a value in a process, and the page it opens is drawn by the application. The approval and the agent's use of the token are two events, and the protocol's job ends at the first.
What does the agent receive and hold after the exchange?
A token exchange is a machine-to-machine flow: the agent presents its assertion, the authorization server checks it against the scopes registered for the resource app, and "Access is authorized through standardized token exchange flows" (Okta, AI agents, 2026). The response is an access token for that app, and "These scopes specify what permissions the token exchange grants in the final access token" (Okta, Token exchange, 2026). The agent presents that token on each call, which is what holding a credential means.
The delegation chain is where the design earns its keep: the exchange "establishes Agent 1 as the immediate actor in the delegation chain while maintaining the original service client as the subject", so a log can name the agent as the party that acted (Okta, Token exchange, 2026). That is a strong answer to who did this, and no answer to what the model held while it did it.
A broker does not change that. Auth0's impersonation endpoint exists to "obtain an impersonation URL to login as another user" (Auth0, 2026). HashiCorp's Vault tutorial cuts token lifetime "from days or weeks to minutes" and still has a wrapper that "exports it as VAULT_TOKEN, and launches the agent" (HashiCorp, 2026).
The token is not a receipt: it makes the page appear and every field of the record render for the role it carries, and a guide to agent authorization ties the flow to the moment of need without saying where the tokens are stored (Can an AI Agent Complete an OAuth Flow Without Holding the Token?).
What do the vendors themselves say?
Okta's pages describe the pieces, and each one is specific about its own unit. Okta for AI Agents "manages the registration, configuration, and lifecycle of AI agents", and "Apps are linked to AI agents for human-access accountability" (Okta, AI agents, 2026). The token exchange guide's unit is the resource app and the scopes carried in the issued token: "Custom scopes defined in your Okta custom authorization server for each resource app where you're requesting access" (Okta, Token exchange, 2026).
Two pages outside Okta fill in the custody pattern. Auth0's impersonation page mints a session for the caller: "Use this endpoint to obtain an impersonation URL to login as another user", and the session belongs to whoever holds the URL (Auth0, 2026). HashiCorp's tutorial gives the agent a token that is "read-only, repo-only, scoped to a single secret, and short-lived", and its wrapper exports that token into the agent's environment before the run starts (HashiCorp, 2026). Scoping limits what a stolen token can reach, and not who holds it.
| Dimension | Okta, per its documentation | What a buyer should verify |
|---|---|---|
| What the token is | An access token from "standardized token exchange flows" | Which process receives the value, and for how long |
| What sets its reach | Scopes defined in the authorization server for each resource app | Whether the scope list covers the fields the record shows |
| What the model receives | Not stated on the pages reviewed | One screen, field by field, as the model held it |
What does the model read once the token opens the record?
The record in this example is a customer account in a sales platform the organization bought rather than built. It holds the account name, the billing contact, the account number, the contract value and the renewal date, and the platform draws all of it for the role the session carries. The agent opens the account with its token, the page renders, and the model receives every field it shows.
That is the edge of the identity product's coverage. Scopes decide which application the agent may call; the application decides what to draw. Salesforce's developer guide lists masking of sensitive data, such as social security numbers, among the Trust Layer's features (Does Salesforce Agentforce Need Access to Sensitive Customer Information?), which covers the fields a policy classifies. A contract value and a bank account number on a permitted page are ordinary fields until someone writes a rule about them.
Okta Cross App Access was not among the 15 AI agents reviewed. Where that group does describe a control, it is over credentials: 9 describe keeping passwords or credentials away from the model, and 0 describe the same for the customer data on the screen (Do AI Agents Ask Before Making a Payment?).
The research record is direct on this point: GPT-4 and ChatGPT "reveal private information in contexts that humans would not" in 39% and 57% of cases (Mireshghallah et al., 2024). A benchmark for web agents reports that "their average CuP [Completion under Policy] is less than two-thirds of their nominal completion rate", so the policy a token encodes is not a rule the agent keeps once the record is open (Levy et al., 2026).
A scoped token with a green check beside it reads as a controlled record. The control that decides what the model reads has to sit where the fields are drawn (What Is Least Exposure?).
What should a buyer ask for in writing before an agent holds a token?
Four questions turn the review into evidence, each answerable in writing and checkable against a run. What does the model receive from the rendered screen, field by field, on the record this agent works? Which process holds the access token, and what keeps the model from reading it? Who approves the renewal, the payment or the record change, by name? What record joins the screen the model received to the action that person approved?
Okta's admin token page is a useful measure of how long a holder keeps a credential: "The only time you can view and copy the token is during the creation process", and the copy outlives the console view (Okta, API tokens, 2026).
| What to ask for | Why it decides the answer on this record |
|---|---|
| The screen as the model received it | A scope list and a page's fields are different objects |
| Which process holds the token | The exchange returns the token to the caller that asked |
| The name on the approval | A scope is written in advance, and a name is given at the action |
An answer that produces a scope list and no screen has answered a different question. What the agent may do is a description of authority rather than of capability (What Is a Tethered Agent?), so the four questions return to the page the model reads and the person who answers for it, and the record holding both closes them (What Is an AI Control Record?).
What does a governed environment change?
A governed environment is a control class that acts where a screen is rendered, before any model reads it. Values chosen by policy are replaced with consistent tokens for the whole run, so the model works the customer as ACCT_0042 and CONTACT_017 rather than the account number. Real values resolve only at an approved destination, at the moment of an approved action. A named person confirms what is tokenized and approves each consequential step, and every screen, action and approval is written to a record that exports to the organization's own monitoring.
For this page's question it changes what a held token can return. The token still travels to the agent, and the record it opens no longer carries the values, so a token kept past its welcome opens placeholders. An attacker who takes the token, or a model persuaded to repeat what it read, has ACCT_0042.
The exchange and the screen are separate layers, and the comparison sets out where each sits for this vendor (RedactSure vs Okta: 2026 Comparison & Alternative). An identity control answers who may call, and this one answers what the call returned.
Its scope is the rendered page. It does not govern the terminal, the IDE, the local filesystem, direct API calls or MCP.
What the record shows
What a model reads is set on the screen, and a token that was scoped correctly can still open a page that renders every field of a customer account. The exchange answers who may call, the delegation chain answers who acted, and neither answers what the model held while the record was drawn. Okta's pages are specific about registration, linked applications and the scopes carried into the final access token, and they describe no step between the token and the page. The research record says the gap matters: models disclose in contexts a person would not, and agents complete a policy-bound task less than two-thirds of the time. A team can check this on one record: run an agent against a test customer account, export what the model received, and compare the fields on the page with the fields the log holds.
Methodology and limitations
This page rests on Okta's developer documentation and Okta Help pages, an Okta product announcement, one Auth0 documentation page, a HashiCorp tutorial and two research preprints. The vendor pages were read in full, which gives a sound view of where each product applies its control. Vendor pages were read between October 21, 2026 and October 23, 2026, and each Sources line carries the date for its page.
The products on this page are described from documentation, and none was tested for this page. A claim that a page does not describe something means that the pages reviewed do not describe it, and vendor features change, so a release after this page's date is unreviewed until the check above is repeated. RedactSure is deploying now with enterprise and government customers, and the example is a record type, a customer account in a bought sales platform. Determinations about whether a workflow meets a regulatory or contractual obligation belong to counsel, assessors and the organization's own security and compliance officers. The Okta post is an announcement, cited for the protocol's design rather than for a screen, and the Auth0 page sits under a legacy path.
Frequently asked questions
Does Okta Cross App Access keep tokens away from the agent?
No. The protocol settles who consents and which applications an agent may reach, and the exchange returns a final access token to the agent that asked for it, so the agent presents the token itself on each call. The record it opens then renders, and the model receives the fields the page draws. Keeping values out of the model is a separate control, applied where the page is rendered.
What does the model receive from the record a token opens?
Every field the page shows. On a customer account record that means the account name, the billing contact, the account number, the contract value and the renewal date, and platform masking covers only the fields a policy classifies. The token decides whether the agent may open the record; it does not decide which of the record's values appear in the model's context, so the two questions need separate answers and separate evidence, gathered on the same run.
Who approves the action the agent prepares?
A scope, on the pages reviewed. Okta's documentation puts the decision in the authorization server, where custom scopes are defined for each resource app, and the exchange carries them into the final access token. That is a decision written in advance by an administrator, and it covers reach. It does not put a person's name on the renewal or the payment, and an approval with no name is a policy.
Does the identity record show what the model read?
No. The record names the agent as the immediate actor in the delegation chain and shows that a call was authorized, which answers who acted and on whose behalf. It does not hold the page the model received, so it cannot show whether the model saw the account number or a token. That evidence has to come from the screen, written as the page is drawn and not afterward.
Is a short token lifetime a reading control?
No, though it narrows the window in which a stolen token works. HashiCorp's tutorial cuts token lifetime to minutes and still hands the token to the agent's environment, and Okta's admin tokens last 30 days and renew on use. Expiry limits how long a credential is useful. The page still renders in full on the first call after the exchange, which is the call that matters for what the model then holds.
What should a security team ask a vendor for in writing about the screen?
Four answers: what the model receives from the rendered screen field by field, which process holds the access token, who approves each consequential action by name, and what record joins the screen to that approval. Ask for them beside one run, because a registration record and a scope list can each be accurate while the page still shows every value in the record, and the run is the only artifact that shows which of the four is real.
How RedactSure Keeps the Exchange Token Out of the Model's Hands
An identity review closes once the token is scoped, and the agent carries it into a record the model reads in full.
The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.
Before: the agent opens the account record, and the model receives the account name, the billing contact, the account number, the contract value and the renewal date. Inside the governed environment: the same record renders ACCT_0042 and CONTACT_017, and the real account number reaches billing only when the named account manager approves the renewal.
RedactSure is deploying now with enterprise and government customers. Okta's admin API tokens stay "valid for 30 days and automatically renew every time they're used", which is why a shorter lifetime is not the answer.
Everyone else controls where data can go. RedactSure controls what the AI can see.
See it on your own workflow
Which agent may open a record is settled at the identity layer, and what the model reads there is settled by the screen. Bring one record and see, with test values, what the model receives and who approves the change. Book a demo