OpenRouter received a lot of attention recently when they agreed to join Stripe in a deal reported to be worth more than $8 billion. $8 billion for an AI gateway gets attention. Unified model access, routing, and brokerage have become strategic infrastructure.
But in our work with large enterprises, OpenRouter is not an approved standard for routing to models. It does exist, as shadow IT always does, but the blessed path usually belongs to a central AI or platform team. These teams are building an enterprise version of what developers like about OpenRouter and many are using agentgateway to build it.
So what changes when an enterprise builds this platform for itself?
Platform teams want to introduce new models and providers quickly but that does not mean “anything goes.” Licenses, data-handling practices, regions, and use cases must be vetted before they become part of the “approved catalog”. The platform exists in part to prevent every developer or agent from bringing an unknown provider into the environment with a credit card and an API key (i.e., making the shadow bigger).
The platform must also fit the enterprise’s existing security architecture. For example, identity should come from the systems the company already trusts. Authorization policy should be based on verified users, workloads, agents, groups, and delegated authority. Credentials should not be copied into every application (no API keys!!). Network paths, audit records, and policy administration should fit existing operational controls rather than create a parallel island.
These differences show up in three big areas.
Enterprise identity is the foundation of governance
An enterprise gateway should recognize the identities the company already issues to people and workloads. Agentgateway supports the main paths:
- Browser-based users can enter through enterprise SSO using OIDC.
- Applications and API clients can present JWT access tokens from an OAuth or OIDC provider. Agentgateway validates the signature, issuer, and audience before policy can use the token’s claims.
- Workloads can authenticate through mTLS and SPIFFE. Agentgateway can retrieve rotating X.509 SVIDs and trust bundles from the SPIFFE Workload API and expose the verified SPIFFE ID to policy.
- When an agent or service acts for a user, Agentgateway can exchange the user’s token through RFC 8693, an RFC 7523 JWT bearer grant, or Microsoft Entra on-behalf-of instead of impersonating the user or sharing a general-purpose credential.
These identities become inputs to authorization. Policy can use the JWT subject, tenant, groups, scopes, and custom claims; the SPIFFE ID of the calling workload; and request context such as the selected model or target. The decision becomes “this finance workload, acting for this user, may call this approved model,” not “someone has the production key.”
Inbound identity and upstream credentials are separate concerns. After Agentgateway authenticates and authorizes the caller, it supplies whatever the backend requires. It can inject a provider API key without exposing it to the caller, use an AWS IAM role, Google service account, or Azure managed/workload identity, or exchange the user’s token for one scoped to a downstream service.
That is the job of the enterprise security boundary: establish the principal, authorize the request in context, and broker the upstream credential.
Keep the data plane inside the enterprise trust boundary
The gateway is part of the inference data plane. Prompts, responses, credentials, policy decisions, and audit records all pass through it. Where that gateway runs matters.
Agentgateway can run inside the enterprise environment and connect directly to approved model endpoints. The enterprise controls the deployment, network path, logging, credentials, and policy configuration. It can reuse existing provider relationships and infrastructure such as private cloud connectivity, approved regions, workload identities, and internally hosted models.
For an enterprise, OpenRouter adds another processor, credential holder, availability dependency, incident domain, egress path, and vendor compliance assessment. An enterprise-operated gateway cannot eliminate the trust placed in external model providers, but it can avoid adding an intermediary in front of providers the company already knows how to govern. The question is whether model aggregation justifies another trust boundary.
In our experience, it does not justify.
Govern what agents do, not just which model they call
An inference request is only one step in an agent workflow. The model might decide what should happen next, but the consequential operation is usually a tool or API call: reading customer records, changing production, issuing a refund, sending a message, or invoking another agent.
Policy has to follow the identity through that entire path. The user, workload, and delegated authority established in section 1 should determine:
- Which models the agent may use
- Which tools and resources it may discover
- Which operations it may invoke
- Which APIs and agents it may reach
- Which credential the gateway presents downstream
Agentgateway provides one enforcement point for LLM, MCP, HTTP, gRPC, and A2A traffic. For MCP, it can facilitate OAuth flows, validate the client’s JWT, and apply authorization rules to individual tools, prompts, resources, and MCP targets. Tools the principal cannot call are filtered from discovery, so the agent never sees them. The same gateway can apply authorization and credential-brokering policies when agents call HTTP and gRPC services directly.
OpenRouter’s budgets, model restrictions, and guardrails govern inference. They do not determine whether the resulting agent may call payroll.lookup, deploy to production, or send data to another system. Those are authorization decisions at the action boundary.
Agentgateway Standalone
We’ve recently released a version of Solo.io Enterprise for agentgateway that can run standalone, that is, without running on Kubernetes. Previous enterprise versions have been primarily targeted to high-scale platform teams and were built to be Kubernetes native (CRDs, GitOps, no external databases, stateless, etc). Standalone now supports more traditional click-ops style interactions with a familiar backing database (Postgres, etc). We believe this will make it much lower friction for people to get started building an enterprise AI gateway with agentgateway.
%20(1).png)
%20a%20Bad%20Idea.png)
