CONSENT_DESIGN.md

Consent Design — Cross-Machine Agent Handoff

Wire is a transport. It moves signed events between agents and keeps the relay too dumb to read or authorize their contents. That boundary is useful, but it does not solve the harder question that appears as soon as an agent asks a different machine's agent to do work: who consented to the second hop, and what authority did they consent to?

This design note captures the trade-space surfaced by the agent-attention incident report in docs/history/INCIDENT_REPORT_2026_05_12_AGENT_ATTENTION_LAYER.md. It is not a claim that wire v0.5 solves consent. It documents where wire sits today and what would change that stance.

Problem Statement

MCP-style local tools assume the consent boundary is the host runtime: a human approved this agent, on this machine, with this set of tools. Cross-machine handoff breaks that neat box. If agent A sends agent B an instruction that implies tool use, agent B needs one of three things:

• Ask its own human every time. This is safe but can become UX dead air.
• Verify a pre-signed delegation token from agent A's operator. This moves consent into a portable credential.
• Consult receiver-side policy. This keeps consent local to B's operator and treats sender intent as an advisory input.

Wire v0.5 transports messages and identity material, but it does not decide what a receiving agent may execute.

Three Axes

Transport is the delivery lane: relay slots, signed events, cursors, deadlines, and health metadata. Wire owns this layer.

Identity is the answer to "which agent/operator produced this event?" Wire ships Ed25519-backed DIDs, signed agent cards, handles, and trust pins, but identity does not automatically imply permission.

Consent is the answer to "may this request cause action here?" Wire treats this as separable from both transport and identity. A verified peer can still ask for something your local policy denies.

Pattern 1: Scoped Delegation Tokens

The sender-side pattern is macaroon-like scoped delegation. An operator signs a token that says something close to:

{
  "agent_a": "did:wire:paul-...",
  "agent_b": "did:wire:willard-...",
  "kinds": [1000, 1002],
  "ttl": "24h",
  "auto_execute_max": "5/hour"
}

The token rides in or beside the event envelope. The receiver verifies the signature, checks caveats such as sender, recipient, kind, expiry, and rate, and then decides whether the token is enough to skip asking its human.

This is attractive when cross-org delegation becomes routine and multiple implementations need the same portable format. It also has costs: it expands the wire envelope's semantics, creates revocation questions, and tempts relays or middleware to understand authority rather than merely move ciphertext.

Pattern 2: Receiver-Side Policy

The receiver-side pattern keeps authority local. A sender may include an advisory requested_authority hint, such as "reply-only", "read-docs", or "run-tests". The receiving agent then consults local policy:

{
  "peers": {
    "did:wire:paul-*": {
      "decision": "auto",
      "kinds": [1000, 1002],
      "max_per_hour": 5
    }
  },
  "default": "ask"
}

The sender's hint is not authority. It is input to the receiver's policy engine. This keeps the relay ciphertext-only, keeps the protocol small, and lets each operator express local risk tolerance without waiting for a global consent format.

Wire v0.5 Stance

Wire v0.5 chooses receiver-side policy as the direction of travel. The relay stays a mailbox, not a consent oracle. Events remain signed transport objects, not executable permissions. Identity and transport are standardized enough to interoperate; consent is deliberately left to the receiving runtime.

The v0.5.9 time_sensitive_until field is an example of the sort of advisory metadata wire is willing to carry: useful to the receiver, covered by the event signature, and not itself an execution grant.

Wire v0.5.9 does not implement requested_authority or receiver-side policy enforcement. That belongs in v0.6 after the operator UX is clearer.

Speculative Scaffold

The standalone src/macaroon.rs module sketches the macaroon-style path as a research artifact: mint, verify, serialize, and deserialize a scoped token with sender, recipient, kind, expiry, and max-rate caveats. It is not used by the relay, CLI, or event envelope in v0.5.9. Its job is to make the alternative concrete enough to evaluate later without changing production consent behavior.

What Would Change This

Macaroon-style delegation should move from alternative to primary if more than one external project needs portable cross-org authority, or if receiver-side policy starts producing incompatible local dialects that block interop. The trigger is repeated real integration pressure, not theoretical neatness.

Until then, the safer default is: wire carries signed requests; the receiver decides what those requests may do.