The Secure Agent Delegation Protocol (SADP): End-to-End Encrypted Task Capsules for AI Agent Systems

1.1. Problem Statement

Agentic AI systems increasingly move sensitive data and authority through long chains of intermediaries: a user's device talks to a personal agent, which delegates to specialist agents, which invoke tools, all mediated by orchestration servers, brokers, queues, model gateways, and logging layers. In deployed systems today, each of those intermediaries typically sees task plaintext. Transport security protects individual hops, but the orchestration layer itself operates on cleartext prompts, documents, tool arguments, and results. That layer includes the broker that stores and forwards messages, the gateway that logs requests, and the framework that schedules agents.¶

That default is a poor fit for legal, medical, financial, government, and enterprise workflows, and it is an increasingly poor fit for personal assistants that hold long-lived user memory. The current generation of agent interoperability protocols reflects this gap: the A2A protocol [A2A] secures hops with TLS and delegates authorization to server-side policy, and the Model Context Protocol [MCP] adopts an OAuth 2.1 resource-server model for tool access. Neither provides end-to-end confidentiality of task content across an untrusted intermediary, and neither binds a task's authorization to the encrypted object that carries it.¶

SADP addresses the confidentiality half of this problem. It defines an encrypted, signed, individually routable protocol object, the task capsule, together with the session, ratchet, and broker machinery needed to deliver capsules asynchronously between principals that may be offline, may run on multiple runtimes, and may never share a direct network path. The authorization half consists of capability grants, attenuated delegation chains, and cryptographically scoped context disclosure. It is specified in the companion document [I-D.atakora-wimse-sadp-delegation].¶

1.2. Protocol Maturity and Naming

This revision is intended for experimentation and review. Neither this specification nor its reference implementation has received independent external cryptographic review, and the wire format is expected to change as interoperability tests and formal analysis identify necessary repairs. Deployments MUST treat the v0.2 profiles as experimental.¶

The acronym SADP has appeared previously in IETF work for the unrelated Scoped Address Discovery Protocol [I-D.ietf-mboned-sadp]. This document uses SADP for the Secure Agent Delegation Protocol; the two protocols are unrelated. A future publication path may choose a less ambiguous short name if that avoids confusion in IETF registries or discussion.¶

1.3. Design Goals

SADP is designed to provide:¶

• Confidentiality of task payloads, tool arguments, context, and results from brokers, queues, gateways, logs, and unrelated runtimes.¶

• Integrity and authenticity of capsule headers, payloads, and registry material.¶

• Asynchronous, offline-capable session establishment using signed prekey bundles, following the design pioneered by X3DH [X3DH].¶

• Per-message forward secrecy and post-compromise recovery through a message ratchet derived from the Double Ratchet algorithm [DOUBLERATCHET].¶

• An optional hybrid post-quantum key-agreement profile combining X25519 [RFC7748] with ML-KEM-768 [FIPS203], following the hybrid approach of PQXDH [PQXDH].¶

• Multi-runtime agent identity, treating each runtime of an agent like a device in multi-device secure messaging [SESAME].¶

• An authenticated broker profile in which the broker routes and stores opaque capsule bytes, authenticates requests by digital signature, and enforces mailbox ownership without access to plaintext.¶

• Transport agnosticism: SADP objects are self-contained and can be carried over HTTP, WebSocket, message queues, or as opaque payloads inside A2A messages and MCP tool calls.¶

SADP explicitly does not attempt to provide anonymous or metadata-resistant routing, protection against a compromised endpoint after decryption, model-behavior safety, or a global identity governance framework. Section 14 discusses these boundaries.¶

1.4. Relationship to A2A, MCP, and Agent Transports

SADP is a layer, not a replacement. A2A [A2A] defines agent discovery, agent cards, and task exchange between agent servers; MCP [MCP] defines tool and resource access for model applications. Both can carry SADP capsules as opaque payloads. When they do, the A2A server or MCP host retains its routing and lifecycle role but loses visibility into task content; only the intended recipient principal can decrypt. Similarly, an ordinary message queue or mailbox service can act as an SADP broker with no knowledge of the protocol beyond byte storage, and a conforming SADP broker (Section 10) adds authenticated mailboxes, registry services, and receipts.¶

1.5. Relationship to Prior Work

SADP deliberately composes established cryptographic constructions rather than inventing new ones, and this document credits those constructions at the point of use. The asynchronous prekey handshake derives from X3DH [X3DH]; the message ratchet derives from the Double Ratchet [DOUBLERATCHET]; the hybrid post-quantum profile follows PQXDH [PQXDH] and the subsequent post-quantum ratchet work [SPQR]; the multi-runtime model follows Sesame [SESAME]. The capability lineage in the companion document builds on Macaroons [MACAROONS], Biscuit [BISCUIT], and UCAN [UCAN], and its on-behalf-of semantics relate to OAuth 2.0 Token Exchange [RFC8693] and GNAP [RFC9635].¶

