Microsoft Agent 365 Goes GA and Starts Auto-Discovering the MCP Servers Nobody Registered

Microsoft's pitch for Agent 365, which went generally available on May 1, 2026, is not "here is a better way to manage your agents." It is something more unsettling: you already have agents you never approved, running tools you never registered, touching data you never scoped — and your security team had no way to see them until now. The centerpiece of the GA announcement is Shadow AI Discovery, a Defender-plus-Intune sweep that surfaces unmanaged local agents across more than 20 agent types, including local and remote MCP servers.

That framing is worth sitting with. The enterprise governance product of 2026 does not start from a registry you fill in. It starts from the assumption that the registry is already wrong — that somewhere on a developer laptop or a forgotten VM, an MCP server is exposing production-adjacent tools to an agent nobody onboarded. Microsoft is selling discovery first, governance second, because its customers kept finding the tools after the incident, not before.

This post is not a recap of the announcement. It is the checklist the announcement implies: the five governance controls Agent 365 ships, what each one catches, and — the part that matters if your agents run on infrastructure Microsoft cannot see — what a self-hosted platform has to build for itself. Defender cannot discover an MCP server running on your own fleet. That gap is now yours to close.

The five controls, and what each one implies you must build​

Here is the whole post in one table. Agent 365's GA and preview capabilities decompose into five controls; each row names the self-hosted equivalent a PaaS pitching agents as first-class operators needs, in build-priority order.

The rest of this post unpacks why each row exists — the threat data behind rows 1–2, the identity argument behind row 3, the logging argument behind row 4 — and ends with the Monday-morning build sequence.

Why MCP servers top the discovery list​

Microsoft did not pick MCP servers as a discovery target by accident. The Model Context Protocol went from an Anthropic developer convenience in late 2024 to the default tool-integration layer for agents in about eighteen months, and the security posture of the ecosystem never caught up. The numbers behind that claim are unusually well documented for a protocol this young:

• Academic research from Queen's University analyzed 1,899 open-source MCP servers and found 7.2% contain general vulnerabilities and 5.5% exhibit MCP-specific tool poisoning — malicious instructions hidden in tool descriptions the agent reads but the user never sees.
• More than 30 CVEs were filed against MCP components in just the first 60 days of 2026, and the community-run Vulnerable MCP Project now tracks 50 CVEs, 13 of them critical.
• An Astrix Security survey of roughly 20,000 MCP servers found only 8.5% use OAuth; 53% still rely on static API keys. Trend Micro found 492 MCP servers exposed directly on the internet with zero authentication.
• A March 2026 ecosystem scan of 5,618 MCP servers judged only 2.5% verified safe, with 90.2% needing security review. In a separate survey of 2,614 implementations, 82% had file operations vulnerable to path traversal and 67% had code-injection risks.

Then came the institutional verdicts. The NSA's Cybersecurity Information Sheet on MCP security design (PP-26-1834, May 2026, produced with Carnegie Mellon's Software Engineering Institute) catalogs the failure modes as structural, not hypothetical: poor approval workflows where a trusted server's capabilities change without user consent, inconsistent implementations — and, the line that should echo through every platform roadmap, missing audit logs that make incident response impractical.

The NSA also names the pattern reversal that makes MCP harder to trace than the APIs it replaces: servers can query or execute actions for connected clients, creating attack paths that run opposite to the direction most monitoring assumes.

And the incidents keep arriving through the exact gap discovery is meant to close. In July 2026, the Ruflo MCP bridge flaw let unauthenticated attackers run commands and poison AI memory through a server most orgs would never have inventoried. The maintainer patched within 24 hours of disclosure — but only teams that already knew the server existed could know they were exposed.

Microsoft's own guidance now states the operating principle plainly: MCP controls start with inventory, change review, and DLP — in that order. You cannot review or filter what you have not found. That is rows 1 and 2 of the table, and it is why discovery leads the product instead of trailing it.

Identity per agent, not per human​

The registry's less obvious half is identity. Every agent governed by Agent 365 gets its own Entra identity — sign-in logs, Conditional Access policies, risk-based shutdown — which Gartner's Alastair Woolcock summarized as giving agents "employee IDs, not just software licenses." The point is attribution under blast radius: when a compromised agent needs to die, IT kills the agent's identity without touching the human who launched it, and every action the agent took is traceable to that identity afterward.

The scale of the unattributed-identity problem is what makes this a platform requirement rather than enterprise polish. Gartner's survey data, via IBM's human–machine identity research, finds organizations deploy an average of 45 cybersecurity tools yet effectively manage only 44% of machine identities — meaning roughly half the non-human identities in enterprise ecosystems are invisible and unmanaged. Every MCP server with a shared static API key (recall: 53% of them) is one of those unmanaged identities, except it can execute tools.

