Python: [Bug]: Cleanup Raw Payload before reaching Agents

[ashishmundra4001]

Description

My Agent is a Foundry Hosted Agent using Hosting Adapter Library:
from azure.ai.agentserver.agentframework import from_agent_framework
from_agent_framework(agent).run().

Codebase similar to https://github.com/microsoft-foundry/foundry-samples/blob/main/samples/python/hosted-agents/agent-framework/agent-with-foundry-tools/main.py

This section is background and not a issue, I will describe issue shortly:
This Hosting Adapter library (from_agent_framework) strips Authorization Header, so when we invoke Agents, Authorization Header never reaches Agent.

So, imagine a common scenario where user login on a UI and gets a Entra JWT Token which represent user, now user calls a API. This API must call Foundry Hosted Agent, so the API gets a OBO Token (on-behalf-of token) which represents original user and identifies the API to Agent and sends this OBO Token in Authorization Header to Agent.

If Agent must call a API which needs to know original user context, the Agent need to get a OBO token to retain original user context and to identify itself to API, but given that from_agent_framework strips this Authorization Header, Agent has no way to get a OBO as initial token is lost.

I have raised this as a defect to the team here - Azure/azure-sdk-for-python#45797

So with that background, coming to the issue or query that I have for Agent Framework.

As from_agent_framework strips Authorization Header, so we now send Authorization Header in /responses metadata attribute (not ideal but still real world scenario where Apps may want to send some sensitive information to the Agent somehow and I think metadata is the only way).

When from_agent_framework gets metadata, it converts it into context.agent._request_headers for Agent Framework and that is available in AgentMiddleware. e.g. in class UserContextAgentMiddleware(AgentMiddleware)

Now, as we are passing something sensitive (continuing to above background, in this particular case original user context in a OBO Token), we want to use this OBO Token in Agent to send to APIs that it calls so that those APIs know original user context. Also, Agent will also need to be identified to that API, so Agent code will need this OBO token obtained from context.agent._request_headers to obtain a new OBO (to retain original user context and to identify itself to API).

This is all fine. But now most likely as I understand it is that this token is in two places a) in context.agent._request_headers and probably from_agent_framework also sending original raw payload (which had metadata) to Agent Framework (I do not know that in which field is it sent or is it not sent at all). Is this token then available to the Agent somehow, because if so, the Agent can do some unwanted calls as its hallucinates, so ideally we do not want Agent to "see" this token. So, there should be some way to strip out selectively metadata from raw payload and from context.agent._request_headers before Agent can "see" it and misuse it.

How can we do this?

Thanks a lot.

Code Sample

Error Messages / Stack Traces

Package Versions

azure-ai-agentserver-agentframework==1.0.0b17 agent-framework==1.0.0rc3

Python Version

3.12

Additional Context

Azure/azure-sdk-for-python#45797

#4774 (comment)

[eavanvalkenburg]

@ashishmundra4001 I have a PR open for built-in support for setting headers on the mcp client dynamically, through a header_provider, would that help (until the MCP server being run by foundry can do the same)? #4849

[ashishmundra4001]

This one is different concern altogether. This is with regards to when a Agent is invoked, whether it calls mcp or not is not concern for this particular request.

I can explain over a call if my description is not clear (if that's an option).

Thanks for replies. The replies help me to assure that an expert like yourself looked at it and may bring it in right forums.

We want to use Foundry Hosted Agents with python Agent Framework soonest possible in a Agentic Mesh scenario, but some basic security flows either are either not implemented or not so straightforward to understand for devs like me.

[ashishmundra4001]

I edited description above to make it more meaningful and also attached a image to explain flow. Hope this clarifies.