Adjacent protocol work exists and predates this document. [I-D.chapman-a2a-mls] applies MLS [RFC9420] to A2A messages with purpose binding; the AGNTCY SLIM project [SLIM] provides an MLS-based encrypted session layer as an agent transport; [I-D.asor-wimse-agent-delegation-chain] defines verifiable attenuated delegation tokens for agent chains without an encryption layer; [I-D.hamr-oauth-agent-delegation] defines an HTTP header profile for attenuated cross-domain agent delegation; [I-D.liu-oauth-chain-delegation] defines OAuth-based chained delegation tokens for agent identities; [I-D.li-oauth-delegated-authorization] defines constrained client-issued delegated authorization tokens; [I-D.singla-agent-identity-protocol] defines decentralized identity and capability delegation for agents; [I-D.vandoulas-aidp] defines a control-plane model for intent, authority, execution, and observation; [I-D.nelson-agent-delegation-receipts] defines user-signed, log-anchored delegation receipts; [I-D.sharif-attp] specifies an agent trust transport framework for trust scoring and action-limit enforcement; and [I-D.sharif-agent-transport-protocol] specifies an asynchronous store-and-forward agent transport. Academic proposals address authenticated delegation [SOUTH2025] and multi-agent governance [SAGA2025].¶

What SADP contributes relative to that work is object-level rather than channel-level end-to-end encryption. The unit of protection is an individually signed, individually routable task capsule that survives store-and-forward delivery through arbitrary intermediaries, composed with capability-bound authorization and payload-blind audit commitments in one protocol. In the v0.2 profile, task and context payloads are encrypted end-to-end, while capability grants and audit records are authenticated outer capsule fields that may reveal delegation metadata to brokers that store the full capsule. A future private-delegation-evidence profile is expected to move grants and detailed audit records inside an encrypted inner body while leaving only public commitments in the outer capsule. Group-channel approaches such as MLS excel when a stable group of participants shares a conversation; SADP targets the delegation topology, where each hop is a distinct pairwise relationship with distinct authority, and where a task object must remain verifiable and confidential as it is queued, retried, and re-routed.¶

1.6. Document Organization

This document specifies the SADP data model (Section 5, Section 6), session establishment (Section 7), the message ratchet (Section 8), single-capsule payload profiles (Section 9), the opaque broker profile (Section 10), metadata privacy (Section 11), and transport carriage (Section 12). Capability grants, delegation chains, caveats, scoped context disclosure, and the audit hash chain are specified in [I-D.atakora-wimse-sadp-delegation]; this document defines only the capsule fields that carry them.¶

5.1. Canonical JSON

SADP structures are JSON [RFC8259] documents. Wherever this document requires canonical bytes, such as signing inputs and hash inputs, the canonical form is defined as:¶

• UTF-8 encoding;¶

• object member names sorted lexicographically by Unicode code point at every nesting level;¶

• no duplicate member names (parsers MUST reject duplicates);¶

• no insignificant whitespace;¶

• array order preserved;¶

• numbers restricted to integers within the IEEE-754 exact range.¶

This canonical form is a deliberately restricted profile compatible with the JSON Canonicalization Scheme [RFC8785]; implementations MAY use an RFC 8785 canonicalizer, provided the restrictions above are enforced on input.¶

5.2. Binary Values and Timestamps

Binary values are encoded as base64url without padding. Timestamps in human-facing document fields use RFC 3339 [RFC3339]; timestamps inside signing inputs and validation APIs use integer seconds since the Unix epoch, to keep canonical bytes unambiguous.¶

5.3. Hashing

All hashes in this document are SHA-256 [RFC6234] and are encoded as base64url without padding unless stated otherwise.¶

5.4. Unknown Fields and Criticality

Capsule headers carry a critical array naming top-level fields whose semantics a receiver must understand. A receiver MUST reject a capsule that lists a critical field the receiver does not implement, and MUST ignore unknown fields that are not listed as critical. This provides forward compatibility without silent security downgrade.¶

6.1. Capsule Header

Every capsule carries the following cleartext header fields:¶

{
  "version": "sadp/0.1",
  "type": "task_create",
  "capsule_id": "cap_01J00000000000000000000000",
  "task_id": "task_01J00000000000000000000000",
  "thread_id": "thread_01J00000000000000000000000",
  "turn_id": "turn_01J00000000000000000000000",
  "from": "user:alice/device:phone",
  "to": "agent:contract-reviewer/runtime:prod-a",
  "created_at": "2026-09-19T12:00:00Z",
  "expires_at": "2026-09-19T13:00:00Z",
  "critical": ["policy", "capabilities", "audit"]
}

