MCP and A2A without losing architectural control

Enterprise AI is moving from a standalone model toward systems that retrieve information, call business services, coordinate specialized agents, and run multi-step work across team boundaries. Two protocols cover different parts of that problem. The Model Context Protocol (MCP) is a standard way for an AI application to reach tools, resources, and contextual information. Agent2Agent (A2A) is a way for independent agents to discover capabilities and collaborate.

They complement each other. Protocol interoperability still leaves identity, authorization, trust boundaries, execution policy, state, and audit to the surrounding architecture.

Different boundaries

MCP tools are operations an application can request, such as retrieving a claim summary or opening a support ticket. Resources are data the application can read through the protocol. Prompts are reusable templates a server exposes. A client discovers and invokes those capabilities through a defined exchange. MCP reduces the need for every application to invent its own integration. It does not, by itself, make a tool safe, confirm that this user may call it, or guarantee the business transaction.

A2A is for agents that may use different frameworks, models, or runtimes. One agent can discover another’s advertised capabilities, often through an Agent Card, delegate a task, exchange structured messages, and track states such as submitted, working, input required, completed, or failed, depending on the protocol version. That enables interoperability. It does not establish that the discovered agent is trustworthy, that its output is correct, or that the action it requests should be allowed.

A claims agent might use MCP to read claim documents and call an internal validation service. If a separate fraud-analysis agent should do the specialist work, the orchestration layer can use A2A to delegate that analysis. The specialist uses its own authorized tools and returns findings. The requesting workflow validates the result and decides the next permitted action. The platform still owns the rules.

A reference shape

A production layout separates reasoning, protocol connectivity, policy, and business execution.

The entry layer authenticates the user or application, validates input, sets tenant context, issues a correlation id, and applies rate limits. Identity is established before the agent runtime starts.

The runtime plans the task, selects models, assembles context, keeps workflow state, handles retry and cancellation, delegates through A2A, and requests capabilities through MCP. A model-generated decision is an input to execution. It is not an authorization decision.

The MCP layer discovers servers, validates input schemas, normalizes responses, and keeps transport secure. Prefer a narrow operation, such as retrieve_claim_summary, over open database access. The underlying service still enforces its own authorization.

The A2A layer verifies endpoints, checks Agent Cards, tracks tasks, restricts where work may be sent, and validates what comes back. A discovered agent is not automatically a trusted target. Identity, ownership, and the data you are allowed to share have to be evaluated.

The control plane evaluates identity-aware policy, role- and attribute-based access, capability allowlists, data classification, risk-based approval, budgets, and audit evidence. Re-evaluate when the context changes or the operation becomes more consequential. Do not rely on a check that happened only when the agent started.

Enterprise systems of record, such as CRM, claims, ledgers, and payment services, keep their own authentication, authorization, and transaction rules. The control plane adds protection. It does not replace those systems.

Identity across the hop

Distinguish at least three identities: the principal who started the workflow, the workload identity of the agent performing a protocol operation, and the target service or remote agent receiving the request. Delegation must not increase privilege.

Forwarding a user’s token to every downstream agent is a weak delegation strategy. Prefer narrowly scoped, audience-restricted credentials, and record the principal, the workload, the delegated scope, the audience, the expiry, and the policy decision that allowed the hop. A receiving service should validate credentials itself.

Each boundary, from user to runtime, runtime to MCP server, agent to agent, agent to a third party, and cloud to an on-premises system, needs its own authentication, data-flow rules, and audit. A2A connectivity between organizations is not implicit trust.

A confused deputy appears when a privileged service uses its own authority to do something the caller was not allowed to ask for. A support agent with broad database access that accepts an arbitrary customer id from a prompt can cross customer boundaries. Constrain the tool, bind the tenant, and check policy close to the operation.

Discovery is not approval

An MCP tool list and an A2A Agent Card describe interfaces. They are not credentials. An enterprise registry can record the capability id, owner, environment, protocol version, schemas, data classification, approved consumers, risk, and review date. The registry governs discovery. Enforcement may sit in a gateway, a policy-aware runtime, the MCP server, the target service, or more than one of those.

Keep three stages separate. Discovery finds the interface. Selection picks a capability that fits the task. Authorization decides whether this caller may use it for this operation under current policy. Read access and a state-changing call are different permissions.

From a tool request to an authorized action

A practical policy outcome is allow, allow with controls, require a person’s approval, or deny. Base that on the operation and its context, not on the agent’s name.

The safer path is: the agent proposes a typed action, the runtime checks the schema, the control plane evaluates principal, workload, resource, and risk, any required approval is completed, the execution component calls the operation, and the target service applies its own rules. Bind approval to the specific action and its material parameters. If those parameters change, decide whether authorization has to be evaluated again.

A timeout does not prove the downstream operation failed. The service may have committed the change. State-changing calls need idempotency keys, deduplication, and reconciliation. A general approval of an agent’s task does not authorize every later operation that agent might propose.

Treat retrieved documents, tool results, and agent messages as untrusted input. Separate trusted instructions from retrieved content, validate outputs, and keep resource-level authorization independent of arguments the model generated. Before sending work to another agent, decide whether it needs the whole document, a few fields, a summary, or a redacted form.

Use secure transport, validated endpoints, managed secrets, and the security requirements of the MCP and A2A versions you actually run. Test malicious tool descriptions, spoofed agent endpoints, unauthorized delegation, replay, cross-tenant access, and policy bypass. Conformance is not a substitute for threat modeling.

Operations

A useful trace includes the correlation id, the principal and workload identities, model and agent versions, discovery and selection, MCP tool names and outcomes, A2A targets and task ids, policy decisions and policy versions, approvals, state transitions, retries, and cost. Distinguish what the agent proposed, what the platform authorized, and what the target system confirmed. Leave sensitive payloads out of general logs.

Extra agents add latency and failure points. Set a budget for the whole workflow. Parallelize only when the data dependencies and the security constraints allow it. Skip a delegation when a direct deterministic call is enough. Limit depth, retry with backoff, and protect failing dependencies. For each step, know whether it is read-only, reversible, or an irreversible business effect. Do not retry a state-changing call until you know whether it committed.

Measure end-to-end latency at the 95th and 99th percentiles, task completion, tool failures, delegation success, policy denials, approval turnaround, duplicate operations, cost per successful outcome, and whether audit events can be correlated. Set the targets from the business requirement, under realistic load.

Mistakes that show up as the system grows

Using MCP and A2A as if they were interchangeable. Treating a discovered capability as approved. Giving every agent broad shared credentials. Relying on the prompt as the access control. Trusting a remote agent’s response without a check that matches the risk. Assuming one gateway means downstream services no longer need authorization. Logging only the final response. Ignoring protocol and schema change. Treating a human approval as cover for a later, different action. Confusing a successful message exchange with a correct business result.

Introduce the controls with the connectivity. Start from the workflows, the data classes, and the trust boundaries. Begin with a small set of capabilities, read-only where you can. Add policy at the execution boundary and keep the target system’s own checks. Instrument the path so a representative workflow can be reconstructed without retaining sensitive payloads. Add agents when ownership, review, and measured reliability support it.

The objective is collaboration inside boundaries you can enforce and explain.