Upgrade agentgateway and support token exchange (also the path to agent session affinity)

> _Migrated from https://github.com/aws-samples/sample-open-agentic-platform/issues/52 — originally opened by @shapirov103 on 2026-08-11T20:58:59Z._

## Summary

Upgrade agentgateway and add support for **token exchange**, so a request from an agent to an MCP server can carry the end user's identity rather than only the workload's.

## Current state (verified on `peeks-hub`)

- Controller and proxy both run `cr.agentgateway.dev/*:v1.1.0`
- The proxy runs a **single replica**
- CRDs installed are `agentgateway.dev/v1alpha1`: `agentgatewaybackends`, `agentgatewayparameters`, `agentgatewaypolicies`
- `AgentgatewayPolicy` has `traffic`, `backend`, `frontend`, `targetRefs`, `targetSelectors`. The `traffic` section includes `jwtAuthentication`, `extAuth`, `rateLimit`, `authorization` and others, but **no token exchange**
- Auth today: agents present a projected ServiceAccount token (the `gateway-identity` trait) and the gateway validates JWTs. Verified working: an agent loaded 29 MCP tools through the gateway with its SA token

## Why token exchange

Every call from an agent to an MCP server currently carries the **agent's** identity. Any per-user authorization has to happen inside the tool server, and the MCP server cannot know which human is behind a request. The upstream feature set covers this: standard token exchange (RFC 8693), JWT Bearer grant (RFC 7523), on-behalf-of tokens with impersonation and delegation, and elicitations with a consent screen. Those enable per-user scoping and auditable "who asked for this" on tool calls.

## Also unblocked by an upgrade: agent session affinity

#49 found that **agents have no session affinity mechanism** in the current stack, which is a correctness problem rather than a performance one. Agents cache one `Agent` per session in memory, and nothing available can pin an A2A session to a pod:

- Agents register via `HTTPRoute` to a Service, not an `AgentgatewayBackend`, and the backend CRD has **no `a2a` section**
- `BackendConfigPolicy` (`gateway.kgateway.dev`) is **not installed**
- `BackendLBPolicy` (Gateway API) is **not installed**
- The installed Gateway API is v1.5.0 **standard** channel, so `HTTPRoute.sessionPersistence` does not exist
- `AgentgatewayPolicy` has no load-balancing or hash fields

Demonstrated: with the same `contextId` sent to two pods of one agent, the first answered `Teal` and the second replied it had no such information. The old default of `replicas: 3` therefore lost roughly two of every three follow-ups. #49 mitigated this by making `replicas` optional (so one pod) and documenting that scaling requires external state via a memory provider.

MCP servers got a real fix in #49 because `AgentgatewayBackend.spec.mcp` supports **selector-based targets** plus `sessionRouting: Stateful`, verified at 2 replicas. The equivalent for A2A is what an upgrade should be evaluated against.

## Scope

- [ ] Determine the current agentgateway release and what the upgrade path is from v1.1.0, including CRD changes
- [ ] Decide OSS vs Solo Enterprise distribution. Note the published docs describe `EnterpriseAgentgatewayBackend` while we run `AgentgatewayBackend`, so feature availability per distribution needs confirming rather than assuming
- [ ] Evaluate whether a newer release offers A2A session affinity or selector-based targets for agents. If it does, apply it to `agent.cue` the way #49 did for `mcp-server`
- [ ] Implement token exchange for agent-to-MCP calls, and decide where identity is enforced: gateway policy versus tool server
- [ ] Consider scaling the proxy past one replica once stateful routing across proxy instances is understood. Upstream notes stateful sessions are what keep a client pinned to the same proxy instance
- [ ] Confirm whether the agent Service's `appProtocol: kgateway.dev/a2a` is stale. `mcp-server` uses `agentgateway.dev/mcp`, and the inconsistency is unexplained. Agents work today, so plain HTTP routing is evidently in effect, but A2A-aware handling may not be
- [ ] Verify against MCP spec compatibility. The 2026-07-28 spec removes the initialize handshake and session IDs entirely, which changes the affinity picture for anything that adopts it

## Risk

The gateway is on the request path for every agent and every MCP tool call, and it currently terminates JWT auth for all of them. An upgrade needs a rollback plan and end-to-end verification: MCP `tools/list` and a real `tools/call` through the gateway, plus an agent loading tools with its ServiceAccount token. The tests in `applications/browser-mcp/test/` and the gateway harnesses used in #49 cover that path.

Start by reviewing agent.cue and the gateway harnesses used in #49 to understand the current routing and replica setup. Run the tests in applications/browser-mcp/test/ and the gateway verification path for MCP tools and agent ServiceAccount authentication. Done means documenting the upgrade and CRD path, confirming token exchange and A2A affinity options, and recording an end-to-end verification and rollback plan.

Written by the indexing model from the issue text.