version identifies the capsule envelope format. The envelope version is deliberately decoupled from cryptographic profile versions: the security profiles defined in this document carry "-v0.2" scheme identifiers inside an envelope whose format is unchanged from "sadp/0.1". capsule_id MUST be unique per sender; receivers and brokers use it for replay rejection and idempotency. expires_at is mandatory; receivers MUST reject expired capsules.¶

6.2. Message Types

The initial message-type registry (Section 15) contains:¶

session_init, session_repair, runtime_added, runtime_removed,
task_create, task_update, task_cancel, task_result,
delegate_create, delegate_result, tool_call, tool_result,
memory_read_request, memory_read_result,
memory_write_request, memory_write_result,
receipt, policy_violation

6.3. Capsule Body

Beyond the header, a capsule MAY carry:¶

policy:

Cleartext delegation policy hints (allowed delegatees, allowed and forbidden tools, retention). Policy fields are advisory routing metadata; enforcement derives from capability grants ([I-D.atakora-wimse-sadp-delegation]).¶

capabilities:

An array of signed capability grants, possibly chained. In v0.2 this field is an outer authenticated capsule field and may be visible to brokers that store the full capsule. Format and verification rules are specified in [I-D.atakora-wimse-sadp-delegation].¶

context_refs:

References to encrypted context blobs, carrying a resource identifier, content type, and an encrypted key reference; the key material is released only against valid capabilities.¶

audit (and, for delegation, parent_audit):

Hash-chain audit records binding the capsule to its delegation lineage. In v0.2 these records are outer authenticated capsule fields and may reveal lineage shape to brokers. They are specified in [I-D.atakora-wimse-sadp-delegation].¶

session_init:

A session-initiation envelope (Section 7.3), present on the first capsule of an edge.¶

encrypted_payload:

The encrypted task content: a ratchet message (Section 8) or a single-capsule AEAD payload (Section 9).¶

key_agreement:

Present with the pre-ratchet payload profile only (Section 9).¶

6.4. Capsule Validation Order

Receivers MUST validate in the following order, and MUST NOT release encrypted payload plaintext to application code before all applicable steps pass:¶

1. Parse with duplicate-key rejection.¶

2. Reject unsupported envelope versions.¶

3. Reject malformed principal identifiers.¶

4. Reject unknown critical fields.¶

5. Reject expired capsules.¶

6. Reject replayed capsule identifiers and, for ratchet messages, replayed message counters.¶

7. Verify signatures and authentication tags.¶

8. Verify capability chains: holder, resource, action, task binding, expiry, delegation depth, and caveats ([I-D.atakora-wimse-sadp-delegation]).¶

9. Verify audit parent linkage ([I-D.atakora-wimse-sadp-delegation]).¶

10. Decrypt the encrypted payload.¶

11. Release plaintext to the application.¶

Debug or inspection modes that bypass any step MUST be impossible to confuse with production validation (for example, distinct function names and distinct result types).¶

7.1. Prekey Bundles

Each registered runtime publishes a signed prekey bundle to the registry:¶

{
  "principal": "agent:contract-reviewer/runtime:prod-a",
  "subject": "agent:contract-reviewer",
  "runtime_id": "prod-a",
  "signing_public_key": "<base64url Ed25519>",
  "encryption_public_key": "<base64url X25519>",
  "ml_kem768_encapsulation_key": "<base64url ML-KEM-768 ek>",
  "prekey_id": "prekey_agent_a_1",
  "prekey_kind": "runtime_static",
  "scheme": "sadp-prekey-ed25519-v0.1",
  "created_at_epoch_seconds": 1789819200,
  "expires_at_epoch_seconds": 1789905600,
  "signature": "<base64url Ed25519>"
}

The signature is computed with the runtime's Ed25519 signing key over a domain-separated canonical encoding that binds every field above except signature. Registries MUST verify prekey signatures and expiry at publication and at lookup, and MUST reject tampered or expired bundles. The ml_kem768_encapsulation_key field is OPTIONAL and enables the hybrid profile of Section 7.6.¶

7.2. One-Time Prekeys

Runtimes SHOULD publish batches of signed one-time prekeys. Prekey selection prefers an unconsumed one-time prekey and falls back to the runtime-static prekey; a one-time prekey is consumed atomically at selection. Because consumption is a state change that an attacker could abuse to exhaust the supply, prekey lookup requires an authenticated request from a registered principal (Section 10.2). Runtimes can monitor inventory through the registry's inventory interface and MUST tolerate static-prekey fallback, as in [X3DH].¶

7.3. Session Initiation

The v0.2 session-initiation profile is identified by:¶

sadp-session-init-x25519-hkdf-sha256-v0.2

The initiator:¶

1. Fetches and verifies the responder's prekey bundle.¶

2. Generates a fresh ephemeral X25519 keypair.¶

