{"id":2751,"date":"2026-07-22T08:00:29","date_gmt":"2026-07-22T15:00:29","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/foundry\/?p=2751"},"modified":"2026-07-21T22:51:16","modified_gmt":"2026-07-22T05:51:16","slug":"building-agents-that-act-on-your-behalf-with-toolboxes-in-foundry","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/foundry\/building-agents-that-act-on-your-behalf-with-toolboxes-in-foundry\/","title":{"rendered":"Building Agents that Act on Your Behalf with Toolboxes in Foundry"},"content":{"rendered":"

How Toolboxes in Foundry simplify user delegation<\/span><\/b><\/p>\n

At some point, many agents move from answering questions to taking action. And when it does, the question becomes: <\/span>whose\u00a0identity is\u00a0it\u00a0acting\u00a0with<\/span><\/b>?\u00a0Imagine\u00a0you\u00a0are building an\u00a0internal\u00a0employee\u00a0agent.\u00a0\u00a0It needs\u00a0to call\u00a0a\u00a0private, Entra-protected\u00a0MCP server for orders, and it also needs to use Microsoft\u2019s managed Work IQ MCP server to reason over the employee\u2019s Microsoft 365 context. In both cases, the agent can\u2019t run as a\u00a0managed identity or service account. It has to act as the\u00a0<\/span>real signed-in user\u00a0<\/span><\/b>\u2014 with that user\u2019s permissions, access boundaries, and data protections. That\u2019s where identity gets hard: exchanging tokens on behalf of the user, keeping each user\u2019s tokens isolated, and handling consent and refreshing.<\/span>\u00a0<\/span>\u00a0<\/span><\/p>\n

Why is this hard to build yourself?<\/span><\/b>\u00a0<\/span><\/h2>\n

Let\u2019s take the example of employee agent. Both tools demand the same thing: user delegation. If you choose to implement the entire user delegation yourself, you probably need to spend weeks before you can start building the business logic for your agents:<\/span>\u00a0<\/span><\/p>\n

    \n
  1. Complex, high-stake token isolation: <\/span><\/b>You must partition token caches correctly by user and tenant. A wrong cache key can silently leak one user\u2019s downstream API access to another user.<\/span><\/li>\n
  2. Consent management overhead: <\/span><\/b>You need to detect consent failures, send users through consent, refresh expired tokens, and handle retries correctly for each API in each agent code you write.<\/span><\/li>\n
  3. Duplicated implementation: <\/span><\/b>Every new tool adds another scope, token exchange, cache entry, consent path, retry path, and header path.\u00a0As you scale with hundreds of tools and thousands of agents, you end up rebuilding the\u00a0same fragile plumbing.<\/span>\u00a0<\/span><\/li>\n<\/ol>\n

    \"Screenshot<\/a><\/b><\/p>\n

    How\u00a0does Toolbox\u00a0solve\u00a0it?<\/span><\/b>\u00a0<\/span><\/h2>\n

    Same scenario, same user delegation \u2014 but the agent carries none of the plumbing above. The core idea:<\/span>\u00a0<\/span><\/p>\n