User Token Passthrough for Secure Tool Calls

[VerdantForge]

Technical Feedback

I’m really enjoying the agent creation experience in Azure AI Foundry — the formalism is simple and intuitive.
That said, the current authentication model for OpenAPI-based tools feels too loose. At the moment, it’s up to the agent to behave responsibly: not leaking data to users who shouldn’t see it, and not performing actions they shouldn’t be able to trigger.

This puts a lot of trust on the agent logic rather than enforcing security at the infrastructure level.
To strengthen this, it would be extremely useful to pass through the user’s bearer token into tool calls at the thread level, so that:

• All actions are executed under the user’s own identity.
• Tools never have more privileges than the user already has.
• Access control is enforced by the underlying services rather than by the agent’s “good behavior.”

Desired Outcome

Enable bearer token passthrough within a thread.
Ideally, tokens would have an expiration mechanism (or be refreshed appropriately), ensuring that tool authentication remains scoped to the thread and tied to the user’s real permissions.

Current Workaround

Right now, I’m using local function calling from the client side (where the user is already authenticated) instead of routing calls directly through Azure AI Foundry’s orchestration. This works, but it bypasses Foundry’s intended workflow and limits the benefits of the platform.

[leestott]

Hi @VerdantForge thanks for the concise critique of agentic orchestration: security delegation versus infrastructure enforcement. You have really covered well the tension between intuitive agent design and the need for robust, identity-scoped execution.

I just want to validate my reading of this:

Core Concern: Over-reliance on Agent Logic for Security

• Current Model: Agents are trusted to enforce access control manually, which introduces risk — especially in multi-user or enterprise contexts.
• Implication: Without infrastructure-level enforcement, any misstep in agent logic could lead to privilege escalation or data leakage.

Proposed Enhancement: Bearer Token Passthrough at Thread Level

Identity-bound execution | Every tool call reflects the actual user’s identity, not a generic agent context.
Least privilege enforcement | Tools inherit only the permissions granted to the user, preventing overreach.
Infrastructure-level access control | Services like Azure APIs can validate tokens natively, removing the burden from agent logic.
Auditability | Actions can be traced back to real users, improving observability and compliance.

Token Lifecycle Considerations

• Expiration: Tokens should expire naturally or be scoped to session/thread duration.
• Refresh Strategy: Ideally integrated with Azure AD or Entra ID, allowing silent refresh or re-authentication prompts.
• Revocation: If a user’s permissions change mid-session, the token should reflect that immediately.

Current Workaround: Local Function Invocation

• Pros: Secure, identity-bound execution.
• Cons: Bypasses Foundry’s orchestration layer, losing benefits like centralized logging, agent chaining, and tool abstraction.

Suggested Implementation Path

1. Thread Context Injection: Allow bearer tokens to be attached to thread metadata.
2. Tool Invocation API Update: Modify tool call schema to include optional auth header passthrough.
3. SDK Support: Ensure CLI and SDKs support token propagation from client to orchestration layer.
4. Policy Enforcement: Add optional flags in agent config to require identity-bound execution for sensitive tools.

[VerdantForge]

Yeah that's exactly what I had in mind!