Companies: MCP and A2A Enforce Identity and Control

Two protocols, MCP and A2A, are gaining traction for connecting and enabling collaboration among AI agents. However, at scale, they are insufficient: security, governance, context, and oversight become essential. Gartner anticipates more than 150,000 agents per Fortune 500 company within two years, while 76% of organizations report struggling with the transition to production. Here’s what these deployments truly entail.

Safeguards: Avoiding Speedy Errors and Security Blind Spots

Barr Moses warns that when siloed, MCP and A2A can primarily accelerate erroneous responses. Deploying agents necessitates observability standards, with tracking of steps and actions to diagnose collaborations, improve accuracy, address vulnerabilities, and support audits. David Mytton believes the next security challenge will emerge when agents work together, complicating visibility. In regulated sectors, Kamesh Tumsi reminds us that every interaction must comply with strict requirements. These challenges clash with operational reality: 76% of companies report critical blockages in moving from pilot to production, while Gartner projects over 150,000 agents per Fortune 500 company within two years.

Identities and Permissions: What MCP and A2A Do Not Decide

The protocols define how an agent presents identifiers but do not establish governance. It is up to organizations to define the identity of each agent, its access rights, and its authorized interlocutors. Kevin Paige notes that MCP and A2A fall under the Linux Foundation’s Agentic AI Foundation, but neither specifies who can initiate a call: MCP ties each token to a unique server audience and prevents transits, while A2A stops at AUTH_REQUIRED and leaves proof acquisition outside the protocol. Policies must govern access to unstructured and confidential data, detailing what actions are permitted, under what circumstances, and with what granularity. Andrew Hartnett emphasizes that these flows become non-human identities managed by programmatic secrets and recommends treating any agent operating on sensitive systems as a privileged identity, with the least privilege and human safeguards for risky actions.

Context Layers: Data Quality, Semantics, and Trust

MCP is particularly used to connect agents to the enterprise context layer, which brings together shared business semantics and graphs of entities and relationships. At scale, this layer must rely on high-quality data, non-negotiable governance, and real-time AI governance. Felix Van de Maele distinguishes between governance of inputs (context, semantics) and outputs (what the agent does and what it is authorized to do), and reminds us that in the absence of agreement on terminology, trust in responses is impossible. BI deployments directly connected via ODBC/JDBC have created webs of connections and siloed views, even in small organizations; following this path exposes one to "AI debt." Data fabrics provide a foundation, but the work lies in elevating knowledge quality and linking agent activity to expert validations. Vivek Vaidya points out that adding endpoints or messages does not create a learning system if each agent starts from scratch; he advocates for preserving shared context, decision history, and human judgment. Trust between business experts and agent results must be built, with the context layer remaining in continuous evolution. Barr Moses warns against the illusion that a protocol would cover the trust layer, and James Oh insists on reliable means for agents to evaluate the tools and peers to trust.

Specialized Agents Foster Process Transformation

Many agents are designed by tasks, which facilitates access control and performance tracking. As deployments progress, opportunities arise to rethink processes through agent collaboration. Oskar Konstantyner describes a shift where each agent brings its expertise and co-determines the task, beyond orchestrating predefined capabilities. Processes such as order processing, onboarding, or compliance reporting can transition to sequences driven by cooperating agents, while Daniel Meyer reminds us that these processes predate current AI. This redesign requires A2A to delegate and exchange results among independent agents. Marc Sanfaçon clarifies that A2A standardizes these exchanges and that, when combined, MCP and A2A help navigate complex processes, provided that systems deliver relevant and up-to-date information and enforce rights.

What MCP and A2A Do, and Where They Stop

Technical leaders clearly distinguish the roles: MCP acts as a toolkit or secure USB port that connects an agent to files, databases, or SaaS without custom gateway code; A2A ensures negotiation and coordination among agents, like a generalist and its subcontractors. For Arpita Soni, MCP standardizes the vertical access of a single agent to tools and data, while A2A provides horizontal connectivity: discovery, capability negotiation, and task handoff between agents, with a common language for communication and delegation. These protocols lay the groundwork, but scaling requires additional layers: identities and permissions, enterprise context, re-engineering, and agenticops. Their adoption is accelerating: creation tools (Bolt.new, Lovable, Pave, Replit, v0) connect to MCP servers, AI editors (Claude Code, Cursor, Devin Desktop, Gemini CLI, GitHub Copilot, Kiro) incorporate MCP clients, and large models expose customizations via MCP and A2A. They are expected to impact agent management in enterprises, even if their mere presence does not resolve orchestration or governance.