Release notes

Review the release notes for agentgateway standalone.

🔥 Breaking changes

MCP authentication moved to route level

MCP authentication is configured at the route level under policies.mcpAuthentication. The route-level placement aligns MCP auth with other route-level policies and allows JWT claims to be used in authorization, rate limiting, and transformation policies.

• Before: MCP authentication was configured as a backend-level policy.
• After: MCP authentication is configured under routes[].policies.mcpAuthentication.

No YAML structure changes are required for standalone users, as standalone configuration already placed mcpAuthentication under route policies. However, if you have automation or tooling that references MCP authentication as a backend-level concept, update it accordingly.

For more information, see MCP authentication.

🌟 New features

OIDC browser authentication

A new oidc route policy provides built-in OpenID Connect browser authentication with PKCE support, encrypted session cookies, and automatic redirect handling. The OIDC policy is a native alternative to deploying an external proxy like oauth2-proxy.

policies:
  oidc:
    issuer: http://keycloak.example.com/realms/myrealm
    clientId: agentgateway-browser
    clientSecret: my-secret
    redirectURI: http://localhost:3000/oauth/callback
    scopes:
    - profile
    - email

For more information, see OIDC browser authentication.

L4 network authorization

A new networkAuthorization frontend policy enables Layer 4 network authorization for non-HTTP traffic. You can enforce policies based on source IP, port, and mTLS client identity before HTTP processing begins. Combine with HTTP authorization for layered L4+L7 controls.

frontendPolicies:
  networkAuthorization:
    rules:
    - allow: 'source.address.startsWith("10.")'
    - require: 'source.tls.identity == "spiffe://cluster.local/ns/default/sa/my-service"'

For more information, see Network authorization.

Authorization require rules

Authorization policies now support require rules in addition to allow and deny. The require rule type provides clearer semantics for expressing mandatory conditions. All require rules must match for the request to proceed.

authorization:
  rules:
  - require: 'jwt.aud == "my-service"'

For more information, see HTTP authorization.

MCP improvements

• Stateless sessions: OpenAPI and SSE upstreams can now use stateless sessions, avoiding state persistence for backends that don’t need it. For more information, see OpenAPI connectivity and Backends.
• Explicit service reference lists: MCP backends can specify targets with explicit service references.
• Tool payloads in CEL context: Tool names and payloads are available in logging CEL expressions via mcp.tool.name and other mcp.tool.* fields.

LLM gateway enhancements

• Path prefixes: LLM providers now support pathPrefix for custom API base paths. For more information, see Providers.
• Azure default authentication: Azure OpenAI providers can use platform-default authentication. For more information, see Azure.
• Vertex region optional: Vertex AI region configuration is now optional with a global default. For more information, see Vertex AI.

Gateway and routing improvements

• Automatic protocol detection: A new auto bind protocol peeks at the first connection byte to determine TLS vs HTTP, simplifying mixed-protocol environments. For more information, see Listeners.
• Service SANs for upstream TLS: Upstream TLS now respects Subject Alternative Names from Kubernetes Services. For more information, see Backend TLS.
• CEL hash functions: New sha1.encode, sha256.encode, and md5.encode functions are available in CEL expressions. For more information, see CEL expressions.