By The Agent2Agent protocol crossed a milestone in April 2026 that is easy to miss: 150 organizations confirmed in production use, not pilots. AWS Bedrock AgentCore, Azure AI Foundry, and Google Vertex AI all support it natively. The Agentic AI Foundation — the Linux Foundation project that now governs both A2A and MCP — added 57 more member organizations at its Seoul summit last week, bringing the total to 247. A2A is infrastructure. The question is whether you are building on it correctly.
Most developers implementing A2A today are leaving a security gap that signed Agent Cards were specifically designed to close.
What 150 Organizations in Production Actually Means
A2A started as a Google open-source project in April 2025 with 50 founding partners. By April 2026 — one year later — the Linux Foundation announced the 150-organization milestone alongside concrete production deployments, not whitepaper commitments. Supply chain orchestration, financial services workflows, insurance claims routing, and IT operations are the verticals where it runs for real today.
The cloud platform support solidified the story. Microsoft integrated A2A into Azure AI Foundry and Copilot Studio. AWS added it to Bedrock AgentCore Runtime. Google baked it into Vertex AI. If your multi-agent infrastructure runs on any of these platforms, A2A support is already available — you are deciding whether to use it or roll a custom handoff protocol that nobody else speaks.
Signed Agent Cards: The Feature Developers Skip
Every A2A server publishes an Agent Card at /.well-known/agent-card.json. The card describes what the agent can do, what auth schemes it accepts, and how to reach it. It is publicly fetchable by design — any caller, authenticated or not, can read it.
A2A v1.0 introduced Signed Agent Cards to address a straightforward spoofing risk: without signatures, nothing stops a malicious actor from presenting a forged agent card and hijacking task delegation. The spec uses JSON Web Signature (JWS, RFC 7515) over a canonicalized representation of the card (RFC 8785). The signature is tied to the publisher’s domain. Callers are expected to verify the signature before trusting capabilities or auth schemes declared in the card.
Here is the part developers misread: signed cards verify the issuer. They do not keep embedded secrets private. An Agent Card is public. If you put an API key, a database connection string, or any credential directly in the card, it is exposed — signature or no signature. The spec is explicit about this. Declare securitySchemes to describe your authentication requirements. Never embed credentials in the card itself.
For sensitive details, use the authenticated Extended Agent Card endpoint (GetExtendedAgentCard). That path requires authentication before returning anything sensitive — it is the correct place for things you do not want publicly crawlable.
A2A and MCP Are Not Competitors
If you have been following the MCP ecosystem, A2A fits in without replacing anything. MCP handles the vertical connection — your agent reaching down to tools, databases, APIs. A2A handles the horizontal layer — your agent handing a task to another agent, possibly built by a different team on a different framework. MCP is how your agent picks up a tool. A2A is how your agent calls a specialist. (ByteIota covered the MCP 2026-07-28 stateless spec changes if you need to catch up on that side of the stack.)
The practical example: a Salesforce CRM agent routes a support escalation to a ServiceNow ITS agent via A2A. Neither team needs to know how the other built their agent. The Agent Card tells them what the other agent can do and how to authenticate. Both protocols now live under AAIF governance, which means the Linux Foundation is managing compatibility and stability — single-vendor lock-in is not the concern it was 18 months ago.
How to Start Building With A2A
The official SDK is straightforward:
pip install a2a-sdkThree things to implement: an AgentSkill describing capabilities, an AgentCard for discovery, and an AgentExecutor subclass with your logic in execute() and cancel(). Wire a DefaultRequestHandler and InMemoryTaskStore into an A2AStarletteApplication, run it with uvicorn, and the card is auto-published at /.well-known/agent-card.json.
For production: use short-lived OAuth 2.0 tokens scoped to specific agent capabilities. The April 2026 incident where an autonomous agent with leaked credentials wiped a production database — including all backups — in nine seconds is not a hypothetical. Static API keys in multi-agent systems are a liability, not a convenience. This is the same category of risk driving security alerts from AI coding agents in enterprise environments.
What to Check If You Already Have A2A Agents Running
Audit three things. First, are your Agent Cards signed? If you shipped before v1.0, they probably are not. Second, does any card contain a credential, connection string, or token? Fix that immediately — the card is public. Third, are you verifying incoming agent card signatures before delegating tasks? The SDK handles verification, but only if you wire it correctly.
The A2A protocol specification and the developer security guide from Tyk are the reference points. If you are building anything that routes tasks between agents, v1.2 is the version to build against — and signed cards are not optional anymore.
