Do you know which of your AI agents your platform vendors can already see? Most organizations building agent fleets in 2026 are focused on what those agents do — not on whether someone else has already cataloged them. The scanner layer is where that question gets answered first.

Why Discovery Is the New Governance Battleground

Agent sprawl was the predicted problem. It’s now the present one. By the time most enterprises formalized an AI governance framework, they already had agents deployed across Salesforce Agentforce, Azure Foundry, AWS Bedrock, custom Kubernetes workloads, and three departmental experiments nobody told the architecture team about.

The canonical response from both MuleSoft and Microsoft is a registry: a centralized catalog that discovers what’s running before you can govern it. I traced the full governance stack — identity, policy, and platform strategy — in the Agent Control Plane War post. This post goes one layer below that: the scanner and sync mechanism that populates the registry in the first place.

What nobody is discussing clearly enough is that MuleSoft and Microsoft have built asymmetric discovery layers. Each has the technical capability to catalog the other’s agents. Only one of them actually does.

How MuleSoft’s Agent Scanner Works

The agent scanner in Anypoint Exchange is a scheduled workflow — not an agent, not an event-driven integration — that runs via deterministic APIs and SDKs to call external cloud platforms, retrieve agent metadata, and register agents in the Exchange Agent Registry. The mechanism is intentionally boring. No LLM reasoning, no semantic scraping. Platform APIs, cron schedule, reliable import.

Six platforms are covered in the current GA release:

Amazon Bedrock and Amazon Bedrock AgentCore — both covered, with separate connectors for the foundational Bedrock service and AgentCore’s higher-level agent runtime.

Google Vertex AI — full metadata retrieval through the Vertex AI Reasoning Engines API.

Microsoft Azure Copilot and Microsoft Foundry — yes, both. The scanner explicitly targets Microsoft’s two agent platforms. Scanners for Microsoft Copilot Studio went GA in January 2026.

GoDaddy ANS — agents verified as safe and secure through GoDaddy’s Agent Name Service, the namespace layer for public agent identity.

Operational constraints matter here. The scanner runs at most once daily, retrieves up to 1,200 services per runtime, and has a 6-hour cap. Change detection is built into the import pipeline — new agents are added, missing agents are flagged, changed metadata is overwritten from the source of truth.

Every agent imported through the scanner is normalized to Google Cloud’s A2A agent-card specification, giving heterogeneous agents from six different platforms a uniform metadata structure inside Exchange. What lands in the registry is not a raw API dump — it’s a structured agent card capturing the agent’s name, capabilities, status, and owner in a format that other agents and developers can consume through a common interface. The registry stores not just imported agents but also APIs and MCP servers discovered during the same scan, making it multi-asset by design.

The practical implication: if you’re running agents on Azure Foundry, MuleSoft’s scanner can discover and catalog them in your Anypoint Exchange without any participation from Microsoft, and without any configuration on the Azure side beyond providing read-access credentials.

How Microsoft’s Registry Sync Works

Microsoft Agent 365’s equivalent is the Registry Sync feature — a connect-once, sync-on-demand mechanism that discovers external agents and imports them into the Agent 365 registry. It is currently in preview; scheduled sync is documented as coming in a future release.

The supported platforms for registry sync are:

Amazon Bedrock — IAM credentials scoped to bedrock:ListAgents and bedrock:GetAgent permissions.

Google Vertex AI — service account with aiplatform.reasoningEngines.list and .get permissions.

Salesforce Agentforce — OAuth connected app with chatbot_api and sfap_api scopes.

Databricks Genie — service principal access to the Genie API.

Every agent synced through Registry Sync receives a Microsoft Entra Agent ID — a durable directory identity managed through the same Entra framework that governs users, devices, and workloads. This identity is the foundation of everything that follows in the Agent 365 governance model. Conditional access policies accumulate around it. Audit history builds against it. Risk signals surface through it.

The Agent 365 registry model aggregates risk signals from Entra, Defender, and Purview into a per-agent score. The taxonomy covers the obvious entries — shadow agent, no owner, excessive permissions — alongside prompt injection signals from AI Prompt Shield and sensitive data access from Purview DLP. For organizations already running M365 E5 and Entra ID, this is a governance dashboard that builds on existing infrastructure rather than requiring new tooling.

The Asymmetry That Explains Everything

Here is the gap neither vendor’s marketing materials highlight directly.

MuleSoft’s scanner explicitly targets Microsoft Azure Copilot and Microsoft Foundry. Both are in the documented GA release. MuleSoft can catalog Microsoft’s agents in your organization without Microsoft’s participation in the process.

