fix: ensure user identity is propagated across A2A requests/sessions

[onematchfox]

Ensures that caller identity correctly propagates from controller->agent->controller.

Addresses #1293 (comment) and potentially also #1771

[Copilot]

Pull request overview

This PR fixes identity propagation for proxy-based authentication by ensuring the controller forwards the authenticated user ID to downstream A2A runtimes via the X-User-Id header (in addition to forwarding Authorization when present), aligning behavior with UnsecureAuthenticator.UpstreamAuth.

Changes:

• Update ProxyAuthenticator.UpstreamAuth to set X-User-Id from the authenticated session principal.
• Extend TestProxyAuthenticator_UpstreamAuth to assert X-User-Id forwarding.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
go/core/internal/httpserver/auth/proxy_authn.go	Forward X-User-Id (and Authorization when available) for upstream A2A requests under proxy auth.
go/core/internal/httpserver/auth/proxy_authn_test.go	Add test assertion ensuring X-User-Id is forwarded in UpstreamAuth.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[onematchfox]

Seeing some unexpected behaviour when running this change in a live environment (that I didn't see in testing) - may need some additional changes.so reverting to draft for now until I understand what's going on.

[onematchfox]

FYI @supreme-gg-gg, I think I might just end up fixing #1771 as part of this

[onematchfox]

This is a change in behaviour as it requires that a Bearer token be provided whereas the original code allowed any caller that knew the X-Agent-Name and X-User-Id to bypass use of a Bearer token. By default any agent created via the Agent CRD will supply a Bearer token - so this would only affect direct consumers of the API that are currently relying on this insecurity.

[EItanya]

Thanks so much for the change. I think we need to really think through this though. This adds an implicit x-user-id reliance around the system when we are already authenticated, which doesn't carry the same gaurantee as a JWT. Is there a way we could get this information from the JWT instead?

Also, yes I recognize that we already have a weird reliance on x-user-id in some places, so trying to make that better going forward

[onematchfox]

Is there a way we could get this information from the JWT instead?

The tricky part is here is that agent pods don't use the forwarded user JWT when making their own outbound calls back to the controller. They authenticate with their SA token (via withBearerToken / KAgentTokenService), and the user identity has to ride alongside as X-User-Id.

Also, as you acknowledge, X-User-Id is already deeply embedded across the codebase; not just in the paths this PR touches, but in other agent runtimes (e.g. langgraph) that I'm not comfortable changing here - let alone me touching Agent STS (guessing this is something the enterprise version uses). So, ripping it out would be a much larger, higher-risk change that is well beyond the intent of this PR. The goal here was simply to ensure that the existing X-User-Id mechanism is applied consistently and correctly across A2A calls, closing the identity propagation gap rather than redesigning the mechanism. Can we perhaps tackle that as a separate issue?

[EItanya]

Is there a way we could get this information from the JWT instead?

The tricky part is here is that agent pods don't use the forwarded user JWT when making their own outbound calls back to the controller. They authenticate with their SA token (via withBearerToken / KAgentTokenService), and the user identity has to ride alongside as X-User-Id.

Also, as you acknowledge, X-User-Id is already deeply embedded across the codebase; not just in the paths this PR touches, but in other agent runtimes (e.g. langgraph) that I'm not comfortable changing here - let alone me touching Agent STS (guessing this is something the enterprise version uses). So, ripping it out would be a much larger, higher-risk change that is well beyond the intent of this PR. The goal here was simply to ensure that the existing X-User-Id mechanism is applied consistently and correctly across A2A calls, closing the identity propagation gap rather than redesigning the mechanism. Can we perhaps tackle that as a separate issue?

Ok I buy that, my one remaining question is why then you are still using the user_id query param instead of just using the x-user-id. Specifically I'm looking at the Python diff

[onematchfox]

Ok I buy that, my one remaining question is why then you are still using the user_id query param instead of just using the x-user-id. Specifically I'm looking at the Python diff

The changes to those lines were made specifically to avoid duplicating setting the X-User-Id header. The query string parameter remains because I was purely focussed on the X-User-Id header and didn't really want to touch all the other code that might be using the query string parameter. I wasn't sure if this is still needed in the event that oauth2-proxy is not enabled or whether other agent types still require this. 😅

I asked my clanker to check and yes, it looks like user_id should now be redundant although it did call out one edge case

for comparison of flow between auth types (oauth2-proxy vs unsecure)

The query param is redundant in the normal A2A flow — but ContextVar doesn't propagate across async task boundaries, so if a session call is made outside the A2A request handling context, get_request_user_id() returns None, the token service doesn't inject the header, and the query param is the only thing carrying identity.
...
So yes, user_id query param is now redundant in both modes. The header chain is complete in both oauth2-proxy and non-oauth2-proxy paths.
...
The only remaining caveat is the async context boundary case (a session call made from a task spawned before set_request_user_id runs), but that's not a realistic path for session
service calls made during A2A request handling.
...
Should we drop it? Yes, it's safe to drop — but as a separate cleanup PR, since it requires verifying no call site bypasses the A2A request handler context.

and for other agent types

The other agent types don't use KAgentTokenService at all — they're a completely different picture.

• kagent-openai (_session_service.py): explicitly sets headers={"X-User-ID": self.user_id, "X-Agent-Name": self.app_name} AND user_id query params on every call. No token service, no context var. Both are hardcoded per request.
• kagent-langgraph (_checkpointer.py): plain httpx.AsyncClient passed in from outside, manually sets headers={"X-User-ID": user_id} on each call. No SA token, no token service.
• kagent-crewai (_memory.py): creates a fresh httpx.Client() (sync) per call, manually sets headers={"X-User-ID": self.user_id}. No token service at all.

None of them go through the KAgentTokenService event hook, so set_request_user_id / get_request_user_id is irrelevant to them. They rely entirely on the manually-set X-User-ID header for identity.

Dropping user_id query params would be safe for all these runtimes (their explicit X-User-ID header covers both the auth layer and getUserID() fallback in the Go handlers), but this PR only touched kagent-adk and these others weren't updated. A cleanup of user_id query params across all runtimes would need to touch all four packages.

So, what are your thoughts? Want to do this cleanup as part of this PR or as a separate piece of work? I'm happy with either.