3. Computes the Diffie-Hellman shared secret between its ephemeral private key and the responder's prekey.¶

4. If the bundle carries an ML-KEM-768 encapsulation key and local policy selects the hybrid suite, encapsulates to it (Section 7.6).¶

5. Builds the session transcript (Section 7.4).¶

6. Signs the transcript with its Ed25519 identity signing key.¶

7. Derives the session root key: HKDF-SHA256 [RFC5869] with the transcript as salt, the key-agreement output as input keying material, and the fixed info string "SADP session root v0.1". (Derivation labels are versioned independently of scheme identifiers and are unchanged from the prior profile revision.)¶

The session-initiation envelope is:¶

{
  "scheme": "sadp-session-init-x25519-hkdf-sha256-v0.2",
  "session_id": "<base64url SHA-256 of root key>",
  "initiator": "user:alice/device:phone",
  "responder": "agent:contract-reviewer/runtime:prod-a",
  "selected_prekey_id": "prekey_agent_a_1",
  "selected_prekey_kind": "runtime_static",
  "initiator_ephemeral_public_key": "<base64url X25519>",
  "responder_identity_public_key": "<base64url X25519>",
  "initiator_signing_public_key": "<base64url Ed25519>",
  "initiator_signature": "<base64url Ed25519>",
  "transcript_hash": "<base64url SHA-256>",
  "algorithm_suite": "x25519-hkdf-sha256+ml-kem-768",
  "pq_hybrid_scheme": "sadp-ml-kem-768-v0.1",
  "pq_kem_ciphertext": "<base64url ML-KEM-768 ct>",
  "repair_for_session_id": "<base64url prior session id>",
  "repair_epoch": 1
}

initiator_signing_public_key and initiator_signature are REQUIRED. The PQ fields and repair fields are OPTIONAL.¶

7.4. Session Transcript

The transcript is a text string: the line SADP session transcript v0.2, followed by one name:value line per field, in exactly this order:¶

scheme, initiator, responder, selected_prekey_id,
selected_prekey_kind, initiator_ephemeral_public_key,
responder_identity_public_key, initiator_signing_public_key,
algorithm_suite, pq_hybrid_scheme, pq_kem_ciphertext,
repair_for_session_id, repair_epoch

Absent optional fields contribute the literal value null. transcript_hash is the SHA-256 of the transcript string.¶

Because the algorithm suite and the ML-KEM ciphertext are inside the transcript, and the transcript is signed, an attacker who strips or alters the post-quantum component, substitutes a prekey, or replaces the ephemeral key invalidates the signature. This is the downgrade binding: no shared-secret material ever appears on the wire, and no commitment to shared-secret bytes is published. (An earlier profile revision published a hash commitment to the PQ shared secret; it has been removed because it added no binding beyond the signed ciphertext and turned ML-KEM implicit rejection into an observable decapsulation oracle.)¶

7.5. Initiator Authentication

initiator_signature is an Ed25519 signature over the byte string:¶

"SADP session init signature v0.2\n" || transcript

A responder MUST, before deriving any key material:¶

1. Recompute the transcript from the envelope fields and verify transcript_hash.¶

2. Verify initiator_signature against initiator_signing_public_key.¶

3. Bind the key to the claimed identity: a responder using a registry MUST resolve the registered signing key for the initiator principal and reject the envelope if it differs from initiator_signing_public_key. Deployments without a registry MUST surface the observed key to the application for explicit trust establishment; silent trust-on-first-use is NOT permitted as a library default.¶

The responder authenticates implicitly: only the holder of the private key matching the selected prekey (and, in the hybrid suite, the ML-KEM decapsulation key) can derive the root key and therefore read or produce ratchet traffic. This asymmetric design, with signature-based explicit authentication of the initiator and key-possession-based implicit authentication of the responder, parallels the deniability tradeoff discussion in [X3DH]; SADP chooses explicit initiator authentication because agent workflows require attributable task submission, and deniability is a non-goal.¶

7.6. Hybrid Post-Quantum Profile

The hybrid suite x25519-hkdf-sha256+ml-kem-768 follows the construction pattern of PQXDH [PQXDH]: the initiator encapsulates to the responder's ML-KEM-768 [FIPS203] encapsulation key, carries the ciphertext in pq_kem_ciphertext, and the root-key input keying material becomes the labeled concatenation:¶

"x25519:" || DH_shared_secret || ";pq:" || ML-KEM_shared_secret

Both components are fixed length, so the labeled concatenation is injective. The security goal is that an adversary must break both X25519 and ML-KEM-768 to recover the session root ("harvest-now-decrypt-later" resistance for recorded traffic). Post-quantum protection of the ratchet itself (as in [SPQR]) is out of scope for this revision and identified as future work.¶

7.7. Profile Negotiation and Downgrade Rules

