leejk/ jk lee

Agent Governance: The Chapter After Standardization · 2026.06

Microsoft Agent 365: past the catalog, into cross-cloud sync

A control plane that ingests the AWS and Google registries — and the problem of two canonical copies

·
#microsoft#agent-365#agent-registry#mcp#governance#landscape

Microsoft Agent 365 went GA on 2026-05-01 and did not stop at its own registry — it entered as a cross-cloud control plane that syncs with the AWS Bedrock and Google Cloud registries. Where AWS Agent Registry was a single-cloud catalog, Agent 365 pulls another cloud registry into its own inventory, so the same agent now exists canonically in two registries at once. The operating question that follows is which registry is the single source and which gets demoted to a mirror — defer it, and the direction of the sync decides for you.

TL;DR. Microsoft Agent 365 went GA on 2026-05-01 and didn't stop at standing up its own registry — it entered as a cross-cloud control plane that syncs with the AWS Bedrock and Google Cloud registries. Where AWS Agent Registry was a single-cloud catalog, Agent 365's branch is pulling another cloud's registry into its own inventory. The moment it does, the "single source of truth" the index warned about stops being abstract and becomes a product default — the same agent now exists, canonically, in both AWS and Agent 365.

Why it matters now

The governance layer arrived all at once over one month in April, and within it AWS Agent Registry first bundled catalog, approval, and audit inside one cloud. Agent 365 GA (2026-05-01) goes one square further — it places governance not inside a cloud but across cloud boundaries. That registry sync opened in public preview the same day is the key signal.

What Microsoft Agent 365 is

Microsoft places Agent 365 as a Microsoft 365 control plane — an operational plane to discover, govern, and secure the agents in an organization. What the GA announcement bundled:

Against the governance four axes, Agent 365 extends Registry/Catalog from one cloud to multi-cloud federation.

The friction sync creates — two canonical copies

The head of the eight frictions in the AWS Agent Registry analysis was: "cloud governance assumes a single source; the local stack assumes many." Registry sync lifts that tension to cloud versus cloud — pinning only the conflicts that follow structurally from reading the sources.

  • Ownership of the canonical record. If an agent is registered in AWS Bedrock and Agent 365 syncs it into its own inventory, where is the canonical record for approval, deprecation, and naming? Sync makes a copy, and a copy forces the question of which one is true.
  • Doubled lifecycle authority. Agent 365 applying start/stop/delete to another cloud's agent means two lifecycles bound to one resource alongside AWS Registry's APPROVED-only, revert-to-DRAFT-on-edit lifecycle. This is exactly the "lifecycle conflict" the index foretold — by design, binding two lifecycles to the same resource neutralizes both.
  • Permission-model coherence. Three permission planes — Microsoft (Entra), AWS (IAM), Google (Cloud IAM) — meet on one sync path. When and how a permission change in one is reflected in the other two inventories sits outside the standard.

In sum

If AWS answered the operational gap inside one cloud, Agent 365 answers the gap across cloud boundaries — governance's next move is not a catalog but a sync of catalogs. Yet sync solves discovery while breaking canonicity. The instant the same resource is canonical in two registries, the operating question for the next cycle is exactly what the index foretoldwhich registry is the single source, and which gets demoted to a mirror. Now that the major clouds have started ingesting one another's registries, defer that decision and the direction of the sync makes it for you.

References

Same topic