MCP and A2A security

Reviewed against the linked protocol documentation on October 3, 2026.

An AI agent may need a tool to read a repository, then ask another agent to review a finding. MCP can provide the tool connection; A2A can carry the request between agents. Neither protocol decides on its own who may access the repository or which credential the second agent should use. Those decisions belong to the applications and services you deploy.

What each protocol connects

Model Context Protocol (MCP) gives an application a standard way to discover and call tools, read resources, and use prompts exposed by an MCP server. A server might offer a repository search tool, for example. The host and server still need to decide how to authenticate the caller and authorize each operation. A tool being available through MCP does not make its output trustworthy or its permissions safe.

Agent2Agent (A2A) lets one agent send tasks to another, potentially across organizations or frameworks. A remote agent publishes an Agent Card describing its endpoint, capabilities, and supported authentication schemes. The client obtains credentials separately and uses them when it calls the agent. The card should not contain secret keys.

These protocols can work together: an agent receives a task over A2A and uses an MCP tool to carry it out. Google describes them as complementary. Their security controls are implementation choices, so comparing one protocol as inherently “more secure” than the other misses the actual trust boundaries.

Follow the credential through the workflow

Consider an agent that asks a second agent to check a code repository. There are at least three access decisions: who may call the remote agent, who may invoke its MCP tool, and what that tool may do with the repository provider. A token for one audience should not simply be forwarded to the next service. The MCP security guidance explicitly warns against token passthrough; each service should validate the credential intended for it.

Map those decisions before enabling the workflow. Record the credential owner, issuing service, audience, scopes, storage location, expiry, rotation path, and what happens when access is revoked. Give read-only tasks read-only permissions. A user approving an agent action does not replace authorization at the tool or downstream API.

Treat tool descriptions, retrieved documents, Agent Cards, and task output as data from separate trust boundaries. If hostile text inside a repository asks an agent to reveal a key, the application must not treat that text as a higher-priority instruction. Review the server and agent endpoints you connect, limit sensitive actions, and keep logs that identify the actor and the credential used without recording the secret itself.

A practical review before production

1. Inventory the MCP servers, A2A agents, and downstream APIs involved in each workflow. Name an owner for every credential.

2. Verify authentication at each hop, including the audience and scope of bearer tokens. Test denial and revocation, not only a successful call.

3. Keep long-lived keys out of prompts, tool descriptions, Agent Cards, logs, and source code. Prefer short-lived, narrowly scoped access where the service supports it.

4. Review tool output and external task content as untrusted input. Require explicit approval for sensitive writes or exports.

5. Monitor for exposed credentials and rotate any verified exposure at the issuing service.

Where Cremit fits

Cremit helps teams find exposed credentials in supported connected sources and external exposure surfaces, verify supported credential types, and route findings to an owner for remediation. It does not currently assess an MCP server’s runtime authorization policy or certify that an A2A agent is safe. Exposure discovery is one part of the review above; the application and identity teams still own access policy, token lifecycle, and runtime controls.