AI Agent Identity and Access Control: TrueFoundry vs OpenRouter (2026)

The question an AI gateway has to answer first is not which model to call but who, or what, is calling. Two years ago the answer was almost always a human with an API key. Today most requests through a gateway come from services, CI pipelines and agents, and the identity model decides whether a production system survives the day its creator leaves the company. That makes AI agent identity a primary evaluation criterion rather than a compliance footnote, and it is where TrueFoundry AI Gateway and OpenRouter diverge most sharply.

This post compares the two on the full identity heading: human identity (SSO, SCIM, MFA), workload and agent identity, authentication and authorization granularity, MCP authentication and tool authorization, credential lifecycle, and delegation. It is written for platform engineers and security teams running an evaluation, and every claim is drawn from the two vendors' public documentation. If you are already past the evaluation stage, you can book a TrueFoundry demo to see agent identities and tool-level RBAC live.

TrueFoundry vs OpenRouter on identity: at a glance

Human identity: SSO, SCIM and MFA

TrueFoundry supports SSO over SAML 2.0 and OIDC, with per-IdP guides for Okta, Microsoft Entra, Google Workspace and JumpCloud, and SCIM provisioning of users and teams for Okta, Entra and JumpCloud (SSO overview). We keep our own user store and federate it three ways: SSO for login, SCIM for lifecycle, and Identity Providers for runtime token validation, covered below. One footnote belongs here as well as in our deployment post: by default, login transits our hosted auth server even in self-hosted deployments; on on-prem deployments on the higher-tier Enterprise plan, a Direct IdP integration removes that path — the control plane talks to your OIDC or SAML IdP directly and tokens are signed locally, so authentication traffic never leaves your environment (external SSO).

OpenRouter SSO is SAML, with named support for Okta, Microsoft Entra ID, Google Workspace or any custom SAML provider, on Enterprise plans only. Setup is self-serve: add your email domain, verify it with a DNS TXT record, connect the IdP, test and activate. OIDC is not named anywhere in its documentation. SCIM is supported with the IdP as source of truth, and SCIM Group Mappings map IdP groups to workspaces with a chosen role, including a “Refresh from IdP” action and audit-log entries for removals. One offboarding detail deserves attention from any security team: IdP deactivation revokes the organisation's access and deactivates the keys that user created in the organisation, but the individual's personal OpenRouter account and personal keys survive, and nothing stops that account calling the same models on its own credits, the keys that user created are deactivated across all of the organization's workspaces, and their memberships in other organizations are untouched; only deletion of the OpenRouter account itself ends personal access.

Neither vendor documents native MFA. Both delegate it to the identity provider through SSO, which is the right answer for an enterprise and the wrong answer for a team without an IdP.

AI agent identity and workload identity

This is the sharpest contrast on the heading, and the reason identity has become a procurement question rather than an admin setting.

TrueFoundry has three principal types. Users hold personal access tokens, which our documentation explicitly warns against using in production. Virtual accounts are first-class non-human identities for applications, services and CI, one per application recommended, with their own tokens that are separate from any user's (virtual accounts). Agent Identity, currently in beta, is a third principal type created 1:1 when an agent is registered, issued either by TrueFoundry or by your IdP, so an agent neither borrows a user's token nor hides behind a shared service account; an embedded agent's outbound calls are governed even when the gateway does not front its inbound traffic (agent identity). The beta label matters and we state it: the capability is documented, not GA.

OpenRouter has no distinct non-human principal. There is no service account, virtual account or agent identity; every key is created by and belongs to a human user inside a workspace. What exists instead is programmatic key management. An OpenRouter provisioning key, generated in the dashboard, can manage other keys but cannot call completions; you use it against the /api/v1/keys endpoints to mint per-developer or per-project keys, each with an optional label and spend limit, and management keys operate at account level. A labelled, spend-limited key is better hygiene than one shared secret, but it is still a user's credential, and OpenRouter's own SCIM behaviour proves the coupling: deprovision the human and the keys they created are deactivated. A production service whose key was minted by an engineer who has since left stops working. That is the concrete operational risk, and it is the row to put in front of anyone evaluating OpenRouter for a fleet of services rather than a team of developers.

