Foundry Hosted Agent from_agent_framework removes Authorization Header disabling OBO possibilities

[ashishmundra4001]

• Package Name: azure-ai-agentserver-agentframework / azure-ai-agentserver-core
• Package Version: latest
• Operating System: Linux/Windows
• Python Version: 3.12

Describe the bug
We are hosting an Agent in Foundry using the Hosted Agent model. The implementation follows the sample at:
[[foundry-samples/samples/python/hosted-agents/agent-framework/agent-with-foundry-tools/main.py](https://github.com/microsoft-foundry/foundry-samples/blob/main/samples/python/hosted-agents/agent-framework/agent-with-foundry-tools/main.py)](https://github.com/microsoft-foundry/foundry-samples/blob/main/samples/python/hosted-agents/agent-framework/agent-with-foundry-tools/main.py), which relies on the HostingAdapter from_agent_framework.

Currently, I’ve observed that metadata sent via the /responses API is surfaced in AgentContext.agent._request_headers. However, this does not include the OAuth token provided in the Authorization header.

This omission is problematic because:

Our Agent needs to call downstream APIs that are OAuth-protected and require user context.
The ideal flow is to obtain an OBO (On-Behalf-Of) token from the original incoming token.
Without access to the Authorization header, OBO cannot be performed, which makes Agents unsuitable for production scenarios requiring user-context delegation.
A possible workaround is to ask callers to include the OAuth token in the /responses metadata field. However, this is non-standard and insecure, since callers could spoof arbitrary tokens.

To Reproduce
Steps to reproduce the behavior:
You can take this codebase - https://github.com/microsoft-foundry/foundry-samples/blob/main/samples/python/hosted-agents/agent-framework/agent-with-foundry-tools/main.py

And this middleware codebase where Authorization header is not injected - https://github.com/microsoft/agent-framework/blob/fcdaaff9cd32a410c51fb0bfa0080d277cbcab81/python/samples/02-agents/middleware/agent_and_run_level_middleware.py

Expected behavior
The Agent Framework Hosting Adapter should be updated to forward the Authorization header token into the Agent middleware. This would enable Agents to:

• Retrieve OBO tokens from the original incoming token.
• Use those OBO tokens to securely call downstream APIs and MCP servers.

Suggested fix (in the Azure SDK repo)
AgentRunContext (or runs_endpoint) should capture the Authorization header from the incoming HTTP request.
AgentFrameworkCBAgent.agent_run() should forward it to self.agent.run(message, client_kwargs={"authorization": token}) so it lands in AgentContext.

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

Additional context
Initially I raised this as bug for Agent Framework Team, but they mentioned that its a bug in the package in this github. This is the comment that they have put in - microsoft/agent-framework#4774 (comment)

[mitokic]

FYI @lusu-msft @lmazuel @lirenhe @JC-386

This seems like a major production blocker. Since most MCP tools from Foundry like Work IQ rely on OAuth to get user info from the agent session. If OBO is broken then it looks like we cannot use OAuth in MCP tools once the hosted agent is deployed in a container in Foundry.

This is a major production blocker for me. Please take a look!

https://learn.microsoft.com/en-us/microsoft-agent-365/tooling-servers-overview

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @JC-386 @lusu-msft.

[ashishmundra4001]

Any updates on this? Thanks.

[ashishmundra4001]

@lmazuel @mitokic - I thought of doing a workaround, but landed up in another problem/query - Raised this - microsoft/agent-framework#4986 - Wanted to know your views there too on how do you see it.

[MRvra-MSFT]

Hi @JC-386 @lusu-msft @ganeshyb cc: @lmazuel following our internal discussion, could you please review and respond to this issue directly, Thanks much!

[ashishmundra4001]

Along with Authorization, we should allow some more headers. E.g. you can have a convention like any header which is Authorization or begins with X-AUTH- will not be stripped. I will mention 2 more use cases that why X-AUTH-* is required.

1. The downstream MCP Tool which Agent will invoke requires a special token, which end user can only send to Agent. If you strip it, Agent will not be able to send to MCP Tool.
2. Lets say we front Agent behind Azure APIM, just OAuth check is not enough at Microsoft Foundry Level, as some other internal malicious developer can copy the same azure apim proxy and can call the Agent. To take care of this, Agent may need a x-api-key which the Azure APIM proxy must pass. So, if another developer copies proxy, they won't know this x-api-key so their proxy will not work. This x-api-key can be sent to Agent using X-AUTH-API-Key kind of header.

So, stripping all Header in Hosting Adapter library is not good.

What must instead be done is that all headers must be sent to Agent as AgentContext (and not main request as such). This way Agent cannot see these headers and mis-use it, but when using Agent, we can setup mcp tools or do some extra validations of requests before Agent can be invoked.

[RaviPidaparthi]

I would not recommend metadata as it gets persisted by default
There are 2 options

1. All x-client-* headers are treated as pass though by the platform. So you use this to transport what you want.
2. On responses API when creating a response, use structured_inputs key value pairs to pass along any named input value of any type (string, int, object, array) and you use this in your container code. Structured inputs are not persisted by default. This is how we solved it for prompt agents. Read more about that at https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/structured-inputs?pivots=rest

Again this is not the perfect solution as developers are forced to implement OBO on their own. My comment was only about avoiding use of metadata for this purpose.