Three session-start profiles exist: x25519 (no PQ fields) and x25519+ml-kem-768, plus a test-only profile that injects an external PQ secret on both sides for interoperability harnesses and MUST NOT be enabled in production. Rules:¶

• A sender MUST prefer the hybrid suite when the selected prekey bundle carries an ML-KEM encapsulation key, and MUST NOT silently downgrade; downgrade requires explicit local policy.¶

• The chosen algorithm_suite is bound in the signed transcript; responders MUST reject a suite inconsistent with the envelope's fields.¶

• Brokers are not negotiators: they store and serve prekey-bundle fields opaquely after signature validation.¶

7.8. Session Repair

When a runtime rotates keys or loses state, the initiator starts a replacement session whose envelope carries repair_for_session_id and repair_epoch, binding the replacement to the prior session inside the signed transcript. Responders SHOULD treat repair envelopes for unknown prior sessions as fresh sessions and MUST NOT allow a repair to resurrect a revoked runtime.¶

8.1. Session State

Session state is local-only and MUST NOT be transmitted through a broker. It comprises the role (initiator or responder), send and receive chain keys, per-direction chain anchors (the chain key at counter zero of the current DH epoch), send and receive counters, DH epoch counters for both directions, the local DH keypair, the last observed remote DH public key, and a bounded skipped-message-key cache.¶

8.2. Key Derivation

All derivations are HKDF-SHA256 [RFC5869], written below as HKDF(salt, IKM, info). BE64(x) is the 64-bit big-endian encoding of x. For a chain key CK, message counter n, and DH epoch e:¶

message_key(n) = HKDF(CK, BE64(n),
                      "SADP ratchet message key v0.1" || BE64(n))
next_chain_key = HKDF(CK, "next", "SADP ratchet next chain v0.1")
nonce(n)       = HKDF(message_key(n), BE64(n),
                      "SADP ratchet nonce v0.2")   (12 bytes)

A DH ratchet step at epoch e derives the new chain key from the current epoch's chain anchor CA (not the position-dependent current chain key, so both peers derive the same value regardless of how many messages each has processed) and the fresh X25519 shared secret ss:¶

chain_key(e) = HKDF("SADP DH ratchet step",
                    CA || ss || BE64(e),
                    "SADP DH ratchet chain v0.1")

The new chain key also becomes the new epoch's chain anchor. The AEAD is ChaCha20-Poly1305 [RFC8439]; because each message key is used for exactly one encryption, nonce uniqueness per key is structural. Implementations MUST use HKDF and HMAC from audited library implementations rather than reimplementations, and MUST zeroize chain keys, chain anchors, message keys, and DH private keys when they are discarded.¶

8.3. Message Format

{
  "scheme": "sadp-ratchet-hkdf-chacha20poly1305-v0.2",
  "session_id": "<base64url>",
  "dh_epoch": 1,
  "dh_public_key": "<base64url X25519>",
  "counter": 0,
  "nonce": "<base64url 12 bytes>",
  "ciphertext": "<base64url ciphertext || tag>"
}

8.4. Associated Data Binding

The AEAD associated data is:¶

caller_aad || "\n" ||
"sadp-ratchet-header-v0.2:" || session_id || ":" ||
dh_epoch || ":" || dh_public_key || ":" || counter

where caller_aad binds capsule metadata (at minimum thread, turn, from, and to), and an absent dh_public_key contributes the literal string null. Binding the ratchet header into the AAD makes header tampering detectable at AEAD verification rather than producing undefined state transitions.¶

8.5. Receiver Processing: Verify Before Commit

A receiver MUST process an incoming ratchet message against a working copy of session state and commit that state only after the AEAD opens successfully. A message that fails authentication MUST leave session state exactly as it was, including DH-epoch state and counters. This rule exists because an earlier revision applied the DH ratchet step before verification, allowing a single forged header to permanently desynchronize a session through an unauthenticated denial of service.¶

Receivers MUST reject replayed (dh_epoch, counter) pairs.¶

8.6. DH Ratchet Steps and Skipped Keys

Responders perform a send-side DH ratchet on their first reply. When a receiver observes a new remote dh_public_key, it first derives and caches message keys for the remaining expected counters of the current receive chain, so that legitimately delayed messages from the prior epoch remain decryptable, and then advances the receive chain to the new epoch. Skipped keys are cached keyed by (dh_epoch, counter), with a global bound of 64 entries; on overflow the oldest epoch is evicted first. Cached skipped keys MUST be zeroized on use or eviction.¶

10.1. Broker Role

A conforming broker MAY route capsule bytes by recipient mailbox, store them durably, return them in insertion order, delete by capsule identifier, and inspect the minimal envelope metadata needed for mailbox behavior. A broker MUST NOT decrypt payloads, mutate capsule bytes, log payload bytes, or require access to payload keys. The mailbox interface is:¶

