Azure / Azure/azure-sdk-for-python

Foundry Hosted Agent from_agent_framework removes Authorization Header disabling OBO possibilities

Offen
#45,797 14 Kommentare 4 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
customer-reported Hosted Agents needs-team-attention question Service Attention
Vorherrschende Sprache
Python
Sterne
5.6k
Forks
3.4k
Ø Merge
2 T. 2 Std.
Gemergte PRs (30 T.)
213

Beschreibung

- **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)](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 - https://github.com/microsoft/agent-framework/issues/4774#issuecomment-4089425575

Beitragsleitfaden

Beitragsleitfaden öffnen

Rechercherichtung

Beginne mit dem hosted-agent sample main.py und dem Agent Framework middleware sample, und untersuche anschließend AgentRunContext oder runs_endpoint sowie AgentFrameworkCBAgent.agent_run(). Reproduziere den fehlenden Authorization-Header über die /responses API; abgeschlossen ist die Aufgabe, wenn der ursprüngliche Header das AgentContext middleware für die sichere OBO-Nutzung erreicht, ohne auf vom Aufrufer bereitgestellte Metadaten angewiesen zu sein.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
python
Bereich
authentication, backend-api-design
Issue-Typ
Bug
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Ruhig
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
48/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.