[0.9.4: ] JWT gets lost in a setup of A2A orchestrator -> A2A Sub agents -> MCP server

[franksgit]

Describe the bug
My setup:

1. A2A Main service
2. A2A Subagent
3. MCP server (exposed as tool of A2A Subagent) The MCP service is defined via @cap_js/mcp annotation and is refered to as:
   cds.requires. "mcp-bpread": {"kind": "mcp", "credentials": { "destination": "mymcp_bpread","path": "/bpread"} },

I am using IAS as authentication against the A2A main service. All of the 3 components are created as separate services in a single CAP 10 project and bound to the same IAS app.
Then I ask a question that invokes the subagent that invokes the MCP server.

I get a 401 of the MCP server as JWT seems to not flow down all the way to the MCP server invokation.

To Reproduce
Steps to reproduce the behavior:
as described above. I did create a trimmed down version of my use case that can be found here:
https://github.com/franksgit/cap_js_agent_subagent_2_mcp_jwt_issue_demo/tree/main

Expected behavior
The JWT injected in the main A2A agent should be propagated down to the A2A subagent and its MCP server tools, even when using destinations.

Quick explaination why I did this setup. (as said it is a trimmed down version of my wider testing):
I wanted to have PoC capabilities where I deploy from a single CAP project a multi agent setup. The split between subagent and the actions implemented in separate service is needed to be compliant with the API policy of SAP to actually expose calls that happen to the S/4 backend via the MCP gateway. In my demo repo linked above, I am simulating the MCP gateway by having a separate MCP enabled service. In reality it would be a service that exposes the API as rest actions that are then consumed/exposed in the MCP gateway. As the URL of the MCP sever from the MCP gateway is different than the URLs of the CAP service, I need MCP destination in between.

[ ] is it a regression issue?

Screenshots
If applicable, add screenshots to help explain your problem.

Customer Info
Company: xyz.

[github-actions]

👋 Hello @franksgit, thank you for submitting this issue. Our team is reviewing your report and will follow up with you as soon as possible.

[Akatuoro]

Hi @franksgit , thanks for the trimmed down repo, was able to reproduce it easily thanks to that.
The auth context with the token gets dropped in the local subagent, will look into a fix.

[Akatuoro]

@franksgit , could you check whether the changes in #124 fix your use case?
I've tested the fix with your trimmed down repository, but still get a 401 on the mcp endpoint because of the proof-of-posession validation.

[franksgit]

Hi @Akatuoro I can confirm that it still does NOT work with your adjusted coding. I had in the meantime also tried a destination with OAuth2JWTBearer doing a pseudo token exchange to the same ias api - just to be sure that it is not an issue with the destination NoAuthentication and forwardAuthToken =true. In my larger example that is properly bound to aicore and IAS I had run a couple of test with DEBUG=agent, mcp and then asked claude to check on the cf logs failures. He concluded this - not sure if that helps and is even true :-)

"Confirmed — same result for both tools now: both McpT01 (bpread) and McpT02 (bpcreate) still return 401, and the actual outbound request headers to /mcp/bpcreate are still just content-type, accept, accept-language, sec-fetch-mode, user-agent, accept-encoding — no authorization header at all, same as before. So the destination change fixed tool building (tools: 2 now, both resolve), but the actual JWT-forwarding is still completely broken. I traced it to the actual root cause.

Root cause, in @cap-js/agents/srv/handlers/mcp-tools.js:21:

const jwt = retrieveJwt(cds.context?.http?.req ?? cds.context)
retrieveJwt() (from @sap-cloud-sdk/connectivity) expects a Node IncomingMessage-like object and reads req.headers.authorization. The intent of cds.context?.http?.req ?? cds.context is: "use the real request if available, otherwise fall back to something." But the fallback is wrong — cds.context itself has no .headers property, so when cds.context.http.req isn't available, retrieveJwt(cds.context) silently finds no auth header, logs a quiet internal warning ("Authorization header not set"), and returns undefined. No exception is thrown (which is why we don't see a "Could not resolve destination" error this time), so getDestination({ destinationName, jwt: undefined }) proceeds normally, buildHeadersForDestination has nothing to forward, and the outbound call goes out with zero Authorization header — exactly what we observe.

The real question this raises: why is cds.context.http.req unavailable at the point this code runs? That happens deep inside the deep-agent's async tool-execution loop (LangChain middleware, wrapModelCall/tool invocation), which very plausibly runs outside the original request's CDS context propagation (a new async tick, or a reconstructed cds.context that only carries .user, not the raw .http.req). That's consistent with everything we've seen: cds.context.user info is fine throughout (task records show createdBy: 'frank.reichenbach@capgemini.com' correctly), but the raw HTTP request object needed specifically for JWT-forwarding purposes isn't propagated into this code path.

So, bottom line: this is the actual bug behind your original "JWT not flowing to the sub-agent/MCP server" report, and it's still present in the fix/local-subagent-headers branch you're testing — it's not fixed. The destination-config changes we made were real, necessary fixes for a separate problem (destination resolution), but they were masking the fact that the underlying JWT retrieval in mcp-tools.js never actually succeeds.

Suggested next step: patch resolveDestination() in mcp-tools.js to reliably get the original bearer token — e.g. have the deep-agent/tool-invocation code explicitly capture req.headers.authorization at request-entry time (where cds.context.http.req is still valid) and thread that raw token string through to mcp-tools.js, rather than relying on cds.context.http.req still being reachable deep inside the agent's async tool-call flow. "