POST   /mailboxes/{recipient}/capsules
GET    /mailboxes/{recipient}/capsules
DELETE /mailboxes/{recipient}/capsules/{capsule_id}
GET    /mailboxes/{recipient}/receipts
GET    /mailboxes/{recipient}/events
POST   /mailboxes/{recipient}/policy/send
GET    /mailboxes/{recipient}/policy/send
POST   /mailboxes/{recipient}/compact

together with registry endpoints for runtime registration, prekey lookup, one-time prekey publication and inventory, issuer-key lookup, and revocation.¶

10.2. Request Authentication

Authenticated broker requests carry:¶

X-SADP-Principal:  agent:contract-reviewer/runtime:prod-a
X-SADP-Request-Id: req_<base64url of 16 random bytes>
X-SADP-Timestamp:  <integer epoch seconds>
X-SADP-Audience:   <audience the client signed>
X-SADP-Signature:  <base64url Ed25519>

The signature scheme is sadp-request-ed25519-v0.2. The signing input is:¶

"SADP broker request v0.2\n" || canonical_json({
  "scheme": "sadp-request-ed25519-v0.2",
  "principal": principal,
  "method": method,
  "path": path,
  "request_id": request_id,
  "body_sha256": SHA-256(body),
  "timestamp_epoch_seconds": timestamp,
  "audience": audience
})

audience is the broker identifier as the client targets it: the lowercased scheme, host, and port of the request URL with no trailing slash. The client declares the audience it signed in the X-SADP-Audience field; a verifier MAY instead derive candidate audience values from the request URL it received. The broker verifies the signature against the registered signing key of the claimed principal and MUST reject requests whose audience does not match its own identity (configured explicitly or derived from the request URL). Binding the audience prevents a signed request captured at one broker from being replayed at another.¶

This design is deliberately similar in spirit to HTTP message signatures [RFC9421]; SADP uses its own canonical-JSON signing input so that identical logic can run over non-HTTP carriage (Section 12).¶

10.3. Replay Protection

Brokers MUST reject a request whose timestamp is more than 300 seconds from server time in either direction, and MUST reject a request whose request_id has been seen from the same principal within the retention window. The replay cache MUST retain identifiers for at least twice the timestamp window. request_id MUST be generated from at least 16 bytes of cryptographically secure randomness; derivation from request content is forbidden, because deterministic identifiers turn the replay cache into a false-negative generator for legitimately repeated operations and a false-positive oracle otherwise.¶

10.4. Registration and Proof of Possession

Runtime registration MUST prove possession of the submitted signing key: the registration record carries a prekey bundle whose signature is verified against the submitted signing key. A broker MUST apply the following state rules:¶

• Creating a new principal record requires proof of possession, and, where deployed, transport-level identity: with mutual TLS, the verified client-certificate leaf MUST carry a URI SAN of the form sadp-principal:<runtime-principal> matching the submitted principal.¶

• Updating an existing record, including publishing new prekeys or rotating keys, requires an authenticated request under the currently registered signing key, mutual-TLS identity, or an administrator signature. Unauthenticated re-registration of an existing principal MUST be rejected; a registry upsert that replaces a principal's keys is an account takeover.¶

• A revoked runtime MUST NOT be re-registerable except by an administrator.¶

• Anonymous registration modes are development conveniences and MUST be explicit opt-in configuration, never a default.¶

10.5. Authorization Matrix

A broker MUST enforce, per authenticated principal: only the mailbox principal may read, delete, or compact its mailbox and read its receipts, events, and send policy; only a runtime may publish its own prekeys or read its inventory; any active registered principal may send to an active recipient subject to the recipient's send policy; a runtime may revoke itself; administrators (a distinct signing key) may revoke any runtime. A capsule identifier reused with different bytes MUST be rejected; an exact byte-identical resend MUST be idempotent.¶

10.6. Send Policy

Recipients own an allow/deny policy over senders, optionally scoped by message type, thread, delegated-resource prefix, delegation status, and fanout count. The v0.2 default remains allow for compatibility; deployments handling sensitive workloads SHOULD configure default deny.¶

10.7. Receipts, Events, and Compaction

Brokers persist delivery receipts and emit mailbox events as an event stream with durable cursors, supporting both snapshot reads and live streaming. Replay-cache compaction is available to the mailbox owner but MUST enforce a minimum retained-identifier floor; a compaction request below the floor is rejected, because trimming the replay cache below recent traffic re-opens replay.¶

14.1. What SADP Protects

