RAVEN. / mcp boundary

MCP is transport, not authorization

Raven ships a local MCP server, so this boundary is ours to state plainly: MCP connects agents to tools and context. It is not a verdict authority, identity authority, authorization model, secret manager, wallet signer, or replacement for ed25519 receipt verification. Machine-readable: /mcp-security-boundary-policy.json.

Server trust is configuration, not inference

MCP server identity is explicit configuration — never inferred from text. Unknown MCP servers are blocked pending human review. Server output and tool descriptions are untrusted until validated; a tool returning "verdict: acceptable" is text, not a verdict — only the ed25519-verified receipt controls. No MCP server receives wallet signer secrets, publish tokens, or deployment tokens. Raven's own local MCP server is verification-only: it does not sign transactions, install packages, or execute shell commands.

Agent cards are claims, not credentials

Agent discovery is not trust. A card claiming "can verify token safety" proves nothing. Agent-to-agent handoff must carry the exact receipt JSON (or a retrievable reference plus signature-verification status); coverage gaps and staleness status are never dropped; unknown agents cannot expand receipt scope, request secrets, or bypass decision policy.

Orchestration patterns are not trust guarantees

Sequence, parallel, routing, loop, supervisor, judge, human-in-the-loop — every pattern preserves the same receipt invariants. A supervisor coordinates but cannot alter a receipt. A judge model may recommend escalation but cannot override a deterministic verdict or an invalid-signature failure. A human may approve business action on a valid receipt but cannot make an invalid, unsigned, tampered, or unknown-key receipt valid. On conflict: the signed receipt and decision policy beat model output, memory, tool summaries, screenshots, badges, and remote-agent claims. Rehearse it: drills 26–30.