WorkOS compares four agent-credential architectures from five vendors and names the gap they share: hiding a credential prevents exfiltration, not misuse. Unstealable is not the same as scoped. This is source notes on that comparison, not a rewrite of the Institute identity playbook.
What WorkOS Published
On September 21, 2026, WorkOS published a comparison of four agent-credential architectures. The setup is familiar: an agent has to call GitHub, a private API, or an MCP server, and the caller is a language model running arbitrary code in a sandbox — a poor place to keep a secret.
Over the prior two months, five vendors shipped four distinct designs. Google and NVIDIA keep the secret out of the sandbox. Rubrik mints a token per tool call. Microsoft inspects MCP on the wire. Opal decides each request and delegates enforcement. WorkOS argues these are not variations on one theme: they intervene at different layers and close different failures. The useful exercise is working out which failure each one actually removes, because most of them leave the same gap.
Egress Proxy And Placeholders: Google And NVIDIA OpenShell
Google's Managed Agents in the Gemini API take the most direct route: the credential never enters the agent's environment. You store a secret once through the API. It is write-only, so no endpoint will return it. You then reference it by ID on a network allowlist rule. At request time, an egress proxy resolves the reference and injects the header on the wire.
If an SDK expects a token from process.env, the variable is still populated — with a placeholder, not the secret. The proxy swaps in the real value only for requests headed to a domain in that credential's trusted_domains. A request carrying the placeholder to any other host is rejected rather than forwarded. Literal values are a different thing: those are readable by anything in the sandbox and belong to config such as NODE_ENV, not to secrets.
The OAuth2 credential type goes further. The proxy holds the refresh token, exchanges it, and refreshes access tokens as they expire, so a long-running session does not break mid-task. Creating the credential performs a live token exchange before storing it.
NVIDIA's OpenShell implements the same shape with sharper edges. Credentials are first-class objects called providers, attached explicitly per sandbox at creation time. There is no inheritance from the host environment. A provider cannot be attached to a running sandbox, so scope cannot be widened after the fact, and everything is purged when the sandbox is deleted.
Two OpenShell details matter for anyone building this layer:
- The binding is to an endpoint, not just a domain. A static credential resolves only when the request host, port, and path match an endpoint in the provider's profile. Send the built-in
GITHUB_TOKENplaceholder to a host the policy otherwise allows, and the proxy returns a 403 with reasoncredential_endpoint_mismatch, records a denied event, and logs none of the secret, placeholder, or query string. - OpenShell assumes the agent will try to go around the proxy. Seccomp blocks raw socket syscalls because those are the bypass paths, and a network namespace forces ordinary egress through a local CONNECT proxy. A proxy you can route around is a suggestion.
OpenShell also does real token exchange. Provider profiles can declare dynamic token grants. client_credentials grants use the supervisor's SPIFFE JWT-SVID as the client assertion. token_exchange grants have the gateway broker an intermediate token using its own JWT-SVID, which the supervisor then exchanges for the final upstream token. The gateway validates the audience, the SPIFFE subject, the expiry, and that both SVIDs sit in the same trust domain. That is a workload identity chain, not a secret store with a proxy in front of it.
Per-Call Token Mint: Rubrik Agent Identity
Rubrik Agent Identity, announced at Black Hat on August 4, attacks a different problem. The agent does hold a credential. It just holds one that is worth almost nothing.
Enforcement sits at an MCP gateway. Every tool call clears three checkpoints before it executes: Rubrik's SAGE engine analyzes the request's intent, parameters, and likely impact; a policy check runs at the infrastructure layer; then an identity step authenticates the agent session and mints a token scoped to that single call. An unauthorized write outside explicit policy scope is blocked before execution rather than caught afterward.
Access is scoped to servers and tools by user and group using On-Behalf-Of federation, which extends the identity structures an organization already has. Rubrik states RBAC parity between agents and humans: the agent cannot exceed the permissions of the user behind it.
Rubrik MCP followed on September 15, co-engineered with Anthropic. It exposes the Rubrik Security Cloud API schema to connected agents with guardrails aligned to the OWASP MCP Top 10. It is in private preview, with general availability targeted for October.
MCP Protocol Firewall: Microsoft Global Secure Access
Microsoft's Global Secure Access MCP firewall, in public preview, is the outlier: it does not handle credentials at all. It is a network control that inspects MCP traffic — JSON-RPC 2.0 over streamable HTTP and Server-Sent Events — and enforces allow or block decisions on what it sees.
WorkOS lists the controls as:
- Deny all MCP traffic tenant-wide until a set of servers is approved.
- Allow or block servers by URL pattern.
- Permit or deny individual primitives, tools, resources, and prompt templates on a per-server basis.
- Block specific methods, unencrypted HTTP transport, and outdated protocol versions.
Policies attach to a Global Secure Access security profile and are enforced through Conditional Access. Microsoft's claim is that this extends identity-based access, Conditional Access, and Continuous Access Evaluation to the MCP protocol layer without changing the spec, or client, host, or server implementations.
Two hard limits sit in the docs. It needs TLS inspection turned on, because MCP rides inside HTTPS and the firewall cannot see the method or tool otherwise. And it only covers remote servers on HTTP transports. Anything over stdio does not traverse Global Secure Access and is not covered, which excludes most of what developers run locally today.
Decide, Then Delegate: Opal Zero
Opal Zero, launched September 17 with general availability at the end of the month, separates the decision from the enforcement. An agent files a request through Opal's MCP server. Paladin, Opal's reasoning model, evaluates it against written policy and organizational context — who owns the agent, what it was built for, and whether the request reaches past what the owner themselves holds. It shows its reasoning and leaves an audit trail.
Then Gateway Sync writes the decision as scoped, time-bound policy into the MCP gateway the enterprise already runs. Databricks Unity Gateway and AWS AgentCore Gateway are supported at launch. WorkOS frames this as no second control plane and no rip-and-replace.
It ships with connectors for Okta Cross App Access and for Claude's Enterprise-Managed Authorization for MCP connectors. WorkOS presents that as putting Opal on top of the standards track rather than beside it.
What Each Architecture Removes
WorkOS's comparison table is the operator-facing summary. Each design closes one failure and leaves another:
| Approach | Failure it removes | Failure it leaves |
|---|---|---|
| Egress proxy with placeholders (Google, NVIDIA) | Credential theft from the sandbox, credentials in logs or model context | Over-broad credential scope, confused deputy |
| Per-call token minting (Rubrik) | Standing privilege, credential reuse across actions | Requires a gateway in the path for every call |
| Protocol inspection (Microsoft) | Unapproved servers and tools, protocol downgrade | Nothing about what the token means; stdio uncovered |
| Decide then delegate (Opal) | Permanent grants, unowned agents, unreviewed access | Depends on a gateway that can enforce what it writes |
Unstealable Is Not The Same As Scoped
The core claim, quoting Google's own agents documentation via WorkOS, is that unstealable is not scoped. Google writes: "The agent may use any credential it has access to, so only provide credentials whose full scope you are willing to grant."
An egress proxy makes a credential impossible to exfiltrate and does nothing to narrow what it can do. From inside the perimeter, the placeholder is exactly as powerful as the secret it stands for. If the stored token is a GitHub PAT with write access to forty repositories, the agent has write access to forty repositories. It simply cannot mail the token to anyone.
That is a containment control, not an authorization one. Hiding a credential from the agent tells you nothing about whether the action it just took was one it should have been able to take.
The second half of the gap is the confused deputy. If a proxy will authenticate any request the agent makes to an allowlisted domain, then a prompt injection that persuades the agent to make a different request to that same domain gets authenticated too. NVIDIA's endpoint binding — down to host, port, and path — is the sharpest answer among the five, and it is a scoping mechanism rather than a secrecy one.
This is also why the two proxy designs converge on token exchange as they mature. OpenShell's token_exchange grants, brokered against a SPIFFE identity with audience validation, are an authorization server reached by a different route. Google's OAuth2 credential type, holding a refresh token and minting short-lived access tokens per request, is the same recognition. Both arrived at the conclusion that the durable answer to "what may this agent do right now" is a short-lived token bound to a specific audience, because that is the only artifact the resource server can check for itself.
The Authorization Server Still Has To Mint The Token
WorkOS says the MCP authorization spec already describes that artifact, and that none of the four architectures can supply it on their own. Under the current 2026-07-28 revision, an MCP server is an OAuth resource server. It validates every token and confirms the token was issued specifically for itself as the intended audience. Clients must send the resource parameter from RFC 8707 on both the authorization and token request, naming the server's canonical URI. Servers must not accept tokens issued for anything else, and must not forward a token they received upstream.
Those rules close the failure a proxy cannot reach. A token that is audience-bound cannot be replayed against a second server even by an agent holding it legitimately. A token that carries the intersection of what the agent may do and what the human behind it may do — which is what Rubrik's On-Behalf-Of federation and Okta's Cross App Access both compute — cannot be used to exceed its principal. Neither property comes from where you stored the secret. Both come from who minted the token and what they put in it.
The practical read in the piece: the gateway, the proxy, and the firewall are all legitimate layers, and a serious deployment will likely run more than one. Network-level inspection catches the server you did not approve. A sandbox proxy keeps secrets out of model context. A gateway gives you a place to enforce a decision per call. None of them substitute for an authorization server that issues scoped, audience-bound, short-lived tokens, because that is the one control the resource server can verify without trusting anything upstream of it.
WorkOS also positions AuthKit as implementing CIMD registration, resource indicators, protected resource metadata, and issuer validation, so what stays in the MCP server is validating the token and deciding what its bearer may do. That is vendor context for how WorkOS implements the spec, not an Institute endorsement of AuthKit.
What The Piece Does Not Prove
- The four architectures and the shared gap are WorkOS's reading of vendor designs. This post does not add Institute scores, adoption counts, or a ranked winner.
- Microsoft's MCP firewall is in public preview and does not cover stdio or local MCP. Rubrik MCP is in private preview, with general availability targeted for October. Opal Zero's general availability is described as the end of September.
- AuthKit, CIMD, resource indicators, and protected resource metadata are how WorkOS describes its own implementation. They are not an Institute product recommendation.
- This Field Notes is the source primary on the comparison. It is not a rewrite of the Agent Identity & Know-Your-Agent playbook, which is a separate identity-plane recipe.
- Hiding a credential is a containment control. The durable authorization artifact named here is an audience-bound, short-lived token the resource server can verify itself.
Related: See our notes on NIST's agent identity foundation and Meta putting permission outside the agent.