Solo Enterprise for agentgateway 2.3: AWS Bedrock AgentCore, Intelligent Failover, and Deeper MCP Control

April 15, 2026

Pete Muir

Sam Heilbron

Solo Enterprise for agentgateway 2.3 is now generally available. The major new feature in this release is improved support for AWS Bedrock AgentCore as well as a broad set of improvements to automatic failover, MCP authentication, token exchange, observability, and authorization policy ergonomics.

Enterprise Authentication for AWS Bedrock AgentCore

Amazon Bedrock AgentCore is a popular platform for deploying custom-built AI agents, but enterprises consistently run into the same challenge: how do callers authenticate to an agent, and how does the agent know who is calling? AgentCore offers two inbound authentication modes, and each has a real limitation:

SigV4 (AWS IAM): gives strong caller authentication, but the token carries no user identity context. The agent knows a trusted AWS principal called it, not which user or team initiated the request.
JWT/OIDC: provides user identity context, but the built-in claim checking is basic, and there is no native way to represent an agent acting on behalf of a user.

Enterprises need compliance, audit trails, and least-privilege access control, and therefore neither mode alone is sufficient. Solo Enterprise for agentgateway 2.3 helps close that gap by enabling three patterns.

Pattern 1: OBO Token Exchange

Solo Enterprise for agentgateway performs a token exchange (RFC 8693) combining the user’s JWT and the agent’s identity (e.g. a Kubernetes service account token, SPIFFE, OAuth client credentials, etc) into a single On-Behalf-Of (OBO) token. The AgentCore agent’s inbound auth is configured in JWT mode and verifies this OBO token, including both user and agent claims.

Pattern 2: JWT Pass-Through with SigV4

Solo Enterprise for agentgateway authenticates to AgentCore with SigV4 (IAM), but passes the user’s original JWT (or an OBO-exchanged JWT) as a custom header. The agent code is responsible for decoding and verifying the JWT.

Pattern 3: Claims as Headers

Solo Enterprise for agentgateway validates the JWT at the edge and extracts verified claims (e.g. sub, roles). It then calls AgentCore with SigV4 and injects those claims as headers. The agent never sees or verifies a JWT, it receives pre-validated identity attributes.

For a detailed walkthrough of how agentgateway and AgentCore work better together, see Christian Posta's post: Inbound Auth for AgentCore with agentgateway.

What Else Is New

Route-level MCP authentication

In 2.2, agentgateway introduced seamless MCP authentication at connect time, solving the OAuth pop-up interruption problem for desktop AI agents. In 2.3, that authentication story becomes more composable. MCP authentication can now be configured at the route level, which means you can combine it directly with rate limiting, JWT claim-based transformations, and authorization policies in the same route definition. If your MCP server access needs to vary by user group, organization, or token claim, this is the configuration model that makes that possible. The previous backend-level configuration continues to work.

Intelligent LLM failover with CEL eviction

A new CEL-based health checking and eviction policy provides more flexibility and enables automatic backend failover for LLM provider groups. When a provider returns an unhealthy response (a 5xx, a rate limit rejection, or any other condition you can express in a CEL expression), it's evicted for a configurable duration and traffic shifts to your fallback providers. When the primary recovers, it's automatically restored. This is the foundation for cost-aware and reliability-aware multi-provider routing: prefer a cheaper model unless it's struggling, then fail over to a more reliable one automatically.

OpenAPI-backed MCP tool discovery

The new EnterpriseAgentgatewayBackend CRD adds support for inline OpenAPI schema definitions. If you have existing REST APIs documented in OpenAPI specs, agentgateway can now use those specs to make tools available to AI agents via MCP, with no live MCP server required and no changes to your backend services. For enterprises with years of existing APIs, this is the most direct path from where you are today to a world where agents can use those APIs as tools.

OBO token claim propagation

In On-Behalf-Of token exchange flows, the gateway now lets you explicitly forward specific claims from the original subject and actor tokens into the generated OBO token. Without this, downstream services that make authorization decisions based on claims like groups, department, or tenant_id would see a valid token with no useful claim context. With allowedSubjectClaims and allowedActorClaims configured, the relevant claims travel through the full chain.

Failure mode control for external auth and rate limiting

External authorization and remote rate limiting policies now support an explicit failureMode field. You can now declare whether an unreachable ext-auth or rate limit backend should fail open or fail closed, rather than relying on implicit defaults. In high-availability configurations, the right behavior under backend failure is a deliberate policy choice.

Platform and operational improvements

Prompt cache token metrics: input_cache_read and input_cache_write token types are now tracked in metrics, giving visibility at the gateway layer into whether prompt caching is actually reducing costs.
OpenTelemetry environment variable support: agentgateway now respects the standard OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES environment variables, making it easier to drop into an existing observability stack without custom gateway configuration.
Auto-TLS protocol detection: a single listener can now auto-detect TLS vs plaintext HTTP on the first byte of each connection, removing the need for separate bind configurations.

For the full list of changes, see the release notes.