AI agent authentication and authorization: how fine-grained?

Authentication proves who is calling; authorization decides what they may do. In the first half both vendors accept bearer tokens at an OpenAI-compatible endpoint. In the second half they diverge.

TrueFoundry's authorization is RBAC, evaluated against the resolved identity, whether that is a user, a virtual account or an agent, at three levels: which models a principal may call, which MCP servers it may reach, and which individual tools within an MCP server it may invoke (user, team and account management). It is not ABAC; attribute- and condition-based rules live in our guardrail layer (Cedar and OPA policies), not in the authorization model. Scoping is identity-mediated: you scope the principal, not the token, which keeps the lifecycle clean when tokens rotate.

OpenRouter's authorization is RBAC with two roles. Org admins hold admin permissions across every workspace (keys, guardrails, BYOK, routing, presets, plugins, observability, members, settings) and only they can create or delete workspaces; members hold member permissions in each workspace they belong to; SCIM group mappings choose between those same two roles. Finer control arrives through guardrails attached to keys or members (budgets, model and provider allowlists, privacy and content controls), with the account-level policy as a ceiling a workspace can only narrow. Model-level restriction is possible via policy; route-, tool- and parameter-level restriction is not. What sits between “admin of everything” and “member” is thin: Workspace Admins can now issue workspace-scoped management keys that act only inside their workspace — a real delegation of key administration — but there is still no read-only auditor and no budget-owner role, and SCIM group mappings still choose between the same two org roles. For a 50-engineer organisation that wants one person to own a team's budget without owning the account, that is the row to watch.

For a broader look at how agents themselves are governed once authenticated, our agent gateway explainer covers the runtime side.

MCP authentication and tool authorization

MCP authentication is where the two products stop being comparable, because only one of them sits in front of your MCP servers.

