--- title: "How to Govern AI Agents Across Multiple Clouds" url: "https://atlan.com/know/ai-agent/how-to-govern-ai-agents-across-multiple-clouds/" description: "AWS, Microsoft, Google, and MuleSoft each run their own AI agent registry. See how to govern AI agents across multiple clouds with one shared framework." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-09-01" updated: "2026-09-01" --- --- AWS, Microsoft, Google, and MuleSoft have each shipped a dedicated AI agent registry within the same twelve months, from MuleSoft's January 2026 launch to AWS Agent Registry's general availability on August 31, 2026. Every registry answers one question well: is this agent approved to run on this platform. None answers what happens once that approved agent crosses into a second cloud, a third registry, or data the first registry never saw. Governing agents across multiple clouds means answering both questions on purpose. --- Governing agents across multiple clouds is not one decision. It is five capabilities working together: a shared inventory across every registry you run, business definitions that don't change by platform, lineage that survives a handoff between clouds, certification that travels with the data instead of resetting at each registry, and an audit trail covering the whole fleet. - One inventory across every registry, not four separate spreadsheets - Definitions and certification that hold their meaning across clouds - Lineage and audit trails that survive a handoff between platforms - A way to add a fifth registry without starting the governance work over | Category | Multicloud AI agent governance | |---|---| | Guide type | New capability layered on registries you already run | | Typical timeline to a working baseline | 6-10 weeks | | Key stakeholders | AI/platform engineering lead, data governance lead, security/CISO, cloud platform owners | | Budget range | Engineering and process investment, layered on registries you already run | | Core evaluation criteria | Cross-platform inventory, shared definitions, portable certification, cross-cloud lineage, retrieval-time policy enforcement | --- ## Why does governing AI agents get harder with every cloud you add? Four of the largest platforms in enterprise software built and shipped their own agent registry in roughly the same year. MuleSoft's Agent Registry reached general availability in January 2026, built on the [Agent2Agent (A2A) protocol](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) Google introduced for cross-agent communication. Microsoft's Agent 365 followed with its own registry, [generally available by May 2026](https://www.microsoft.com/en-us/security/blog/2026/05/01/microsoft-agent-365-now-generally-available-expands-capabilities-and-integrations/). Google folded its Agent Registry into the [Gemini Enterprise Agent Platform](https://docs.cloud.google.com/agent-registry/overview), the Cloud Next 2026 rebrand of Vertex AI. AWS Agent Registry, part of Bedrock AgentCore, [reached general availability on August 31, 2026](https://www.infoworld.com/article/4157183/aws-targets-ai-agent-sprawl-with-new-bedrock-agent-registry.html), with a governance plane for approvals and a discovery plane for search. | Vendor | Product | Launch / GA | Scope | |---|---|---|---| | AWS | AWS Agent Registry (Bedrock AgentCore) | GA Aug 31, 2026 | AWS-native agents, tools, skills; open ARD spec for federated discovery | | Microsoft | Agent 365 registry | GA ~May 2026 | Copilot Studio, Foundry, partner agents; preview sync with Bedrock and Google Cloud | | Google | Agent Registry (Gemini Enterprise Agent Platform) | 2026 Cloud Next rebrand | Agents, tools, and MCP servers on Google Cloud | | MuleSoft (Salesforce) | Agent Registry / Agent Fabric | GA Jan 2026 | Agents, tools, and MCP servers via the A2A protocol | Databricks adds a fifth variant outside the table: [Unity AI Gateway](https://atlan.com/know/ai-agent/databricks/unity-ai-gateway/) and [Agent Bricks](https://atlan.com/know/ai-agent/databricks/agent-bricks/) govern runtime agent behavior on that platform alone. According to Gartner (2026), the average Fortune 500 will run more than 150,000 agents by 2028, up from fewer than 15 in 2025, and a centralized inventory is step two of its six-step sprawl framework. "Centralized" now has four competing definitions: as Forbes put it in April 2026, enterprises adopting these registries in parallel risk "[recreating the very fragmentation these tools are meant to solve](https://www.forbes.com/sites/janakirammsv/2026/04/10/agent-registries-become-the-new-battleground-for-cloud-giants/)." Each registry beats no registry. None was built to see past its own platform's edge, and few enterprises run only one platform for long. This is [agent sprawl](https://atlan.com/know/ai-agent/agent-sprawl/) at the platform level: the same proliferation that shows up in duplicate agents and orphaned [agent identities](https://atlan.com/know/ai-agent/ai-agent-identity/) now shows up one layer up, in the registries meant to control it. --- ## What does an AI agent registry actually govern? An agent registry governs the agent as an asset: its identity, owner, approval status, version, and whether another team can discover and reuse it. AWS Agent Registry makes this explicit with a governance plane for approvals and a discovery plane for search. That's a real job, closer to how a [model registry](https://atlan.com/know/model-registry-implementation-guide/) tracks a model's lifecycle than to an [agent governance](https://atlan.com/know/ai-agent-governance/) framework covering what the agent may know. It's also distinct from a compliance-focused [AI system registry](https://atlan.com/know/what-is-ai-registry/) built for a regulatory question, and from an [agent skills registry](https://atlan.com/know/ai-agent/ai-agent-skills/agent-skills-registry/) scoped to skill packages rather than the full catalog AWS and its peers now cover. Some of this is federating across platforms. Microsoft's registry can sync with Amazon Bedrock and Google Cloud in public preview, and AWS published an open [Agentic Resource Discovery](https://aws.amazon.com/blogs/machine-learning/manage-agents-tools-and-skills-at-scale-with-aws-agent-registry/) spec, one of several [interoperability protocols](https://atlan.com/know/agent-interoperability-protocols/) competing for that role. The A2A protocol, governed by the Linux Foundation's Agentic AI Foundation, already has 150+ organizations running it in production. A reasonable person could ask whether the registry-per-platform problem resolves itself once these protocols mature. It resolves half of it. A2A and ARD federate identity and inventory: which agent exists, which registry approved it, whether a second platform can find it. Neither federates meaning. An agent's approval record can sync flawlessly across three clouds while "revenue" still means three different things to the systems it reads from. Federated discovery tells you an agent is allowed to run; it says nothing about whether the answer it just gave is still true. That gap is why a [context layer](https://atlan.com/know/ai-agent/context-layer/multi-cloud-context-layer/) has to sit underneath the registries rather than wait for them to converge. --- ## What capabilities does a cross-cloud agent governance approach need? Eight capabilities separate an approach that works across clouds from one that stops at the first cloud boundary. | Capability | Why it matters | What to look for | |---|---|---| | Cross-platform agent inventory | No visibility, no governance | One list spanning every registry, refreshed automatically | | Consistent identity and permission model | Shared credentials block clean audits | Non-human identity mapped onto each registry's own IAM/OAuth | | Shared business-term definitions | One meaning for "customer" or "revenue," not four | Definitions certified once, referenced everywhere | | Lineage crossing cloud boundaries | One traceable path across three clouds | Lineage that doesn't stop at a cloud's edge | | Portable certification status | Stale in one registry, stale everywhere | Certification attached to the data, not one catalog entry | | Policy enforcement at retrieval | One-time approval, every-run retrieval | Access rules applied at the moment of query | | Drift and staleness detection | Post-approval data drift | Alerts when a certified source is modified | | Auditable answer-to-source trace | Regulators need why, not what | A record of what context drove each answer | **Must-have** for any enterprise running two or more registries: cross-platform inventory, shared definitions, cross-cloud lineage, and retrieval-time policy enforcement. **Nice-to-have as the program matures**: portable certification automation, drift detection, and a fully auditable trace. Regulated industries should treat [GDPR](https://atlan.com/know/ai-agent/gdpr-compliance-for-ai-agents/) and [HIPAA](https://atlan.com/know/ai-agent/hipaa-compliance-for-ai-agents/) as must-have from day one, since [PII handling](https://atlan.com/know/ai-agent/data-for-ai/how-to-handle-pii-in-ai-pipelines/) across clouds is where most compliance gaps surface. Skip any one of these eight, and a program that looks complete on an audit slide still lets an agent act on data nobody checked. --- ## Do you need a registry or a context layer? The honest answer is both, and most enterprises reach this question only after they already have two or three registries live and the audits still feel incomplete. The [enterprise context layer](https://atlan.com/know/context-layer-enterprise-ai/) is the piece most evaluation frameworks skip entirely. **You are relying on registry controls when you need to know:** which agents exist, who owns each one, whether an agent was approved before it shipped, and which version is running now. AWS's, Microsoft's, Google's, and MuleSoft's registries all do this well, each on its own platform. **You need a context layer when you need to know:** whether the data an approved agent just read is still accurate, who owns its definition, how a number traces to source across every cloud it touched, and whether a policy applied at retrieval, not just approval. This layer has to be [portable across whichever registry approved the agent](https://atlan.com/know/ai-agent/context-portability/), because the agent doesn't stay on one platform for its whole working life. Most enterprises don't choose one or the other. They're already several registries into discovering they need a [role-based access model](https://atlan.com/know/ai-agent/context-layer/context-layer-role-based-access-control/) neither registry was built to provide, since the [agent skills](https://atlan.com/know/ai-agent/ai-agent-skills/governed-context-for-agent-skills/) each one catalogs still need context to be trustworthy once they run. Evaluate that layer on its own [criteria](https://atlan.com/know/ai-agent/context-layer/context-layer-evaluation-criteria/), separate from any registry's roadmap: [model-agnostic](https://atlan.com/know/ai-agent/context-layer/model-agnostic-context-layer/), [vendor-neutral design](https://atlan.com/know/ai-agent/context-layer/single-stack-lock-in-vs-neutral-context-layer/) is what keeps it from becoming a fifth silo. --- ## A 5-step framework for governing agents across multiple clouds A structured rollout takes most platform teams 6-10 weeks to reach a working baseline, longer if inventory turns up more shadow agents than expected, which it usually does. The sequence below mirrors [how to implement an enterprise context layer](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/), scoped to the specific problem of doing it underneath several registries at once. **Step 1: Inventory what's already running per cloud.** Pull every registered agent from every registry you operate, plus anything running outside them. Most teams find more than expected, especially partner agents nobody centrally approved. Result: one list you can actually govern. **Step 2: Define one shared context standard across registries.** Agree on business terms, ownership, and certification criteria that must not vary by platform. "Certified" needs to mean the same thing everywhere, or certification is decoration. Result: the one artifact every later step depends on. **Step 3: Map each registry's approval workflow to that shared standard.** Don't rebuild identity and approval logic per cloud; map AWS's, Microsoft's, Google's, and MuleSoft's approval flows to one underlying policy. [Who owns that mapping](https://atlan.com/know/ai-agent/who-owns-ai-governance-caio-vs-cdo-vs-cto/), and whether a [model council](https://atlan.com/know/ai-agent/what-is-a-model-council/) reviews exceptions, matters more than which registry technology wins. Result: a policy layer that travels. **Step 4: Deliver governed context through a protocol every registry's agents can reach.** Whether via MCP, A2A, or both, context should come from one governed source at query time, not four drifting copies. Skills are what an agent can do; [MCP is how it retrieves what it needs to know](https://atlan.com/know/ai-agent/ai-agent-skills/agent-skills-vs-mcp/). Result: the mechanism that makes "governed everywhere" true. **Step 5: Monitor and audit across the fleet, not per platform.** Cross-registry blind spots, not single-platform failures, are where these programs break. [Context observability](https://atlan.com/know/ai-agent/ai-agent-observability/context-observability-for-ai-agents/) built for one registry won't catch a failure spanning three. Result: an audit trail answering what every agent knew when it acted. --- ## Evaluation scorecard for a cross-cloud governance approach Score any approach (vendor tool, internal build, or a platform's own registry extension) against the same weighted criteria. | Criterion | Weight | Option A | Option B | Option C | |---|---|---|---|---| | Cross-platform inventory | 20% | | | | | Shared business definitions | 15% | | | | | Lineage across cloud boundaries | 15% | | | | | Portable certification | 10% | | | | | Retrieval-time policy enforcement | 15% | | | | | Drift and staleness detection | 10% | | | | | Auditable answer-to-source trace | 10% | | | | | Effort to add a new registry later | 5% | | | | | **Weighted total** | **100%** | | | | **Red flags:** one cloud covered with "multicloud" on a roadmap slide; certification that doesn't survive a handoff between registries; no way to trace an answer to source across platforms; policy enforced only at approval, never at retrieval; adding a fifth registry means redoing the work. Score against [production at scale](https://atlan.com/know/ai-agent/ai-agent-scaling-in-production/), not a demo: an approach that can't clear the bar for [enterprise-ready agents](https://atlan.com/know/ai-agent/enterprise-ready-ai-agents/) fails the same way in production, with more agents attached. --- ## How Atlan approaches multicloud agent governance Atlan is the Context Layer for AI: it answers what an agent may know, whether that's still true, and how an answer traces to source, sitting underneath whichever registry approved the agent to run. AWS Agent Registry, Microsoft's Agent 365, Google's Agent Registry, and MuleSoft's Agent Fabric stay exactly what they are. Atlan connects to metadata each platform already produces, including catalogs like Databricks Unity Catalog and Snowflake, so certified definitions, ownership, and lineage reach an agent regardless of which registry cleared it. The [Enterprise Data Graph](https://atlan.com/know/ai-agent/knowledge-graph/knowledge-graph-construction-for-ai/) unifies metadata, definitions, and policy from every cloud into one structure, instead of four catalogs that each know only their own slice. [Context Repos](https://atlan.com/know/ai-agent/context-repository-for-ai-agents/) package that meaning into versioned units, so the same definition serves an agent in AWS Bedrock and one in a Databricks Genie Space without rebuilding it twice. The [Atlan MCP server](https://atlan.com/know/ai-agent/how-to-build-mcp-servers-for-enterprise-data/) delivers it: a registered agent retrieves the same governed context at query time, not a platform copy. Context Governance and Observability then certifies an agent used the right context, not merely that it was approved to run. That gap is measurable. In Atlan's own AI Labs benchmark, adding governed context to a text-to-SQL agent improved accuracy by 38%. Registries confirm an agent is allowed to ask the question. Only [governed, current context](https://atlan.com/know/ai-agent/data-for-ai/data-lineage-for-ai/) determines whether the answer is correct, regardless of which registry the agent happened to clear. --- ## Real stories from real customers: governing context across clouds "AI initiatives require more context than ever. Atlan's metadata lakehouse is configurable, intuitive, and able to scale to hundreds of millions of assets. As we're doing this, we're making life easier for data scientists and speeding up innovation." — Andrew Reiskind, Chief Data Officer, Mastercard Watch Now "Atlan captures Workday's shared language to be leveraged by AI via its MCP server. As part of Atlan's AI labs, we're co-building the semantic layer that AI needs." — Joe DosSantos, VP Enterprise Data & Analytics, Workday Watch Now Mastercard's program named multicloud sprawl directly as the problem it had to solve before agentic workflows could scale. Workday shows the other half: context defined once, delivered through MCP rather than rebuilt per surface. Both stories are the layer underneath the registry each company already runs. --- ## Why the registry you pick isn't the governance decision that matters The registry-per-platform outcome most multicloud enterprises live with isn't a mistake anyone made. It's the default result of four vendors each building the best registry for their own platform, and enterprises reasonably buying more than one. Waiting for AWS, Microsoft, Google, and MuleSoft to converge on a shared standard treats a vendor roadmap as a governance strategy, and roadmaps change. The decision that actually matters isn't which registry to standardize on. It's whether the context an agent relies on stays true and traceable regardless of which registry approved it, because that agent will eventually touch data, tools, and teams the approving registry can't see. Build that layer once, and every new registry you add plugs into a model that already works. Book a Demo --- ## FAQs about governing AI agents across multiple clouds **1. Do I need a separate AI agent registry for every cloud I use?** Yes, in practice, if you run agents natively on more than one platform. AWS's, Microsoft's, Google's, and MuleSoft's registries are each scoped to their own platform. Multiple clouds means multiple registries unless you add a layer that governs across all of them. **2. What's the difference between an AI agent registry and MCP?** A registry catalogs and approves agents and who owns them. MCP is the protocol an approved agent uses to retrieve governed data at query time. One decides if an agent can run; the other decides what it can know once it does. **3. Can AWS Agent Registry, Microsoft Agent 365, and Google's Agent Registry talk to each other?** Partially, and only for inventory and identity. Microsoft's registry can sync with Amazon Bedrock and Google Cloud in public preview, and AWS's ARD spec supports federated discovery. None of this synchronizes the meaning of the data each agent reads. **4. Does the A2A protocol solve multicloud agent governance?** No, though it solves an adjacent problem well. A2A, governed by the Linux Foundation's Agentic AI Foundation, lets agents on different platforms discover and communicate, with 150+ organizations running it in production. It federates identity and discovery, not the definitions or certification status that determine whether an answer is correct. **5. Who should own AI agent governance across clouds?** Typically a joint effort: platform engineering owns technical delivery of context and registry integrations, data governance owns definitions and certification, and security owns the identity model spanning every registry. **6. What happens if an approved agent uses stale or wrong data?** A registry has no mechanism to catch this. Approval confirms an agent was cleared to run in the past; it says nothing about whether the dataset it just queried is still current. Catching this needs drift detection and certification attached to the data itself. **7. How long does it take to stand up cross-cloud agent governance?** Most platform teams reach a working baseline in 6-10 weeks, following the inventory, shared-standard, approval-mapping, delivery, and monitoring steps in sequence. Inventory usually takes longer than planned. **8. What's the biggest mistake enterprises make governing agents across multiple clouds?** Treating registry approval as the finish line. Teams that stop at "approved everywhere it touches" still ship agents reasoning from stale data, because approval never checked whether the data was true. --- ## Sources 1. [AWS Machine Learning Blog, "Manage agents, tools, and skills at scale with AWS Agent Registry"](https://aws.amazon.com/blogs/machine-learning/manage-agents-tools-and-skills-at-scale-with-aws-agent-registry/) 2. [InfoWorld, "AWS targets AI agent sprawl with new Bedrock Agent Registry"](https://www.infoworld.com/article/4157183/aws-targets-ai-agent-sprawl-with-new-bedrock-agent-registry.html) 3. [Gartner Newsroom, "Gartner Predicts 40% of Enterprise Apps Will Feature Task-Specific AI Agents by 2026"](https://www.gartner.com/en/newsroom/press-releases/2025-08-26-gartner-predicts-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026-up-from-less-than-5-percent-in-2025) 4. [Microsoft Security Blog, "Microsoft Agent 365, now generally available, expands capabilities and integrations"](https://www.microsoft.com/en-us/security/blog/2026/05/01/microsoft-agent-365-now-generally-available-expands-capabilities-and-integrations/) 5. [Google Cloud Documentation, "Agent Registry overview"](https://docs.cloud.google.com/agent-registry/overview) 6. [MuleSoft Blog, "How to Catalog Agents Automatically With Agent Scanners"](https://blogs.mulesoft.com/news/agent-scanners/) 7. [Google Developers Blog, "Announcing the Agent2Agent Protocol (A2A)"](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) 8. [Forbes, "Agent Registries Become The New Battleground For Cloud Giants"](https://www.forbes.com/sites/janakirammsv/2026/04/10/agent-registries-become-the-new-battleground-for-cloud-giants/)