Microsoft Foundry Toolboxes centralize authentication for AI agent tool calls, letting agents delegate to a user's identity via OAuth 2.0 rather than each agent implementing token acquisition, isolation, consent, and refresh independently. The piece walks through configuring connections, building reusable toolboxes, and consuming them from agents, along with supported authentication models (agentic-identity, project-managed-identity, oauth2, custom-keys, none). It covers security concerns like token isolation between users/tenants, narrow OAuth scopes, approval boundaries for consequential actions, gateway protection, and toolbox versioning, plus common mistakes and a production security checklist for user-delegated AI tools.
Table of contents
IntroductionWhy User Delegation Is Different From Agent AuthenticationWhy Implementing User Delegation Yourself Is DifficultWhat Microsoft Foundry Toolboxes ChangeSupported Authentication ModelsStep 1: Configure the ConnectionStep 2: Build the ToolboxStep 3: Consume the Toolbox From the AgentToken Isolation Is a Security BoundaryConsent Should Be ExplicitAdding Approval at the Tool BoundaryProtecting the Toolbox With a GatewayToolboxes and MCPDesigning Toolboxes for ReuseVersioning the ToolboxCommon MistakesProduction Security ChecklistComparison: Custom Delegation vs Foundry ToolboxesFrequently Asked QuestionsConclusionQuestions this post answers
What is the difference between agent identity and user delegation in an AI agent tool call?
Agent identity means the downstream tool sees the application or agent's own credentials, useful for service-to-service operations where the app should have its own permissions. User delegation means the tool acts using the signed-in user's authorization context, so access follows that user's existing permissions rather than the agent's. The same agent can use either identity depending on the caller. Developers weighing identity models for agent tool access can dig deeper into these patterns on daily.dev.
What authentication types does Microsoft Foundry support for toolbox connections?
Foundry toolbox connections support five authentication types: agentic-identity (agent's own identity, for service-to-service operations), project-managed-identity (application-owned access), oauth2 (end-user delegated access), custom-keys (stored API key or header, for key-based services), and none (anonymous, for public tools). Choosing the right one should match the security boundary needed rather than defaulting to delegated access. Teams designing secure tool integrations can track authentication patterns like these on daily.dev.
Why is token cache partitioning a security risk in multi-user AI agent systems?
Incorrect token-cache partitioning can cause one user's downstream access token to be exposed to another user if the cache key does not properly isolate callers. Microsoft identifies this as a serious risk requiring caller context to be part of the isolation boundary, since a bad implementation could let User B's request resolve User A's cached token. Anyone hardening multi-tenant AI agent auth can keep up with security patterns like this via daily.dev.