Microsoft, AWS and Google Each Have an Agent Registry. None Sees All Your Agents

Microsoft, AWS and Google each offer an agent registry now, which is a product that lists the AI agents running in your company. None of the three lists all of them. Each records agents built on its own platform with little effort and learns about the rest only when a person connects a platform or enters an agent by hand. Microsoft's own page, dated 5 November 2026, says its cross-platform sync is manual and can keep agents that were deleted at the source.

The practical answer is to choose one registry as the system of record, meaning the list your company treats as the truth. Choose it by where most of your agents and their identities already live. Treat every other registry as a feed into it, give one named team the job of reconciling them, and keep a plain spreadsheet for the agents no product can see.

What a registry has to answer

A registry earns its place when it answers four questions about every agent. The first is which agents exist and where each one runs. The second is who owns each agent. The third is what it can touch, meaning the data, tools and other agents it can reach and the identity it acts under. The fourth is how to switch it off and who is allowed to do so.

The practical test is an incident, when a security lead needs all four answers for one misbehaving agent within minutes. Seeing an agent in a list is also different from controlling it, because an imported entry does not by itself give you a way to stop the agent. The guide page on the AI agent registry covers the concept in more depth.

What the vendors changed in early November

Microsoft published a new page for Agent 365 "Connected platforms", the feature that copies agents from other vendors into the Microsoft registry. The page, dated 5 November 2026, lists seven sources: Amazon Bedrock, Google Vertex AI, Salesforce Agentforce, Databricks Genie, Anthropic Claude Managed Agents, Oracle Generative AI Agents and Snowflake Cortex. The same page states the limits: sync is "Manual synchronization only", and "Agent 365 doesn't currently sync on a schedule". Every platform "requires a key-based credential". The page also warns that "Deletion reconciliation isn't guaranteed".

Microsoft's pages disagree on whether this sync is a preview. The new Connected platforms page puts a preview label only on observability data collection. An older page, Choose an Agent 365 integration option, dated 30 September 2026, still calls the feature "Registry sync (preview)". Until Microsoft says it is generally available, plan as if it is a preview.

On the Azure side, Microsoft's documentation now says: "Microsoft Foundry Control Plane deprecates custom agents on May 7, 2027. You can no longer add new custom agents." Custom agents were the manual way to list an agent hosted outside Foundry. The replacement, external agents, is in preview. Microsoft says Foundry "stores only registration metadata" for these agents and "doesn't host, proxy, or invoke the runtime". The registration therefore shows traces once the agent sends telemetry, and it cannot stop the agent.

AWS announced that Agent Registry is generally available in AWS GovCloud (US-West), in a post dated 6 November 2026. Microsoft is also renaming what staff see. A Message Center notice, MC1484008, describes plugins that "can bundle agents, skills, connectors, and Model Context Protocol (MCP) servers into a single package", and says that "By late November 2026, users will select Plugins instead of Agents" to find agents in Copilot, according to a third-party mirror of the notice. Staff will look for agents under Plugins while the admin registry keeps the name Agents, so internal guidance needs an update.

What each registry sees on its own

The table covers the four lists a company using Microsoft, AWS and Google Cloud would have, as checked on 10 November 2026. AWS records general availability in its August 2026 release notes, and Google in its release notes for 18 June 2026.

Even the automatic column has gaps. Microsoft's registry page warns that "Publishing the agent in Copilot Studio alone might not make it visible in the admin center". AWS allows "only one active organization-scoped registry per Region", so a company in several Regions has several AWS lists. Google gathers agents across projects only inside a management boundary that an administrator configures. For agents that do not use A2A, an open protocol that lets agents describe themselves to each other, Google says its registry "can't automatically capture metadata such as the endpoint URL where the agent is hosted, the agent identity, and A2A skills".

Agents on laptops are a separate list again. Microsoft says local AI agent discovery in Defender for Endpoint is "generally available on supported Windows and macOS devices", and adds that "Installing an agent doesn't by itself guarantee an inventory entry". The cloud-by-cloud and framework-by-framework detail is in the companion whitepaper.

Why Microsoft 365 plus one other cloud gives you partial lists

