Cross-Cloud Agent Ecosystems: How AWS, Azure, and GCP Are Shaping MCP, A2A, and Secure Agent Identity
AI Security & Development
Autonomous agents are no longer just research tools. They're now powering real workflows, from developer copilots to AI systems coordinating complex tasks. But as these agents move into production, one thing is clear: better models aren’t enough. We need infrastructure.
For agents to operate securely and reliably across cloud environments, we need four key layers:
Discovery – How agents find other agents or tools
Authentication – How they prove who they are
Authorization – How they’re allowed to act
Delegation – How they securely pass off responsibilities
This post explores how AWS, Azure, and GCP are approaching these layers, specifically through MCP (Model Context Protocol) and A2A (Agent-to-Agent communication).
MCP and A2A, Explained
Model Context Protocol (MCP) defines how agents interact with the tools, models, and memory around them. Think of MCP as a standardized “context wrapper” for an agent. It gives structure to agent inputs, outputs, and dependencies. It also makes agents easier to audit, compose, and reuse.
Agent-to-Agent (A2A) communication adds a trust layer between agents. It answers questions like: If Agent A calls Agent B, how does B know it can trust the request? This is where signed tokens, agent identity (like DIDs), and delegation mechanisms come in.
Used together, MCP and A2A create the foundation for secure, scalable, autonomous systems.
Comparison at a Glance
AWS: Scale-First Agent Infrastructure
AWS is quietly building one of the most powerful agent stacks in production today.
MCP tools: The Strands SDK and Bedrock Agents provide context-aware orchestration with embedded memory, tools, and reasoning. These agents can run on Lambda, Fargate, or ECS, giving teams strong options for scale and isolation.
A2A support: While AWS doesn’t offer a formal spec for agent-to-agent trust yet, their documentation shows early patterns. Developers can wrap agents in Agent Cards, use JWTs for delegation, and coordinate workflows with EventBridge or Step Functions.
Authentication: AWS leans on familiar primitives, IAM roles, Cognito with OAuth 2.1, and KMS for signing. CloudFront and WAF can provide request-level filtering. It’s a robust and well-integrated stack.
Discovery: Cloud Map supports DNS-based service discovery, and public Agent Cards can be self-hosted and signed with KMS. A centralized registry is likely on the roadmap.
Azure: Enterprise-First Identity and Agent Governance
Azure’s approach is grounded in identity, governance, and policy control.
MCP tools: Copilot Studio allows teams to build agent workflows with embedded model context. AI Foundry templates extend that with pipeline logic and structured prompting.
A2A support: Azure is pushing the concept of “Agent ID” through Microsoft Entra. These agent identities can be registered, scoped, audited, and governed. Conditional Access policies even allow device- or context-specific delegation.
Authentication: Azure uses Entra for role-based access and agent claims. Microsoft Purview adds audit trails across data and agent usage. Support for mTLS, OAuth 2.1, and Verifiable Credentials is growing.
Discovery: Azure is building a centralized Agent Registry tied directly to Entra. This will enable consistent delegation across Microsoft 365, Dynamics, and Azure workloads.
GCP: Open Standards and Developer Flexibility
Google Cloud is leading in agent interoperability, though it still leaves much up to developers.
MCP tools: Vertex AI Agent Builder supports tool use, routing, and state with context-wrapping via Vertex Pipelines and API Gateway.
A2A support: Google introduced the Agent Card spec, where each agent hosts a public
.well-known/agent.jsonfile describing capabilities, tokens, and endpoints. They also support token streaming for multi-step delegation across agents.Authentication: IAM service accounts, OAuth 2.1, and mTLS are all in place. JWTs can be signed and verified using Cloud KMS.
Discovery: No central registry exists yet. Developers host their own Agent Cards and rely on URL-based discovery. A decentralized discovery model is emerging, but tooling remains manual.
Where the Gaps Still Exist
Despite solid progress, several foundational pieces are still missing:
No Agent Name System (ANS): There’s no DNS-style lookup for agents. OWASP’s ANS proposal outlines a public key infrastructure for this, but adoption is still early.
No Cross-Cloud Registry: Every cloud vendor has its own discovery mechanism. There's no shared registry for federated agent ecosystems.
No Lifecycle Standards: There's no consistent way to onboard, revoke, or rate agents. Certificate management and trust scoring are still ad hoc.
These gaps create opportunities for open-source tooling, interoperable standards, and new infrastructure layers that support agent interoperability across environments.
Want to Try It Yourself?
You don’t have to wait for standards to mature. Here are a few things you can build right now:
Wrap an agent using an MCP pattern (like Bedrock Agents or Vertex AI)
Use JWTs with Cognito or Entra to simulate agent delegation
Host your own
.well-known/agent.jsonfor agent metadataRegister agents in Cloud Map with signed tokens
Explore libraries like
@agentic-profile/auth,jsonwebtoken, or cloud-native SDKs
Final Thoughts: The Road to an Interoperable Agent Economy
Major cloud platforms are building the foundation for composable, agent-first systems. But it’s up to developers, architects, and security teams to help shape what comes next.
If you’re designing AI assistants, internal agents, or multi-agent services, the choices you make around identity, delegation, and discovery will define their trustworthiness, and their potential.
The agent economy is coming. Let’s make sure it’s secure, flexible, and open.
Want the full deep dive? Check out my full article on Medium.
🚀 Stay tuned for more posts in AI Security & Development! Follow for more insights on securing AI, cloud, and Web3.
AI Security & Development - AI table of contents included.