For a self-hosted PaaS with an MCP-calling deploy API, row 3 translates directly: one credential principal per agent, scoped to the minimum tools it needs, with per-agent revocation that does not require rotating a shared secret every other agent also holds. If your agents today share one API token — one identity for the whole fleet — you have the exact condition Agent 365's identity pillar exists to eliminate, and no vendor product will fix it inside your perimeter.

Row 5 is the same lesson at fleet scope. The registry-sync preview pulls agents running in AWS Bedrock and Google's Gemini Enterprise Agent Platform into one inventory with basic lifecycle governance, because, as Microsoft's Charlie Weston told VentureBeat, "if we're going to be a single control plane, we have to meet customers where they are, and many of them are multi-cloud." Your agents will not all run on your PaaS either — some on developer laptops, some in another cloud, some on a customer's cluster. A registry that only knows about agents inside one console repeats the pre-discovery mistake at a smaller scale. Export the inventory and the audit feed in a portable shape; assume somebody else's console needs to read them.

Runtime DLP and the audit trail you cannot skip​

Rows 1–3 find and name the agents. Row 4 governs what they do while running. Purview's contribution to Agent 365 is runtime data loss prevention for agent prompts — evaluating prompts and responses against DLP and content policies in real time, blocking sensitive data before it reaches a model — plus Purview Audit logging of all agent activity for full traceability. A Purview SDK extends the same prompt-and-response evaluation to agents built outside Microsoft's own platforms, cutting integration from weeks to days.

Two details matter for the self-hosted equivalent. First, the enforcement point is pre-execution: the policy decision happens on the tool input before the model or the tool ever sees it, not as a forensic review afterward. An MCP-calling deploy API needs the same choke point — every tool call evaluated against policy (which agent, which tools, which data classes) before dispatch, with denials logged as first-class events, not silent drops. Second, the audit requirement is completeness, and this is where the NSA sheet bites: "missing audit logs that make incident response impractical" is listed as a catalogued failure mode of current MCP deployments. If your deploy API logs the deployment but not the agent's tool-call sequence that produced it — the inputs, the server versions, the policy decisions — you cannot reconstruct an incident, which means you cannot scope one either.

The uncomfortable corollary: most self-hosted agent stacks today log less than the minimum Agent 365 treats as table stakes. Application logs record what the app did; almost nobody records the full tool-call transcript with per-call identity and policy outcome. That transcript is the artifact every other row exists to make meaningful — discovery tells you which servers to watch, identity tells you who called, and the audit log tells you what happened. Without it, rows 1–3 are inventory for its own sake.

What to build Monday morning​

If you operate a self-hosted PaaS where agents deploy and operate apps, the Agent 365 GA is a prioritized requirements document written by your largest competitor. Build it in this order — each step makes the next one possible:

1. Registry with teeth. Stand up the inventory of agents and MCP servers allowed to touch your API, and enforce it at authentication time: unregistered caller, no credentials. This is the cheapest row and the prerequisite for all four others.
2. Fleet discovery. Continuously scan your own namespaces and nodes for MCP endpoints that are not in the registry, and alert on drift. You cannot buy Defender-for-your-fleet; a scheduled sweep plus admission-time checks is the honest substitute.
3. Per-agent identity. Issue one scoped credential principal per agent with independent revocation. Retire any shared token that more than one agent holds.
4. Pre-execution policy + append-only tool-call log. Evaluate every tool call against policy before dispatch; log caller identity, tool, inputs, server version, and decision to tamper-evident storage. Size this before you need it — it is the highest-volume row.
5. Portable export. Publish the registry and audit feed in a format another console can consume, so the team running agents across your platform and elsewhere gets one inventory instead of two partial ones.

None of this requires Microsoft's stack. All of it is implied by the fact that Microsoft now ships it by default: the moment the enterprise baseline includes auto-discovered, identity-bound, DLP-filtered, fully audited MCP servers, a platform whose agent story is "bring your own MCP config and a shared API key" is not minimalist — it is missing the controls its customers' auditors will ask about first.

The deeper signal in the Agent 365 GA is a phase change in what "supporting agents" means. In 2024 and 2025, supporting agents meant giving them tools — an MCP server, an API key, a sandbox. In 2026, Microsoft is defining the second half: discovery of the tools nobody registered, identity for the callers nobody onboarded, policy on the prompts nobody reviewed, and logs for the incidents nobody can yet reconstruct. Governance is becoming the price of admission for agents-as-operators, not an enterprise upsell layered on afterward.

That is good news for self-hosted platforms, if they read it that way. Every control in the table is buildable on infrastructure you own, with no license meter running — a registry, a scanner, scoped credentials, a policy hook, an audit log. The enterprises buying Agent 365 at 15 dollars per user per month are not buying exotic technology; they are buying the admission that shadow agent sprawl already happened to them. Build the five rows before your own sprawl needs discovering, and the audit is a report you generate — not a product you buy to find out what you missed.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agents as first-class operators. Star the repo on GitHub or deploy your first app today.