Worked example: a company runs Microsoft 365 and builds its own agents on AWS. Copilot Studio agents land in the Agent 365 registry and AgentCore agents land in AWS Agent Registry. Agents the Azure team hosts in Foundry show up in Foundry Control Plane, a third list, and Microsoft's page says "Classic agents and Azure OpenAI assistants aren't supported" there.

Microsoft is the only one of the three whose documentation describes connectors that list agents on other vendors' platforms. AWS and Google document manual registration for agents hosted elsewhere. Microsoft's guide to connecting Amazon Bedrock covers Bedrock Agents Classic and AgentCore. It says nothing about agents that teams run on Lambda, in containers or on virtual machines, and AWS auto-detection covers AgentCore Runtimes and Gateways only. So an agent running in a container outside AgentCore appears in neither registry unless someone registers it by hand. That conclusion is our reading of the two documents, and neither vendor states it.

The copy that does arrive is only as fresh as the last time an administrator pressed the sync button. It also rests on a stored access key, because the Connected platforms page says keyless options "aren't currently supported".

Pick one system of record and treat the rest as feeds

Start with where the agents and their identities are, then check that the registry can hold the fields you need. If most of your agents are built in Copilot Studio and Microsoft 365, and their identities sit in Microsoft Entra, use the Agent 365 registry, since it is the only one of the three with documented connectors to other platforms. If most are engineering-built agents on AgentCore, use AWS Agent Registry. The Microsoft registry exports to a CSV file, but we found no documented import of that file into AWS, so a person has to reconcile it by hand. Set the schedule by how often your agents change.

For agents spread evenly across several vendors, compare a cross-vendor inventory with the work of reconciling by hand. MuleSoft Agent Fabric, for example, documents scheduled scanners for eleven provider families, limited to one run a day. A company with only a few agents can skip the products and run the spreadsheet below as its system of record. We would rely on feeds with less manual checking if a vendor shipped scheduled, keyless sync that removes deleted agents. Coverage of agents outside the supported platforms would still need a person.

The register for what no product sees

These registries can miss agents built into purchased software, agents on unsupported infrastructure and agents run by suppliers. Enter them in the system of record where it accepts manual entries. Where it does not, keep a spreadsheet as an annex with the same owner and review dates. We recommend fifteen starting columns, grouped here under the four questions, plus a note of the source registry and the last sync date for any synced entry.

• Which agent: agent ID, name and version, purpose, platform and location, model.
• Who owns it: business owner, technical owner and contact.
• What it can touch: agent identity, tools and connected agents, data reached and its sensitivity, risk tier.
• How to control it: status and approval, human oversight, kill switch, review dates.

Several standards ask for an inventory, and none of them prescribes a field list for agents. The NIST AI Risk Management Framework says under GOVERN 1.6: "Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities." A preliminary NIST draft from December 2025, NIST IR 8596, is the only standard text our research found that names agents: "Inventories should include AI models, APIs, keys, agents, data (see also ID.AM-07), and their integrations and permissions."

The EU AI Act sets no general inventory duty in Article 26, which covers companies that deploy high-risk systems. Article 49 concerns registration in an EU database, mainly by providers and by public authorities that deploy high-risk systems. The July 2026 amendment, Regulation (EU) 2026/1744, left the text of both articles unchanged, on our reading of the consolidated version on EUR-Lex, which is a documentation tool and carries no legal force of its own. The Article 26 duties for the high-risk uses listed in Annex III apply from 2 December 2027. When Article 49 registration starts to apply is a legal question our research could not settle, so ask counsel before you put a date on it.

What to do this month

1. Export the Agent 365 registry to CSV and count your agents by platform, then count AgentCore runtimes and Google Agent Runtime agents the same way.
2. Name one registry as the system of record in writing, with a named team responsible for reconciling the others into it.
3. Before connecting another platform to Agent 365, agree with security on a read-only key and on who re-runs the sync and checks for deleted agents.
4. Look in Foundry Control Plane for custom agents and plan their move to external agents before 7 May 2027, keeping the existing gateway in place as Microsoft's deprecation notice instructs.
5. Start the register with the agents no registry lists, beginning with those inside purchased software.

QueryNow helps IT teams set up the register and the controls around it as part of its AI agent security work.