MCP and A2A in AI Agent Protocols — Security considerations (I)
Intro
With the growing adoption of LLM-based agents across industries, there’s a growing need for standardized communication and security guidelines — both between agents and external tools/data and among agents themselves.
AI agents are advanced systems capable of generating complex textual outputs requiring sequential reasoning. They demonstrate capabilities such as forward-looking planning, maintaining contextual memory of past interactions, and employing external tools to dynamically adapt responses according to situational demands and desired communication styles.
Protocols can be divided into context-oriented and inter-agent types
- Context-Oriented Protocols (like MCP) — for agent-to-resource interaction
- Inter-Agent Protocols (like A2A) — for agent-to-agent communication
From an IT Security perspective, designing and deploying AI agents using MCP (Model Context Protocol) or A2A (Agent-to-Agent Protocol) introduces critical risks that must be addressed early in the architecture. From authentication & authorization to data privacy, secure execution and isolation, least privilege principles, auditability and logging, etc.
(A good resource for AI agent protocols can be found here)
MCP vs A2A
Model Context Protocol (MCP) — Context-Oriented
MCP was developed by Anthropic and enables LLM agents to reliably interact with external tools, data, and services.
MCP aims at standardizing tool invocation across LLMs and resources (e.g., APIs, databases, file system, etc.). As part of its architecture, it uses a Host–Client–Server–Resource model, where:
- Host: The LLM agent
- Client: Describes available tools/resources
- Server: Interfaces with actual tools/services
- Resource: The actual API/data/service
Agent-to-Agent Protocol (A2A) — Inter-Agent
Developed by Google with the purpose of enabling structured, secure, and interoperable collaboration between multiple agents.
Due to this interoperability design, A2A protocols rely on HTTP + JSON-RPC 2.0 + SSE for real-time communication, ensuring cross-vendor compatibility in distributed systems (Multi-agent collaboration in complex environments). From this perspective, it’s used in scenarios involving negotiation, delegation, or task chaining.
It’s imporetant to highlight that MCP and A2A are complementary, not competing. For example, a tool in MCP could itself be a high-autonomy agent speaking A2A. Future architectures may merge context-oriented and inter-agent designs into layered, hybrid agent ecosystems.
MCP Architecture
In an MCP (Model Context Protocol) server, there are three core primitives that define how the server can interact with clients:
Prompts : Prompts are reusable, parameterized text templates that can be invoked by clients. They serve as a way to package domain-specific knowledge or instructions that the server can provide to language models. For example, a prompt might be a code review template, a writing style guide, or a specific analysis framework. Prompts can accept parameters to customize their output, making them flexible building blocks for various tasks.
Resources: Resources represent data or content that the server can provide access to. These could be files, database records, API responses, or any other structured information that might be relevant to a language model’s task. Resources are typically read-only from the client’s perspective and can be referenced by URI-like identifiers. They allow MCP servers to expose their data in a standardized way that clients can discover and consume.
Tools: Tools are functions that the server exposes for clients to invoke. Unlike resources (which are passive data) or prompts (which are templates), tools represent active capabilities — they can perform actions, make API calls, run computations, or interact with external systems. Tools define their input schema and can return structured results. They’re the primary mechanism for giving language models the ability to take actions through the MCP server.
These three primitives work together to create a comprehensive interface: prompts provide instructions and context, resources supply relevant data, and tools enable actions.
This architecture allows MCP servers to expose rich, domain-specific capabilities while maintaining a clean separation between different types of functionality.
Beyond these “primitives” part of MCP, there are some important architectural components and protocol layers that are worth understanding in the broader MCP ecosystem, and relevant from a security perspective
Transport Layer
MCP operates over various transport mechanisms — typically stdio (standard input/output) for local processes, or WebSocket/HTTP for network-based servers. This isn’t a primitive per se, but it’s how the protocol messages actually flow.
Client-Server Architecture
The MCP client (usually embedded in an AI application) communicates with MCP servers (which expose the primitives). This architectural pattern is fundamental to how MCP works, even though it’s not a primitive itself.
Protocol Messages
The underlying JSON-RPC message format that carries requests and responses between clients and servers. This includes initialization, capability negotiation, and the actual primitive invocations.
Capability Negotiation
During connection establishment, clients and servers negotiate which capabilities they support — essentially discovering what prompts, resources, and tools are available.
Session Management
The lifecycle of MCP connections, including authentication, initialization, and graceful shutdown.
So, while Prompts, Resources, and Tools are the complete set of functional primitives that MCP defines, the full MCP specification includes these additional architectural and protocol elements that make those primitives work in practice.
In the next article
MCP client/server deployment and:
- Authentication and Access Control (including OAUTH)
- Input Validation and Output Sanitization (Prompt Injection and Tool Poisoning Prevention /Tool Description Hardening)
- Server Trust and Verification
- Credential and Data ProtectionRate Limiting and Resource Controls
- Monitoring and Logging
Need Help?
The functionality discussed in this post, and so much more, are available via the SOCFortress platform. Let SOCFortress help you and your team keep your infrastructure secure.
Website: https://www.socfortress.co/
Contact Us: https://www.socfortress.co/contact_form.html
