AI security news · · 7 min read

Microsoft Agent 365 expands MCP tool governance: what local coding agents should learn

Microsoft's September 2026 controls separate tool inventory, administrator approval, and runtime policy. Here is the narrower, practical GrantTap connection.

Editorial illustrationCreated for this story. GrantTap screens below are separate captures made with sample data.

Microsoft's September 30, 2026 Agent 365 update is a useful sign of where agent governance is going. Its Tools management is described as generally available for MCP servers, plugins, skills, and connectors. The same announcement says developers can register custom MCP servers for administrator review in public preview, Agent Management Rules are in public preview, and an Azure API Management integration begins rolling out from September 30. These are Microsoft's stated release statuses, not independent verification that every tenant or agent route already has every control.

The interesting point for a developer running Claude Code or Codex on a personal computer is structural. A tool may be discoverable, approved, actually reachable, invoked, and successful at different times. Treating those states as one green check makes governance hard to trust. GrantTap has a much smaller, personal and local scope than Agent 365. It coordinates supported local coding tools through Project Mesh and host-reported capability coverage. It does not claim a Microsoft tenant inventory, Entra identity governance, or Azure API Management enforcement. We use Microsoft's news as an occasion to ask better questions of our own path.

What Microsoft actually announced

The official Microsoft post describes a central Tools management view where administrators can discover connected tools, inspect metadata and usage, and apply tenant-wide allow or block decisions across several tool classes. It also distinguishes custom MCP registration from approval: a developer can submit a server, while an administrator can inspect its description, publisher, requestor, endpoint, and capabilities before accepting it. The approval path matters because an MCP server name alone does not reveal what network destination or account access the server will use.

Agent Management Rules are a separate public-preview feature for automating lifecycle actions such as blocking agents or rejecting publication requests when conditions match. Microsoft also says the Agent 365 connection to Azure API Management is rolling out, with discovered AI assets and runtime authentication, routing, and controls on traffic that passes through that service. A reasonable reading is that registry visibility, administrative decision, and runtime enforcement are related layers. It would be wrong to compress the announcement into a claim that all tools on all endpoints became universally blockable on September 30.

Editorial illustrationOriginal generated interpretation of an agent-tool review path; no Microsoft product screen is depicted.

Why MCP governance matters to coding work

An MCP server can put repository information, ticketing systems, cloud services, or deployment functions near an agent. A skill can provide instructions or scripts that change how that agent works. A connector may expose data without appearing as a shell command. The risk is not that any one category is inherently bad. The risk is that the person approving work cannot tell which exact capability was present, how it was configured, and whether a later action used it. Agent inventories and review queues answer part of that problem before execution.

For a local developer, identity is more precise than a marketing name. Two MCP configurations with the same display label can launch different binaries or carry different endpoints. A skill bundle can change on disk after approval. A robust review therefore needs a digest, version or exact configuration when available, plus the host and Project where it applies. The GrantTap capability status guide explains why discovered, requested, approved, initialized, and observed usage must remain separate. Those states are useful even to someone who never operates a corporate tenant.

What GrantTap does on the local path

GrantTap's Project Governance lets a person set allow, ask, or deny for capability kinds such as skills, MCP servers, shell and scripts, file writes, deployment, and network actions. Named rules can narrow a kind to a specific capability. The Project policy is written on the phone, delivered encrypted, applied on each Project computer through the separately distributed GrantTap Engine, and acknowledged with the revision held by that computer. The app reports coverage as enforced, observed only, unsupported, or unknown. A global provider deny wins over a Project allow.

That is a host-and-Project control for supported local integrations. Claude Code and Codex are the primary paths. Cursor has narrower coverage, and Grok Build remains observable where its local runtime permits it. If a provider-native route bypasses a GrantTap hook, the app cannot truthfully show it as blocked by GrantTap. Likewise, a saved policy on the phone is intent until the target host reports application. The approval-boundary article describes how to test a harmless denial at the computer instead of trusting a card color.

Inventory is not execution evidence

Microsoft's announcement talks about tool usage in its management experience. GrantTap has its own evidence boundary. A tool being configured on a computer is an availability signal. A policy allowing it is a decision. Initialization tells you that a particular host made it usable. A provider transcript or attributed hook event can report a call. Even a reported successful call is not automatically proof that the intended file changed or a deployment completed. The GrantTap runtime explicitly leaves unverified filesystem changes unknown instead of manufacturing them from edit-tool requests.

This distinction is important for SEO headlines too. Saying a control center “knows every tool an agent used” would exceed the current observation paths. A more honest claim is that GrantTap reports what its supported provider adapters and local host can actually observe, with gaps exposed. The real screenshot in this article is a deterministic GrantTap Project Governance capture. It shows the layout and status vocabulary; it does not demonstrate that a live Microsoft tenant rule or a production local denial fired. The two conceptual images likewise explain an idea rather than showing telemetry.

Editorial illustrationOriginal generated interpretation of a tool inventory; the objects are conceptual, not measured tenant assets.

A practical review for one Project

Choose a disposable repository and list the MCP servers, skills, and shell actions the agent may need. Record the exact host and provider, then choose a Project rule for one harmless capability. Confirm that the target computer acknowledges the new policy revision and reports enforcement coverage. Ask the agent to try both an allowed and a denied operation. Inspect the provider transcript and the host-side denial record, including the rule and capability fingerprint. If the denied action still happens, stop relying on that route for sensitive work until its coverage is understood.

Next repeat after a provider update or a configuration change. A newly configured MCP server may share a familiar label but have a different command or endpoint. Check that an old approval did not silently become authority for a different capability. If one computer is asleep, wait for its acknowledgment rather than assuming all Project machines applied the edit. The relay can retain an encrypted policy packet, but receipt and enforcement remain host facts. This is the difference between a policy distributed to machines and a policy actually in force.

How to compare different governance systems fairly

Agent 365 is positioned for organization-wide agent inventory and Microsoft tenant controls. AgentCore policies govern calls passing through an AWS gateway. GrantTap coordinates supported local coding-agent work and reports host coverage in a personal Project. The common questions are who owns a rule, which identity it covers, where it is enforced, how updates reach each target, and what evidence exists afterward. The answers differ because the systems sit on different execution paths. A feature table that says simply “supports governance” loses the essential boundary.

The local lesson from Microsoft's release is still valuable: make tools first-class reviewable objects, keep publication separate from actual use, and connect administrative intent to runtime control. GrantTap applies this idea where a developer's coding work lives, while leaving unknown outcomes and unsupported paths visible. Readers who want to examine that local model can continue with Project Mesh, capability status, and the usage evidence guide.

Real GrantTap Project Governance interface, captured with deterministic sample policy and coverage. It is not a Microsoft Agent 365 screen or proof of a live block.
GrantTap screen · sample dataReal GrantTap Project Governance interface, captured with deterministic sample policy and coverage. It is not a Microsoft Agent 365 screen or proof of a live block.

Sources

Next storyAWS AgentCore temporal policies make agent history part of authorization →