TrueFoundry models two layers explicitly. Inbound authentication (who is calling the gateway: a PAT, a virtual account token or your IdP's JWT) is separated from outbound authentication (whose credentials reach the downstream MCP server), with RBAC deciding which users and agents can reach which servers and which individual tools in between. User consent is modelled on the outbound leg as an OAuth flow in which the end user authorises the MCP server with their own identity, documented end to end for Okta and Azure Entra, with per-server auth overrides (MCP gateway auth and security, tool approval). If you are new to the protocol side of this, our primer on MCP authorization covers the sp

OpenRouter does not govern your MCP servers. Its Agent SDK can now wire a remote MCP server into an agent loop client-side (@openrouter/mcp, HTTP/SSE), but that connection carries whatever credentials your application holds — there is no gateway-side model for how a tool call carries or checks identity, no per-tool grants, and no consent step. Its own MCP server authenticates you to OpenRouter's catalogue, which is inbound access to OpenRouter, not authorization of your tools. The closest surface is its server-operated tools: shell and bash run in containers scoped per account and workspace and never shared across tenants, and bash's engine field decides whether execution happens server-side or is returned to your application. It is isolation, not authorization: no per-tool grants, no consent.

Credential lifecycle: issuance, rotation, revocation

TrueFoundry virtual account tokens support auto-rotation on a configurable interval with a configurable grace period for the old token, rotation notifications by email or Slack, and automatic sync of rotated tokens into AWS Secrets Manager and Parameter Store, GCP Secret Manager, HashiCorp Vault and Azure Key Vault (virtual accounts). Personal tokens die with the user. Revocation propagation delay is not documented; configuration syncs to gateway planes over NATS, so it should be near real time, but it is a test-it-yourself item.

OpenRouter has three issuance paths: the dashboard, the Management API via a provisioning key, and OAuth PKCE. For inference keys, spend limits and reset intervals (daily, weekly or monthly at midnight UTC) substitute for TTLs and no expiry is documented. Management keys now support an expiration date — fixed at creation, not extendable (create a new key to extend), with requests failing 401 “API key expired” afterwards — and OpenRouter recommends setting one on every management key. Rotation is programmatic regeneration, with no scheduled auto-rotation or grace-period mechanism. Revocation is via dashboard, Management API or SCIM deactivation, with propagation delay not documented. One operational wrinkle: removing a member from a workspace requires deleting the keys they created there first.

Delegation: OAuth PKCE vs runtime IdP JWT

Both vendors support delegation, in forms built for different buyers.

OpenRouter OAuth is PKCE, and it is unusually well developed. A third-party app sends the user to openrouter.ai/auth with a callback URL and a code_challenge; after the user authorises, the app exchanges the code at /api/v1/auth/keys for a key that spends from that user's own credits. The authorization codes are single-use and expire after 10 minutes. No client registration, no client secret, no backend, and localhost callbacks on any port for local CLI tools. For consumer apps and developer tools this is a real strength and we concede it fully. What it is not: the result is a long-lived API key rather than a scoped, expiring token, there is no refresh mechanism, and delegation happens once at authorisation time with no per-request identity propagation. There is also no documented path to present your IdP's JWT to the inference API; every request carries an OpenRouter-issued key, so the caller's real identity has to be reconstructed downstream from key labels.

TrueFoundry's delegation is built for the enterprise case. With Identity Providers, an external app or user presents your IdP's JWT directly to the gateway; we validate it via JWKS and resolve it to a TrueFoundry identity for RBAC, preserving the upstream user's identity on every request without minting a TrueFoundry token at all (identity providers). The MCP outbound OAuth leg acts as user-delegated access to downstream tools. Formal RFC 8693 token exchange is not documented on either side.

TrueFoundry vs OpenRouter: identity head-to-head

TrueFoundry capabilities are from our documentation; OpenRouter capabilities reflect its publicly documented functionality at the time of writing.

When to choose OpenRouter

• Your callers are individual developers, each with their own key and spend limit, and a two-role model covers how your organisation actually works.
• You are building a consumer app or a CLI tool where end users should pay for their own inference; OpenRouter's OAuth PKCE flow is the cleanest implementation of that pattern available.
• You do not have an IdP in the loop yet and are not ready to pay for Enterprise to get SSO and SCIM; OpenRouter's provisioning keys give you labelled, capped per-project keys at no extra cost.

When to choose TrueFoundry

• Services, pipelines and agents make most of your calls and need identities that outlive the people who set them up. Virtual accounts and agent identities exist for exactly this.
• Your identity provider must be in the loop at request time, not only at login, so that a user's real identity reaches the gateway on every call without a gateway-issued token in between.
• You need roles between “everything” and “member”: a team manager who owns a budget, a model-account manager who does not own the tenant.
• Your traffic includes your own MCP tools and agents, and tool calls must be authorised per tool with the end user's consent and the right downstream credentials.
• Rotation has to be automatic and land in your secret manager, not be a calendar reminder.

For the wider field of gateways that offer workload identity and SSO below an Enterprise tier, see our guide to OpenRouter alternatives.

Related reading

• What is MCP Authorization? — the protocol-level primer behind the MCP section
• Identity and Access Management Overview — introduction to TrueFoundry’s tenants, users, teams, virtual accounts, SSO, provisioning, identity providers, and access control
• Agent Gateway — how governed agent runtimes work
• AI Agent Registry — registering and governing agents at scale
• MCP Server Security Best Practices — hardening the servers your agents call
• OpenRouter Alternatives — the wider field of enterprise options

Conclusion

OpenRouter's identity model is a developer's: humans own keys, two roles cover the organisation, and its best feature lets other people's apps spend a user's credits safely. TrueFoundry's identity model is a platform's: three principal types, runtime federation with your IdP, rotation that lands in your secret manager, and authorization that reaches down to an individual MCP tool. On AI agent identity specifically, one product has it and one does not, and that single row will decide the evaluation for any organisation whose services and agents outnumber its developers.

If you are evaluating how agents and services will authenticate to your models and tools, book a demo to see virtual accounts, agent identities and tool-level RBAC on the TrueFoundry AI Gateway.