Agentic AI introduces new security challenges in era of MCP and A2A

Enterprises have worked for decades to develop their cybersecurity architecture and protect against data breaches. Booming GenAI adoption has challenged cybersecurity efforts the past couple years, but the rise of agentic

AI has introduced an even bigger hurdle. As AI agents gain the ability to autonomously discover tools, collaborate with other agents, and make decisions at machine speed, organizations are encountering a new threat: agent breaches.

With protocols like Anthropic’s Model Context Protocol (MCP), Google’s Agent-to-Agent (A2A), and IBM’s Agent Communication Protocol (ACP) enabling AI agents to communicate directly, the security landscape is evolving fast.

These autonomous agents operate at speeds far beyond human monitoring capabilities, and they often have access to sensitive systems.

We’ve moved past basic AI security quandaries (for example, Will these models train my competitor using my data?).

Organizations are now generally confident that deploying large models within secure private cloud environments offers protections similar to conventional cloud databases with appropriate governance in place.

There’s a new concern today. In the multi-agent AI era, models call other models, creating all sorts of new attack surfaces. Giving models more autonomy to achieve also means giving them more keys to the data kingdom.

The vulnerabilities of MCP, A2A, and ACP

Traditional data breaches were about unauthorized access to information. Agent breaches are about unauthorized or unintended agent behavior.

That means agents accessing the wrong data, misinterpreting critical information, or creating vulnerable chains of communication between systems.

For the most part, models are not capable of getting data on their own. So agents need programs and people to get the ball rolling, to put data to work.

Protocols like MCP let agents find and use other useful agents to follow-through, but are those interconnections secure and what are the new parts of the attack surface?

MCP, A2A, and ACP all bring their own unique concerns.

Let’s start with MCP. MCP enables agents to discover tools dynamically, going far beyond the static endpoints of traditional APIs. While this allows flexibility, it can also mean agents interact with unknown or unverified tools, increasing the risk of impersonation attacks.

Without built-in verification mechanisms, MCP requires external security layers to make it viable in enterprise settings. You need to add your own layers of protection to make sure it’s enterprise-ready.

Next is A2A. A2A raises questions of accountability and control when agents interact with those from other vendors. Who is responsible for decisions made jointly? Are communications secure?

What models are involved, and are they susceptible to drift? Traditional monitoring might not detect proprietary data embedded in AI summaries, making it difficult to ensure governance.

Agentic AI attacks are fast and devastating

AI works far faster than humans. That means that when things go wrong with agents, it happens at machine speed. Agentic AI attacks go beyond simple prompt injections. Generally, attackers try to do at least one of three things:

1) extract an agent’s architecture to map an organization’s entire AI architecture, 2) steal agent instructions and tool schemas to uncover business logic and proprietary methodologies, and 3) exploit tool misconfigurations to gain access to a corporate network.

This can play out a few ways in the real world. Consider the following scenario: A financial services firm deploys an AI agent to help with vendor payments.

An attacker discovers they can ask the agent to “verify payment details” for a fake vendor, then convinces it to initiate a “test transaction” of $1. Once successful, they escalate to larger amounts by framing requests as “urgent executive approvals.”

Here’s another example that could happen in virtually any sector. In a multi-agent system where a data analysis agent feeds insights to a strategy agent, attackers poison the analysis agent’s outputs with subtly biased interpretations.

Over weeks, this leads the strategy agent to recommend increasingly poor business decisions, all while appearing to function normally.

Control is key to safely adopting agentic AI

How can enterprises use agentic AI safely? It’s all about taking and maintaining control. Begin with these five steps: Centralize access to AI models: Give everyone rights to models, but through a monitored, metered gateway that you control.

Leverage hyperscaler tools: apply the tools available from your hyperscaler, knowing you’re not the only enterprise with these issues. But be wary about giving them full control to choose the actual AI model instances for you, without your say.

Check for vendor compliance: Ensure your vendors are compliant with your strategy, using your gateway access for built-in AI logic. Standardize, standardize, standardize: Standardize on the big blocks like AI cost reporting, evaluations, and testing model drift.

Build a repository: create a repository for prompts, tools and embedding vectors that is simple to manage and easy to connect, like your data sources are for reporting tools and exports.

Agentic AI offers transformative value, amping up the ROI of “traditional” GenAI significantly. Companies shouldn’t be afraid or slow to adopt agents. They just need to be thoughtful.

Build security into the foundation of multi-agent environments. Centralize control without creating bottlenecks. Monitor everything without slowing anything down.

The shift from preventing data breaches to preventing agent breaches requires new thinking and new governance models.

But the fundamentals remain: know what’s happening in your systems, control who has access, and build security into the foundation rather than bolting it on after.

We've featured the best business VPN.

This article was produced as part of TechRadarPro's Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro