Microsoft Foundry Moved Agent Tool Permissions Into a Request Parameter, and the Denylist Fails Open

Five Claude capabilities went live on Azure-hosted Foundry deployments on August 17. The one sentence worth reading twice is in the operational checklist at the bottom, and it describes a permission control that does not fail closed.

Near the end of Microsoft's announcement of five new Claude capabilities in Foundry, past the code samples and the enterprise use cases, there is a security checklist. One line reads: "Verify denylists in CI, because unknown tool names warn rather than error."

Sit with that. It is a vendor telling you, in its own launch post, that the mechanism you would reach for first to stop an agent from deleting things does not stop anything if the name you typed no longer matches a tool on the server. It logs a warning. Then it runs.

That single line is a better description of where agent security actually lives right now than most of the papers published this month.

What actually shipped

On August 17, Microsoft made five Claude capabilities available on Foundry deployments hosted on Azure: structured outputs, web search, web fetch, an MCP connector, and tool search. The post is written by Haoran Cheng, a product manager on the Foundry team working on the Claude API.

The framing in the post is procurement-shaped and honest about it. Claude models went generally available in Foundry in June 2026 with Entra ID auth and Azure Marketplace billing, which solved buying and governing. The agentic feature set stayed on Anthropic-hosted deployments, so a team with a commitment that prompts and completions remain in Azure had to either break that commitment or rebuild search, fetch, MCP plumbing, and tool routing themselves. That fork is gone. For Azure-hosted deployments, Microsoft states that prompts and completions stay within Azure, and only usage metadata and content flagged by Anthropic's safety systems leaves.

So far this reads like a competent platform release, and it is one. The part that changes how you should think about your agent is quieter than the feature list.

The boundary moved into the request body

Look at what an MCP connector call looks like on Foundry. You declare servers in mcp_servers, then declare which of their tools are live with an mcp_toolset entry in tools. Microsoft names three governance patterns directly, which is more than most vendors do.

Denylist. Enable everything, then switch off the destructive operations by name: delete_incident, bulk_close_incidents, modify_sla, each with {"enabled": False}.

Allowlist. Set default_config: {"enabled": False} on the toolset, then enable named tools one at a time. Microsoft calls this the right posture for anything touching identity, endpoints, or money, and says it is how you build an agent that is genuinely read-only.

Deferred. Set default_config: {"defer_loading": True}, which hands the server's tools to tool search instead of loading them into context.

Precedence runs per-tool configs over set-level default_config over system defaults. This is a real permission model with a real merge order. It is also entirely made of JSON in a request body, which means it gets reviewed the way prompts get reviewed, not the way IAM policy gets reviewed. Those are very different review cultures, and one of them has decades of scar tissue.

Now put the checklist line back in. A denylist names delete_incident. The team that owns the ServiceNow MCP server ships a refactor and renames it delete_incident_v2. Your config still names a tool that does not exist. Unknown tool names warn rather than error. The warning goes to a log nobody reads, the new tool was never denied because it was never named, and the agent can now delete incidents.

The allowlist inverts that failure. With default_config: {"enabled": False}, a rename means the new tool is simply absent, because absence is the default and enabling is the exception. The rename breaks your agent's capability instead of breaking your agent's containment. That is the correct direction for something to break.

Tool search makes the allowlist load-bearing

The other capability in this release changes what "the set of tools my agent can reach" even means.

Microsoft puts numbers on the problem. Five ordinary servers, GitHub plus Slack plus Sentry plus Grafana plus Splunk, consume roughly 55,000 tokens in tool definitions before the model does any work at all. Separately, Claude's ability to pick the right tool degrades once you pass roughly 30 to 50 available tools, and the post is blunt that it does not degrade gracefully: the agent starts calling search_issues when it meant search_pull_requests, and your evals get noisy in a way that looks like a prompting problem.

Tool search fixes both by inverting the loading model. Claude searches a catalogue and pulls in three to five tools per request, cutting definition tokens by over 85%. There are two variants, a regex one and a BM25 one, and both search tool names, descriptions, argument names, and argument descriptions.