Against a passive or active broker, queue, gateway, or logging layer, SADP provides: task and context payload confidentiality (only intended recipients hold message keys); integrity and authenticity of capsule payloads and authenticated metadata (signatures, audit commitments, and AEAD); replay rejection (capsule identifiers, ratchet counters, request nonces); expiry enforcement; forward secrecy per message and post-compromise recovery across DH ratchet steps ([DOUBLERATCHET]); downgrade resistance for the negotiated suite (signed transcript, Section 7.4); and mailbox-level authorization with replay-protected request authentication (Section 10.2).¶

14.2. What SADP Does Not Protect

SADP does not protect against: a compromised recipient after decryption; malicious model behavior over legitimately received plaintext; prompt injection contained in legitimately decrypted content; collusion among intended recipients; traffic analysis and relationship, capability, audit, and resource-name metadata in the v0.2 outer capsule fields (see Section 11); or revocation of data already disclosed. Deployments MUST NOT represent SADP as an anonymity system.¶

14.3. Initiator and Responder Authentication

The v0.2 handshake authenticates the initiator explicitly by signature and the responder implicitly by key possession (Section 7.3). The binding between a signing key and a principal name is only as strong as the registry's registration proofing (Section 10.4); deployments that accept anonymous registration have no principal authentication at all, which is why anonymous modes are confined to explicit development configuration. Cross-registry identity, attestation of runtimes, and richer identity proofing are out of scope and are natural integration points for workload-identity systems such as SPIFFE [SPIFFE] and the WIMSE architecture work.¶

14.4. Cryptographic Profile Status

The v0.2 profiles use conservative, widely deployed primitives: X25519 [RFC7748], Ed25519 [RFC8032], ChaCha20-Poly1305 [RFC8439], HKDF-SHA256 [RFC5869], SHA-256 [RFC6234], and ML-KEM-768 [FIPS203]. Two cautions are in order. First, the reference implementation's ML-KEM dependency tracks a library that predates final FIPS 203 test-vector alignment in some releases; deployments MUST pin a library version with FIPS 203 final vectors. Second, neither this specification nor its reference implementation has yet received independent external cryptographic review; until such review completes, deployments should treat the protocol as experimental. The construction deliberately reuses the analyzed shapes of X3DH and the Double Ratchet to maximize the applicability of existing analysis, but reuse of shape is not a substitute for review of this composition.¶

14.5. Denial of Service

Signed requests with timestamps and nonces bound to a broker audience limit replay-based abuse; authenticated prekey fetch prevents anonymous one-time-prekey exhaustion; idempotent capsule posting bounds duplicate-delivery amplification; and the verify-before-commit rule (Section 8) prevents forged headers from desynchronizing sessions. Brokers remain subject to ordinary volumetric denial of service and SHOULD deploy standard rate limiting per authenticated principal.¶

14.6. Key Compromise

Compromise of a runtime's signing key allows impersonation of that runtime for new sessions and broker requests until revocation propagates; it does not retroactively decrypt recorded traffic (message confidentiality rests on the DH/KEM secrets and ratchet chains, not the signing key). Compromise of session state exposes current chain keys; the DH ratchet restores confidentiality after the next uncompromised ratchet step. Implementations MUST zeroize retired key material and SHOULD encrypt session stores at rest.¶

16.1. Normative References

[FIPS203]

National Institute of Standards and Technology, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", NIST FIPS 203, August 2024, <https://doi.org/10.6028/NIST.FIPS.203>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/rfc/rfc6234>.

[RFC7748]

Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/rfc/rfc7748>.

[RFC8032]

Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/rfc/rfc8032>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8439]

Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, <https://www.rfc-editor.org/rfc/rfc8439>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

16.2. Informative References

[A2A]

Agentic AI Foundation / Linux Foundation, "Agent2Agent (A2A) Protocol Specification", n.d., <https://a2a-protocol.org/latest/specification/>.

[BISCUIT]

Biscuit project, "Biscuit: Authorization Tokens with Offline Attenuation", n.d., <https://www.biscuitsec.org/>.

[DOUBLERATCHET]

Perrin, T. and M. Marlinspike, "The Double Ratchet Algorithm", November 2016, <https://signal.org/docs/specifications/doubleratchet/>.

[I-D.asor-wimse-agent-delegation-chain]

"Verifiable Attenuated Delegation for AI Agent Chains", Work in Progress, Internet-Draft, draft-asor-wimse-agent-delegation-chain-01, September 2026, <https://datatracker.ietf.org/doc/draft-asor-wimse-agent-delegation-chain/>.

[I-D.atakora-wimse-sadp-delegation]

Atakora, H., "SADP Capability Delegation Chains and Scoped Context Disclosure", Work in Progress, Internet-Draft, draft-atakora-wimse-sadp-delegation-02, September 2026, <https://datatracker.ietf.org/doc/html/draft-atakora-wimse-sadp-delegation-02>.

[I-D.chapman-a2a-mls]

