AgentValet vs Okta Cross App Access
Okta’s Agent SSO, built on the IETF’s Cross App Access standard, lets your identity provider decide which agents reach which apps for which people. AgentValet decides each call the agent makes. They act at different moments, and this page is plain about where each one wins and how they fit together.
Two approaches, in plain words
What Cross App Access is
Cross App Access (XAA) is the product name for an IETF draft, the Identity Assertion JWT Authorization Grant, or ID-JAG. Your employee signs in to an agent with your IdP. The agent asks the IdP for a signed grant naming the app it wants. The app, which already trusts your IdP for single sign-on, swaps the grant for its own access token. There’s no consent screen, and IdP policy decides which agents may reach which apps for which people.
Okta made Agent SSO generally available on 24 August 2026, included in its core SSO plans, and Claude supports it on Team and Enterprise. The MCP project adopted the same pattern as Enterprise-Managed Authorization, so an MCP server can take part without new protocol work.
What AgentValet is
AgentValet is a broker on the platform call. It holds the credential for Slack, GitHub, Stripe or an MCP server, checks the agent’s own grant and your rules on every call, asks a person first when a rule says so, and records what was executed.
It works the same whichever IdP a platform trusts. Your team can sign in to AgentValet itself through Okta, so the broker sits next to the IdP you already run.
The question that separates them
Is the decision made when the token is issued, or on every call?
With Cross App Access, your IdP decides once, when it issues the grant. The MCP extension says so itself: the IdP’s visibility “is limited to the process of issuing the access token, but does not extend to the actual MCP traffic between the MCP Client and Server.” Renewal does come back through the IdP, because the app “SHOULD NOT return a Refresh Token”, so disabling a user or an agent there stops new grants.
AgentValet decides on each call, which is where a per-action approval and a per-call record can live. The other dividing line is the circle. The draft is limited, by design, to apps that trust the same IdP as the agent, and its authors point to other drafts for the rest.
- Employee signs in to the agent with your IdP
- IdP checks policy and issues a grant
- App that trusts your IdP issues its own token
- Agent calls the app with that token
- App
Strong inside one circle of trust. Once the token is issued, the calls are out of the IdP’s sight.
- Your agent
- Tool call
- Broker checks identity, grant, policy and approval
- Credential attached in memory
- Any platform or MCP server
Checked per call, whichever IdP the platform trusts. It doesn’t take over your IdP’s say in which apps an agent may reach.
What each one actually does
One line per cell. Open the detail underneath for the longer version.
| AgentValet | Cross App Access (ID-JAG) | |
|---|---|---|
| When it decides | On every platform call, at the broker. | When the IdP issues the grant; the app then issues its own token. |
| Which apps | Any platform or MCP server you connect, whichever IdP it trusts. | Apps that trust the same IdP as the agent for single sign-on. |
| Who the grant is for | A named agent with its own signing key, acting for a person or on its own grant. | A person signed in through your IdP; an agent acting as itself is outside the draft. |
| Holds platform credentials | Yes, and the agent never sees them. | No; the agent holds the app’s access token until it expires. |
| Approval of a specific action | Built in: the call pauses until a person approves it. | Not part of the standard; the IdP’s decision is made at grant time. |
| Record of what happened | Append-only, with a signed receipt on every decision. | The IdP sees each grant; the calls themselves are in each app’s own logs. |
| Chains of agents | One level of child agents, each limited to a subset of the parent’s scopes and checked on every call. | A new grant per hop; the chain of actors isn’t defined. |
| Tenants that trust a different IdP | Each connection is held by the broker, so the IdP behind the app doesn’t matter. | Outside scope unless that tenant adds your IdP as a trusted issuer. |
| Revocation | Revoke an agent and its next call fails closed. | Disable the user or agent at the IdP and no new grants are issued. |
| Fit with Okta | Your team signs in to AgentValet through Okta, on the Enterprise plan. | Okta is the IdP that issues the grants. |
| Standards | OAuth for platform connections; it doesn’t issue or accept ID-JAGs today. | An OAuth working group draft, and a stable MCP extension. |
| Pricing | Free tier; paid plans from US$99 a month, self-serve. | Included in Okta’s core SSO plans, with 250 grants per user, per app, per month. |
The detail behind 7 of these rows
- Which apps
Cross App Access (ID-JAG): Section 4.1 of the draft limits it to deployments where the client and the app both trust the same IdP. An app can trust several IdPs, but each one has to be configured in advance.
- Who the grant is for
Cross App Access (ID-JAG): Section 3.1 makes the subject a user. The Workload Authorization Grant draft is the authors’ proposal for agents acting as themselves, and it’s at an early stage.
- Holds platform credentials
Cross App Access (ID-JAG): The app should not issue a refresh token, so each renewal goes back through your IdP.
- Approval of a specific action
AgentValet: Approve with a passkey or email link on every plan, with push notifications on Team and above. The approved call then runs.
- Chains of agents
Cross App Access (ID-JAG): Sections 9.3 and 9.7. The authors point to an actor profile and the Identity Chaining draft for this.
- Standards
Cross App Access (ID-JAG): draft-ietf-oauth-identity-assertion-authz-grant-04, dated 21 May 2026.
- Pricing
Cross App Access (ID-JAG): One grant is used each time an agent reaches an app through XAA. Above the allowance, Okta points customers to its separate Okta for AI Agents product.
Where Cross App Access genuinely wins
If your agents act for your employees in SaaS apps that already trust your IdP, Cross App Access is the cleanest answer there is. No consent screens, one place to decide which agents reach which apps, renewal that keeps going back through your IdP, and nothing extra to buy if you already run Okta SSO. AgentValet doesn’t replace any of that.
It’s also a standard, with the MCP project and major app vendors behind it, which counts for a lot in a field that’s still settling.
Where AgentValet wins
If your agents work outside that circle, as themselves, in a partner’s or client’s tenant, or through a chain of agents, something else has to hold the authority. And inside the circle, a decision at token time isn’t a decision per action. AgentValet checks each call, can ask a person first, and records what was executed with a signed receipt.
Your team signs in to AgentValet through Okta, so the broker sits next to the IdP you already run. It doesn’t replace it.
The two stack, and the standard’s own authors plan for composition: Cross App Access for the hop from your IdP to apps that trust it, other layers for the rest. Use it wherever an app supports it, and put the calls that leave the circle, or need a person’s yes, behind a broker.
Which one fits
Choose Okta Cross App Access if
- Your agents act for signed-in employees in apps that trust your Okta.
- You want your IdP to be the one place that decides which agents reach which apps.
- The apps you care about already support Cross App Access.
Choose AgentValet if
- Agents act as themselves, or in tenants that trust a different IdP.
- A person should approve a risky call before it runs.
- You need a record of what each agent executed, call by call.
Run both if
- You run Okta, and your agents also reach beyond its circle.
- Identity owns which apps; security owns which actions.
Checked against the ID-JAG draft (-04), the MCP Enterprise-Managed Authorization extension, Okta’s Agent SSO announcement, Okta’s XAA developer guide and Claude’s connector authorisation guide on 8 October 2026. If something has changed, report a correction and we’ll fix the page.
Keep your IdP. Add the per-call check.
Register one agent on the free plan with npx @agentvalet/register, grant it one scope, and put an approval rule on one risky action. The call waits for a person, and the record shows who said yes.
npx @agentvalet/register