Agent 365 can now block the MCP tools an agent calls. Policy becomes real at the gateway

A list of your agents is not a control. A control is being able to stop one agent from calling one tool on a Wednesday afternoon, without redeploying the agent and without asking the team that built it. Most agent governance programs today have the list.

On October 9, Microsoft put the two halves together. A public preview connects Agent 365, its agent governance product, with Azure API Management for traffic to MCP servers and tools. Microsoft describes the split plainly: “Agent 365 defines governance intent, maintains inventory, and manages access decisions,” while “Azure API Management enforces those decisions inline for traffic to MCP servers and tools.”

That sentence describes an architecture worth copying, whatever vendor you use.

Two planes, two owners

The team that decides what agents may do is rarely the team that runs them. Identity and security teams set access policy; platform teams run gateways; product teams build agents on whatever framework suits them. Until now, agent governance products mostly lived on the first side: inventories, risk scores, policies written down. Enforcement depended on each agent’s own configuration.

Here the decision and the enforcement live in different systems with different owners, joined by an integration. Agents already configured to reach tools through the gateway keep their connection, the MCP servers stay in the customer’s Azure subscriptions, and discovery needs a one-time tenant-level consent. An agent does not have to be rebuilt on Microsoft’s runtime to be governed, as long as its tool traffic passes through API Management.

Who decides, who enforces

Agent 365

• MCP inventory
• Governance intent
• Access decisions

Owned by governance and security

Azure API Management

• Inline enforcement on every tool call

Owned by the platform team

Defender and Purview (AI Gateway tier)

• Evaluate tool requests
• Evaluate tool results

MCP servers and tools

• In the customer's Azure subscriptions

Read the tier before the headline

What you can enforce depends on which API Management tier you run. Microsoft says the v2 tiers support “centralized MCP inventory and server-level blocking and unblocking through Agent 365.” The AI Gateway tier adds “individual-tool blocking, tool activity observability, and tool threat protection,” with individual-tool blocking itself labeled preview.

The difference is larger than it looks. Blocking a whole server is a circuit breaker: useful in an incident, blunt in daily operations. Least privilege needs the finer control, where an agent keeps its read tools on a CRM server and loses the one that updates records. That control sits in the AI Gateway tier.

Threat protection works in two directions. Defender and Purview evaluate tool requests and results for malicious content, prompt injection and sensitive information. With blocking configured, “pre-invocation evaluation can prevent a disallowed call from executing,” and “post-invocation evaluation can withhold unsafe results before they reach the agent.” The second direction deserves attention: a tool’s response is where injected instructions enter an agent, and few teams inspect it today.

The announcement does not cover licensing, pricing, regions or numeric limits. Check the documentation before planning around it, and remember that all of it is preview.

What the gateway cannot see

Inline enforcement governs the traffic that passes inline. An agent holding its own credential to an MCP server, calling a local tool, or browsing the web is outside this control, and the dashboard will not say so. As we argued when MCP connectivity outran MCP governance, the protocol connects; it does not govern.

The design work is therefore to make the gateway the only route:

• Credentials that only work through the gateway. If a tool accepts a token the agent could use directly, the gateway is optional.
• Egress rules for agent workloads, so a direct path to a tool server fails at the network.
• Reconciliation of inventory against traffic. Agents that appear in Agent 365 but never send traffic through API Management are either idle or bypassing it. Both deserve a question.

This is the pattern we described for the AI gateway as a policy enforcement point, now applied to tools instead of models. It also keeps two of the six authorities that govern an agent apart: the people who grant tool access are not the people who can switch the enforcement off.

Three questions are worth asking before a pilot. Which of our agents’ tools can be blocked individually today, and on which tier? What traffic reaches tools without passing the gateway? And when security decides to cut an agent off from a tool, how many minutes does it take, and who has to agree?