Chapman, C., "End-to-End Encryption and Purpose-Bound Governance for Agent-to-Agent Messaging", Work in Progress, Internet-Draft, draft-chapman-a2a-mls, n.d., <https://datatracker.ietf.org/doc/draft-chapman-a2a-mls/>.

[I-D.hamr-oauth-agent-delegation]

"An Attenuated Delegation Profile for Automated Agents", Work in Progress, Internet-Draft, draft-hamr-oauth-agent-delegation, n.d., <https://datatracker.ietf.org/doc/draft-hamr-oauth-agent-delegation/>.

[I-D.ietf-mboned-sadp]

"Scoped Address Discovery Protocol", Work in Progress, Internet-Draft, draft-ietf-mboned-sadp, n.d., <https://datatracker.ietf.org/doc/draft-ietf-mboned-sadp/>.

[I-D.li-oauth-delegated-authorization]

"OAuth 2.0 Delegated Authorization", Work in Progress, Internet-Draft, draft-li-oauth-delegated-authorization, n.d., <https://datatracker.ietf.org/doc/draft-li-oauth-delegated-authorization/>.

[I-D.liu-oauth-chain-delegation]

"OAuth Chain Delegation for AI Agents", Work in Progress, Internet-Draft, draft-liu-oauth-chain-delegation, n.d., <https://datatracker.ietf.org/doc/draft-liu-oauth-chain-delegation/>.

[I-D.nelson-agent-delegation-receipts]

"Delegation Receipt Protocol for AI Agent Authorization", Work in Progress, Internet-Draft, draft-nelson-agent-delegation-receipts, n.d., <https://datatracker.ietf.org/doc/draft-nelson-agent-delegation-receipts/>.

[I-D.sharif-agent-transport-protocol]

"Agent Transport Protocol: Asynchronous Store-and-Forward Messaging for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-sharif-agent-transport-protocol, n.d., <https://datatracker.ietf.org/doc/draft-sharif-agent-transport-protocol/>.

[I-D.sharif-attp]

"ATTP: Agent Trust Transport Protocol", Work in Progress, Internet-Draft, draft-sharif-attp, n.d., <https://datatracker.ietf.org/doc/draft-sharif-attp/>.

[I-D.singla-agent-identity-protocol]

"Agent Identity Protocol (AIP): Decentralized Identity and Delegation for AI Agents", Work in Progress, Internet-Draft, draft-singla-agent-identity-protocol, n.d., <https://datatracker.ietf.org/doc/draft-singla-agent-identity-protocol/>.

[I-D.vandoulas-aidp]

"Agent Interaction and Delegation Protocol (AIDP)", Work in Progress, Internet-Draft, draft-vandoulas-aidp, n.d., <https://datatracker.ietf.org/doc/draft-vandoulas-aidp/>.

[MACAROONS]

Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A., Vrable, M., and M. Lentczner, "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud", NDSS 2014, 2014, <https://research.google/pubs/pub41892/>.

[MCP]

Model Context Protocol project, "Model Context Protocol Specification", June 2025, <https://modelcontextprotocol.io/specification/2025-06-18>.

[PQXDH]

Kret, E. and R. Schmidt, "The PQXDH Key Agreement Protocol", September 2023, <https://signal.org/docs/specifications/pqxdh/>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9420]

Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[RFC9635]

Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, <https://www.rfc-editor.org/rfc/rfc9635>.

[SAGA2025]

Syros, G., Suri, A., Nita-Rotaru, C., and A. Oprea, "SAGA: A Security Architecture for Governing AI Agentic Systems", April 2025, <https://arxiv.org/abs/2504.21034>.

[SESAME]

Marlinspike, M. and T. Perrin, "The Sesame Algorithm: Session Management for Asynchronous Message Encryption", April 2017, <https://signal.org/docs/specifications/sesame/>.

[SLIM]

AGNTCY Project, Linux Foundation, "SLIM: Secure Low-Latency Interactive Messaging for Agents", n.d., <https://slim.agntcy.org/>.

[SOUTH2025]

South, T., Marro, S., Hardjono, T., Mahari, R., and A. Pentland, "Authenticated Delegation and Authorized AI Agents", January 2025, <https://arxiv.org/abs/2501.09674>.

[SPIFFE]

SPIFFE Project, Cloud Native Computing Foundation, "Secure Production Identity Framework for Everyone (SPIFFE)", n.d., <https://spiffe.io/>.

[SPQR]

Signal Messenger, "Signal Protocol and Post-Quantum Ratchets", October 2025, <https://signal.org/blog/spqr/>.

[UCAN]

UCAN Working Group, "User Controlled Authorization Networks (UCAN) Specification", n.d., <https://github.com/ucan-wg/spec>.

[X3DH]

Marlinspike, M. and T. Perrin, "The X3DH Key Agreement Protocol", November 2016, <https://signal.org/docs/specifications/x3dh/>.