Agents are autonomous and increasingly capable but are they secure? As we move from chatbots to agentic workflows, the protocols enabling agents are exposing us to vulnerabilities like it's the early days of web 2.0 all over again!
Introduction
Welcome to the first post in our series about agentic security. In this post we will dive in to the fundamentals and focus on the two main agentic protocols: Model Context Protocol (MCP), Agent To Agent (A2A) and we'll give a brief mention of Agent Communication Protocol (ACP).
Given that the world of AI moves very fast, even by the time we post this, there will be some new information. However, we will do our best to summarise agentic security and provide enough useful tips and information over the next few posts so that even as the world changes, what is written here will still be helpful to anyone reading in the future.
Each protocol is a different approach to enabling agentic communication and both can and are used together. But why do we want agents to communicate and what even is the point in an agent anyway?
An agent is an autonomous entity that uses the capabilities available to it to perform its given instructions. Agents can have access to LLMs and other AI models to enable them to process data and make decisions "intelligently" but this is not a requirement. An agent can be a simple set of "if this then that" instructions that are blindly followed with no "thought". As people realised that AI had the potential to usefully automate a great deal of tasks, it naturally lead to breaking repeat and distinct tasks into to their own bots or "agents". A modern AI system will usually make use of a number of agents with varying degrees of capabilities and "intelligence". The use of agents is a powerful tool in creating these systems but as we will discuss, this comes with some very serious security implications that when overlooked can have (and have had) disastrous effects.
Model Context Protocol (MCP)
Overview
Of all the agentic protocols, MCP is the most widely implemented and used. MCP was developed by Anthropic and released in November 2024. MCP looks at the agentic problem and answers the question "How do I give my agents access to stuff?". It follows a Client-Server model where "Servers" are used to expose resources to "Clients". "Hosts" act as the orchestrators of their Clients. Servers are independent entities who expose some resource (or group of resources) to the Clients connecting to them. Servers can be located within the same system as the Host or maybe an entirely separate system hosted on the internet by a third party. MCP uses JSON-RPC and aims to provide a stateful session protocol to enable and co-ordinate the communication between Servers and Clients in a uniform and standardised way.
MCP is made up of a Data Layer and a Transport Layer.
The Data Layer uses JSON-RPC to offer the following:
Lifecycle Management - Connection initialisation, capability negotiation and connection termination for Clients and Servers.
Server Features - Allows Servers to provide core functionality including Tools (calling APIs etc), Prompts (predefined prompts to help users interact with tools effectively) and Resources (data access).
Client Features - Allows Servers to talk back to the Clients to ask for input, sample from the host LLM and log messages to the Client.
Utility Features - Provides support for additional features such as notifications for real-time updates and progress tracking of long running tasks.
The Transport Layer supports two transport mechanisms:
STDIO Transport - Standard I/O streams are used for direct, fast interprocess communication between local processes on the same Host.
Streamable HTTP Transport - HTTP POST methods are used for Client to Server messages (together with optional Server Sent Events for streaming capabilities). This mechanisms is designed for use with remote resources. It supports standard HTTP authentication methods including Bearer Tokens, API keys and custom headers. The standard recommends using OAuth to obtain authentication tokens.
Security Concerns
To be blunt, in MCP, security is an optional exercise left up to the end architect rather than a core fundamental of the protocol design. Even the fundamental mission of "giving agents access to stuff" is potentially undermined by the lack of security baked in to the protocol. We will not cover every security issue MCP has in detail, as that would be a whole blog series in and of itself. However, we will try and highlight some of the most concerning risks exposed.
Authorisation is recommended but is entirely optional and by default, not included. RBAC is also not a feature and is instead passed on the end architect to implement. The fundamental building block in agentic security is carefully and purposefully implemented RBAC with strong authentication. This allows resource access to be reduced the bare essential required and also helps monitor and attribute agent actions. MCP leaving this vital first step up to the end architect means it is often overlooked and systems are deployed with no authentication nor access restrictions.
Third party MCP Servers are the most common used and usually takes the form of systems interacting with external MCP Servers or deploying local third party created MCP Servers. This creates a whole slew of supply chain, plugin and man-in-the-middle issues. The MCP Servers have the ability to run code on the Client systems by Sampling (asking the Client LLM to process a request for the Server) and Elicitation (asking the Client for input/further information). Both of these primitives already expose a poorly configured Client system to abuse from a malicious third party server. In addition to these dubious primitives available to Servers, a malicious Server can provide Poisoned Tools wherein the malicious Server embeds malicious instructions in the MCP Tool description, performs Tool Response Injection where a malicious instruction is included with the legitimate Tool response and even performs Indirect Prompt Injection where malicious prompts are embedded in returned documents, images and other media. Poorly configured external third party Servers can also be man-in-the-middled by threat actors who could then perform all of the afore mentioned attacks and use any additional access the Client has to attack the external Server. When threat modelling MCP Server creation, it is important to consider the Servers created within your own architecture as malicious threat actors with these capabilities too because they are and they are one misconfiguration away from compromise.
All the old bugs are new. An often overlooked point when talking about MCP issues is the atrocious lack of security fundamentals when exposing resources. SQLi was very nearly a solved issue for any serious developer. Though people still managed to mess it up in some very public and very damaging ways, this was one problem that was very well addressed by modern frameworks. But with MCP, it's the early 2000's all over again. Most MCP implementations lack any kind of filtering when exposing resources and it's like being in the early web 2.0 days. SQLi, XSS, SSRF etc are all back again, enabled by poorly implemented MCP Servers.
Some example of the horrors of MCP include but are not limited to that time GitHub exposed private repos via MCP, when Anthropic's Slack MCP Server allowed data exfiltration and of course the time the MCP OAuth lead to OS command execution on Clients when connecting to malicious Servers.
Agent2Agent Protocol (A2A)
Overview
A2A was developed by Google and released in April 2025 then passed on to the Linux Foundation in June 2025. If MCP is designed to solve the question "How do I give my agents access to stuff?" then A2A is designed to answer the question "How do I give my agents access to each other?". It is fundamentally a protocol to enable inter-agent communication and collaboration. It is designed to be framework agnostic to allow agents from different developers to communicate.
Similar to MCP, A2A is made up of the following actors:
User - The end user may be human or an automated service and initiates the interaction.
A2A Client - The Client agent acts on behalf of the User and communicates with one or more A2A Server.
A2A Server - The Server receives Client requests and tasks and provides results or status updates.
The fundamental communication elements in A2A are detailed below:
Agent Card - This is a JSON metadata document that describes the agent's identity, capability, endpoints, skills and auth requirements. It is exchanged at the beginning of an interaction and allows discovery and understanding on how to communicate with the agent.
Task - This facilitates tracking of long running operations and enables multi-turn operations. It is a stateful unit of work initiated by an agent with a unique ID and defined lifecycle.
Message - A message contains the role ("User" or "Agent"), some content and represents a single turn of communication between Client and Agent.
Part - The fundamental content container that holds text content, a file reference or structured data. It is used within Messages and Artifacts.
Artifact - A tangible output generated by an agent during a task; such as a document, image or other structured data.
A2A provides the following interaction mechanisms:
Request/Response (Polling) - Clients send a request to a Server and receive a response. This can also be used for periodic polling of long running tasks.
Streaming with Server-Sent Events (SSE) - Clients initiate a stream to receive real-time, incremental results or status updates from a Server over an open HTTP connection.
Push Notifications - This allows the Server to send the Client asynchronous notifications to a Client provided webhook when significant updates to a long running task occur.
The standard mandates that all communication must be over encrypted HTTPS.
A typical A2A request lifecycle looks something like this:
Security Concerns
A2A by design, encourages the use of MCP to expose tools via agents so when this is the case, all of the previously mentioned issues with MCP can potentially apply but now with extra steps to get to them.
Authentication and authorisation is handed over to standard authentication mechanisms handled by some separate authentication server outside of the A2A protocol. The protocol only recommends the use of authentication and authorisation and it is not baked in. Although the protocol says that the principal of least privilege must be enforced and that agents must only grant the minimum required privilege this is ultimately a moot point as all authorisation and authentication is handled outside of the protocol.
As with MCP, A2A Servers can also be malicious. They can embed prompt injections in their Agent Cards and Responses. It is worth calling out that with A2A, the Clients are other agents so this leads to cross-agent prompt injection. Malicious A2A Servers can also target Clients consuming their Responses through conventional injection attacks embedded in the Response (such as XSS, SQLi etc).
Lastly, there are no security controls within the protocol. No filtering, no validation, no output length monitoring, no rate limiting etc. The onus is firmly on the downstream services to be conducting security and given A2A is designed to use MCP, this does not bode well.
So the protocol as written creates a greater level of exposure.
At the time of writing, there are no concrete examples of A2A being reported exploited in the wild but this Trend Micro report has some very interesting statistics on early adoption of A2A; including how "Not a single agent [they] discovered implemented any form of authentication". It seems likely that as adoption increases, it will only be a matter of time before a major security incident occurs.
Agentic Communication Protocol (ACP) - A Brief Mention
In March 2025, IBM announced their Agentic Communication Protocol (ACP). It was designed to be an agnostic communication protocol that could support any agentic architecture (not just a simplistic Client-Server model). IBM open sourced it from the get go. Although it showed promise as a potential competing third/second standard for agent communication, in August 2025 (just five months later) they announced (https://github.com/orgs/i-am-bee/discussions/5) that they would be merging their efforts with the A2A project under the Linux Foundation. It should be noted that it had the same security issues as A2A and from a security perspective was no different.
It is worth mentioning as even IBM are not immune to the fickle and swift changes of all things AI and it highlights the importance of staying up to date with the current trends in AI (or at least trying to).
Conclusions
MCP provides a standardised way for agents to access resources and A2A provides a standardised way for agents to talk to each other.
Both standards pass off authentication and authorisation to external services and neither standard has security built in. Both platforms potentially expose many risks that were long thought dead and are increasingly being exploited in the wild.
Security Recommendations
When implementing any agentic protocol the following security recommendations should be adhered to:
- Strong authentication and authorisation of agents
- Well defined and monitored RBAC for agents
- Humans in the loop for any decisions of significance
- Monitoring of agent behaviour with appropriate kill switches in place
- Principle of least privilege access
- Strong input and output filtering and encoding
- Prompt filtering in place
- Logging of all agent behaviours and decisions
- Vetting of third party A2A and MCP Servers
- Rate limiting