Here is the mental model the post says trips people up, and it is the important one. defer_loading controls what enters the context window, not what you send. Every tool definition still travels in the tools array on every request, because the service needs them to run the search and expand references. At least one tool must stay non-deferred or you get a 400.

Read that alongside the governance patterns and the picture sharpens. With deferred loading on a nine-server, six-hundred-tool setup, the agent's working set is chosen at runtime by a search over descriptions you may not have written. The only thing that bounds what can enter that working set is the enable state you configured. If that bound is a denylist, it is a list of names that has to keep matching a server you do not control.

Put this into practice

None of this requires a migration. Start where the exposure is worst.

Convert one toolset to allowlist form today. Pick the server that touches identity, endpoints, or funds. Set default_config: {"enabled": False} and enumerate what the agent actually needs. It will be a shorter list than you expect.

Write the CI check Microsoft told you to write. One test: call the MCP server, list the tools it currently exposes, diff against the set your config expects. Fail the build on any tool present on the server that your config does not mention. That converts a silent warning into a red pipeline, which is the entire point.

Turn on citations for web fetch. They are on by default for web search and off by default for fetch. For anything resembling a risk assessment or a regulatory summary, that default is backwards. Set citations: {"enabled": True}.

Treat allowed_domains as a security control, because Microsoft says it is one. The post names it explicitly as a control against prompt injection on web fetch. Note that allowed_domains and blocked_domains are mutually exclusive and sending both returns a 400, and entries are bare domains with an optional path, no scheme.

Log server_name off every mcp_tool_use block. The response blocks carry the source server, so per-server audit logging is a few lines. Do it before you need it, not after.

Cap the spend surface. max_uses on search and fetch, max_content_tokens on fetch. Microsoft's own sizing: a 10 kB page is about 2,500 tokens, a 100 kB docs page about 25,000, a 500 kB research PDF about 125,000. Four of the last one eats most of a turn.

Keep protected data out of schemas. Structured outputs are ZDR-processed, but schemas are cached for 24 hours. No PHI in field names or descriptions.

What this does not solve

The MCP connector is in beta on Foundry, and you opt in with betas=["mcp-client-2025-11-20"]. Beta means the shape of the governance model above can still move.

The MCP connector's server exchange is not covered by zero data retention. Structured outputs are. If your compliance posture rests on ZDR, those two facts belong in the same review, and the post says so.

allowed_domains constrains where a fetch goes. It does not constrain what an allowed domain returns. A trusted vendor's status page that has been tampered with is still a trusted domain, and the injection arrives inside the retrieved text.

Several APIs are absent on Foundry: Message Batches, Admin, Models, Compliance, Claude Managed Agents, server-side fallback, and the Advisor tool. If your architecture assumes any of them, plan around it now. Foundry also does not surface Anthropic's rate-limit headers, so back off exponentially and expect less signal than you are used to.

The cost feedback loop is slow. Web search bills at $10 per 1,000 searches, fetch and tool search add no per-call charge, and it all meters hourly through Azure Marketplace as Claude Consumption Units, invoiced monthly in arrears. An agent looping on search will be a line item you read weeks after the behavior.

And the obvious one: this is a vendor's launch post, complete with a webinar link. The failure modes I have pulled out here are documented because Microsoft chose to document them, which is to its credit. That does not mean the list is complete.

The part to take with you

The five capabilities in this release are the ordinary kind of good. The thing worth changing your habits over is that your agent's blast radius is now expressed as parameters in a request, merged by a precedence rule, against a server whose tool names can change without telling you.

Go read your own agent's tool configuration this week. If any part of it is a list of things you have forbidden by name, you are trusting a string match against a system you do not version. Flip it. Let the default be no, and let the exceptions be the thing you have to defend in review.

Sources: Microsoft Foundry Blog, "From single call to agents: five new Claude capabilities now available in Microsoft Foundry" (August 17, 2026); Claude Platform Docs, MCP connector; Claude Platform Docs, Tool search tool; Claude Platform Docs, Claude in Microsoft Foundry.