Microsoft’s Registry Sync covers Amazon Bedrock, Google Vertex AI, Salesforce Agentforce, and Databricks Genie. Salesforce Agentforce is on the list. MuleSoft — the integration platform that sits underneath Agentforce and manages the API catalog those agents call — is not. Neither is Anypoint itself.

It gets sharper. When Microsoft launched Agent 365 with its 23-partner ecosystem on May 1, 2026, the partner list included Adobe, Box, Canva, Figma, Miro, Zendesk, Zoho, and multiple agent-factory vendors. Salesforce and MuleSoft are not among them.

This is not an oversight. It’s the boundary condition of two platforms that each believe they should be the system of record for enterprise agents — and neither is willing to create the integration that legitimizes the other’s claim.

Each is claiming discovery rights over the other’s ecosystem. Neither is granting reciprocal rights. MuleSoft can catalog Microsoft’s agents without Microsoft’s participation. Microsoft can catalog Salesforce’s agents without Salesforce’s participation. The reading is asymmetric by design.

The practical enterprise consequence: if you run both platforms — Anypoint for integration and Azure for AI infrastructure — you have two registries that each see part of your agent fleet. Neither sees the full picture. The unified governance view both vendors are promising requires choosing one registry as primary, which means choosing whose identity model governs your agents and whose scan covers your fleet.

Open Standards Don’t Resolve This

Both platforms normalize to the A2A agent-card specification. Both MuleSoft (Salesforce) and Microsoft sit on the A2A steering committee alongside AWS, Cisco, Google, IBM, SAP, and ServiceNow. The protocol for describing, advertising, and exchanging agents across platforms is genuinely shared.

The registry above the protocol is not.

This is the same pattern visible across every enterprise platform competition of the last decade: open standards emerge at the wire level — REST, OAuth, SAML, and now MCP and A2A — and proprietary catalog and governance layers are built above them. What’s usually portable in these evaluations is the raw artifact — the agent code, the A2A card format, the underlying model invocation. What isn’t portable is the governance layer built on top of it.

An A2A-compliant agent on AWS Bedrock can be cataloged by MuleSoft’s scanner and by Microsoft’s Registry Sync simultaneously. The agent card format is the same. The governance layers above it — Anypoint Exchange policies, Entra Agent ID, conditional access rules — are separate, non-interoperable, and accumulate independently on each side. A2A solves the description format problem. It doesn’t solve the registry ownership problem.

Honest Admission

Both mechanisms are genuinely early, and that matters for architecture decisions made today.

MuleSoft’s daily scan has real limits at enterprise scale — the registry lags reality, and add-by-URL registration on the roadmap is an acknowledgment that the scanner alone won’t cover everything. Microsoft’s scheduled sync doesn’t exist yet — only manual, on-demand sync is available in the current preview.

The asymmetry I’ve described exists today and may not exist in 18 months. Microsoft adding Anypoint to its Registry Sync supported platforms would close one side of the gap. MuleSoft expanding its scanner to cover Anypoint-managed agents from Microsoft’s perspective would close the other. Platform partnership dynamics — commercial, competitive, and technical — will determine whether either happens, and neither vendor has signaled any change publicly.

Don’t architect a permanent governance strategy around the current asymmetry. Understand it clearly enough that you’re not surprised by it when you get into implementation.

What to Actually Do With This

The scanner question is simpler to answer once you map your estate.

If you’re Anypoint-first and running agents on Azure Foundry, MuleSoft’s scanner already has the access path to catalog those agents. The question is whether you’ve configured it.

If you’re M365-first and running Salesforce Agentforce agents, Microsoft’s Registry Sync can surface them in Agent 365 — the question is whether you’ve set up the OAuth connected-app connection and accepted the manual-sync limitation while scheduled sync is in preview.

In both cases, the gap is the agents on the platform the other vendor doesn’t scan. Those are the shadow agents your governance framework doesn’t see — and shadow agents are where policy enforcement breaks down first. The traffic governance layer, which I covered in the Omni Gateway post, can only enforce policies on the agents it knows about. Discovery is the precondition for everything else.

The registry isn’t the whole governance story. It’s the entry point. What you do with the catalog once it’s populated — identity, policy, conditional access, and audit — is where the real work happens.

---

The companion piece that covers what happens after discovery — identity assignment, policy enforcement, and the lock-in that accumulates once you’ve committed to one registry’s identity model — is the Agent Control Plane War post. If you’re navigating an agent governance evaluation in a regulated environment, or you think I’ve gotten a platform detail wrong, I’m at @orestesgarcia on X and LinkedIn.