]> Imara Labs

United States hatakora@imaralabs.dev

Security Individual Submission AI agents end-to-end encryption delegation task capsule double ratchet post-quantum broker A2A MCP This document specifies the Secure Agent Delegation Protocol (SADP), an experimental end-to-end encrypted communication layer for user-to-agent and agent-to-agent workflows. SADP defines task capsules: signed, encrypted, individually routable protocol objects that carry agent tasks, tool invocations, and results across untrusted brokers, queues, and orchestration infrastructure. SADP provides asynchronous session establishment using signed prekey bundles, per-message forward secrecy and post-compromise recovery through a Double-Ratchet-style message ratchet, an optional hybrid post-quantum key-agreement profile based on ML-KEM-768, and an authenticated opaque-broker profile with replay protection. SADP is transport agnostic and is designed to be carried over HTTP, message queues, and existing agent protocols such as A2A and MCP without requiring those systems to be trusted with plaintext task content. Capability-based delegation semantics and scoped context disclosure are specified in a companion document.

Introduction

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 secures hops with TLS and delegates authorization to server-side policy, and the Model Context Protocol 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 .

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 . 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.

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 .
• Per-message forward secrecy and post-compromise recovery through a message ratchet derived from the Double Ratchet algorithm .
• An optional hybrid post-quantum key-agreement profile combining X25519 with ML-KEM-768 , following the hybrid approach of PQXDH .
• Multi-runtime agent identity, treating each runtime of an agent like a device in multi-device secure messaging .
• 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. discusses these boundaries.

Relationship to A2A, MCP, and Agent Transports SADP is a layer, not a replacement. A2A defines agent discovery, agent cards, and task exchange between agent servers; 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 () adds authenticated mailboxes, registry services, and receipts.

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 ; the message ratchet derives from the Double Ratchet ; the hybrid post-quantum profile follows PQXDH and the subsequent post-quantum ratchet work ; the multi-runtime model follows Sesame . The capability lineage in the companion document builds on Macaroons , Biscuit , and UCAN , and its on-behalf-of semantics relate to OAuth 2.0 Token Exchange and GNAP . Adjacent protocol work exists and predates this document. applies MLS to A2A messages with purpose binding; the AGNTCY SLIM project provides an MLS-based encrypted session layer as an agent transport; defines verifiable attenuated delegation tokens for agent chains without an encryption layer; defines an HTTP header profile for attenuated cross-domain agent delegation; defines OAuth-based chained delegation tokens for agent identities; defines constrained client-issued delegated authorization tokens; defines decentralized identity and capability delegation for agents; defines a control-plane model for intent, authority, execution, and observation; defines user-signed, log-anchored delegation receipts; specifies an agent trust transport framework for trust scoring and action-limit enforcement; and specifies an asynchronous store-and-forward agent transport. Academic proposals address authenticated delegation and multi-agent governance . 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.

Document Organization This document specifies the SADP data model (, ), session establishment (), the message ratchet (), single-capsule payload profiles (), the opaque broker profile (), metadata privacy (), and transport carriage (). Capability grants, delegation chains, caveats, scoped context disclosure, and the audit hash chain are specified in ; this document defines only the capsule fields that carry them.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Principal:

An entity that participates in SADP with a stable identifier and cryptographic key material. Principals include users, agents, runtimes, tools, workspaces, and brokers.

Runtime:

An executing instance of an agent or tool, analogous to a device in multi-device secure messaging . An agent identity is stable across its runtimes; each runtime has its own key material and registration.

Task Capsule (or Capsule):

The SADP protocol object: a JSON document with a cleartext routing header, protocol metadata, authenticated capability grants and audit records, and an encrypted task or context payload. In the v0.2 profile, capability and audit fields are outer authenticated fields rather than encrypted inner fields.

Broker:

An untrusted store-and-forward service that accepts, stores, and delivers opaque capsule bytes to recipient mailboxes and hosts the runtime registry. A broker is trusted for availability, never for confidentiality.

Mailbox:

The per-principal delivery queue a broker maintains.

Session:

The shared cryptographic state between two principals on one communication edge, established as described in and advanced by the message ratchet.

Prekey Bundle:

Signed public key material a runtime publishes to the registry so that senders can establish sessions while the runtime is offline, following the design of .

One-Time Prekey:

A prekey published for single use and consumed at selection time.

Edge:

An ordered (local principal, remote principal, thread) tuple over which one session is maintained.

Registry:

The broker-hosted directory of runtime records, signing keys, encryption keys, and prekey bundles.

Scheme Identifier:

A versioned ASCII string naming a cryptographic profile, for example "sadp-session-init-x25519-hkdf-sha256-v0.2". Every signed or encrypted SADP structure names its scheme explicitly.

Protocol Overview SADP layers as follows: A typical exchange proceeds as follows:

1. Each runtime generates an Ed25519 signing keypair, an X25519 encryption keypair, optionally an ML-KEM-768 keypair, and registers with a broker, proving possession of its signing key ().
2. A sender fetches the recipient's prekey bundle from the registry, verifies its signature and expiry, and derives a session root key using the signed session-initiation handshake ().
3. The sender builds a task capsule: cleartext routing header, authenticated capability grants and audit commitments as needed, and a task or context payload encrypted under the session's message ratchet ().
4. The broker authenticates the sender's request by signature (), performs mailbox-level authorization, stores the opaque capsule, and emits delivery events.
5. The recipient fetches the capsule, performs the validation sequence of , verifies capabilities and audit linkage per , decrypts the encrypted payload, and only then releases plaintext to the application.
6. Replies and delegated subtasks flow the same way on their own edges, advancing or establishing sessions as needed.

Principal Identifiers A principal identifier is a sequence of one or more segments separated by "/" (U+002F). Each segment has the form kind:name, where kind is one of: and name is a nonempty token of ASCII letters, digits, "-", "_", and ".". Examples: The identifier without its trailing runtime:* or device:* segment is the principal's "subject" and groups the runtimes or devices of a single actor. Implementations MUST reject identifiers with unknown segment kinds, empty segments, or characters outside the token alphabet.

Data Encoding

Canonical JSON SADP structures are JSON 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 ; implementations MAY use an RFC 8785 canonicalizer, provided the restrictions above are enforced on input.

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

Hashing All hashes in this document are SHA-256 and are encoded as base64url without padding unless stated otherwise.

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.

Task Capsules

Capsule Header Every capsule carries the following cleartext header fields: 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.

Message Types The initial message-type registry () contains:

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 ().

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 .

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 .

session_init:

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

encrypted_payload:

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

key_agreement:

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

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 ().
9. Verify audit parent linkage ().
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).

Session Establishment

Prekey Bundles Each registered runtime publishes a signed prekey bundle to the registry: ", "encryption_public_key": "", "ml_kem768_encapsulation_key": "", "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": "" } ]]> 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 .

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 (). Runtimes can monitor inventory through the registry's inventory interface and MUST tolerate static-prekey fallback, as in .

Session Initiation The v0.2 session-initiation profile is identified by: 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 ().
5. Builds the session transcript ().
6. Signs the transcript with its Ed25519 identity signing key.
7. Derives the session root key: HKDF-SHA256 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: ", "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": "", "responder_identity_public_key": "", "initiator_signing_public_key": "", "initiator_signature": "", "transcript_hash": "", "algorithm_suite": "x25519-hkdf-sha256+ml-kem-768", "pq_hybrid_scheme": "sadp-ml-kem-768-v0.1", "pq_kem_ciphertext": "", "repair_for_session_id": "", "repair_epoch": 1 } ]]> initiator_signing_public_key and initiator_signature are REQUIRED. The PQ fields and repair fields are OPTIONAL.

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: 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.)

Initiator Authentication initiator_signature is an Ed25519 signature over the byte string: 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 ; SADP chooses explicit initiator authentication because agent workflows require attributable task submission, and deniability is a non-goal.

Hybrid Post-Quantum Profile The hybrid suite x25519-hkdf-sha256+ml-kem-768 follows the construction pattern of PQXDH : the initiator encapsulates to the responder's ML-KEM-768 encapsulation key, carries the ciphertext in pq_kem_ciphertext, and the root-key input keying material becomes the labeled concatenation: 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 ) is out of scope for this revision and identified as future work.

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.

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.

Message Ratchet The v0.2 message ratchet profile is identified by: It is a Double-Ratchet-style construction with per-direction symmetric chains and X25519 DH ratchet steps.

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.

Key Derivation All derivations are HKDF-SHA256 , 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: 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: The new chain key also becomes the new epoch's chain anchor. The AEAD is ChaCha20-Poly1305 ; 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.

Message Format ", "dh_epoch": 1, "dh_public_key": "", "counter": 0, "nonce": "", "ciphertext": "" } ]]>

Associated Data Binding The AEAD associated data is: 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.

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.

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.

Single-Capsule Payload Profiles Two payload profiles exist for capsules outside a ratcheted session; both are intended for development, fixtures, and first-contact messages, and ratcheted sessions SHOULD be used for all multi-message exchanges.

sadp-aead-chacha20poly1305-v0.1:

Direct AEAD with a caller-provisioned 32-byte key, 12-byte nonce, and associated data binding "sadp-capsule-v0.1:" || capsule_id || ":" || from || ":" || to.

sadp-pre-ratchet-x25519-hkdf-sha256-v0.1:

A fresh sender-ephemeral X25519 key against the recipient's static encryption key; the AEAD key is HKDF-SHA256 over the shared secret with the capsule-metadata associated data as salt. This profile provides confidentiality from the broker but neither sender authentication at the cryptographic layer nor post-compromise recovery, and MUST NOT be used where those properties are required.

Opaque Broker Profile

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: together with registry endpoints for runtime registration, prekey lookup, one-time prekey publication and inventory, issuer-key lookup, and revocation.

Request Authentication Authenticated broker requests carry: X-SADP-Timestamp: X-SADP-Audience: X-SADP-Signature: ]]> The signature scheme is sadp-request-ed25519-v0.2. The signing input is: 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 ; SADP uses its own canonical-JSON signing input so that identical logic can run over non-HTTP carriage ().

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.

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.

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.

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.

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.

Metadata Privacy Considerations SADP v0.2 is an opaque-payload routing profile, not an anonymity system. A broker observes sender and recipient principals, capsule identifiers, capability grant metadata, audit records, sizes, timing, and registration metadata. It does not observe encrypted task payload or context plaintext. Deployments for which relationship, grant, resource-name, or timing metadata is sensitive should apply the staged hardening profiles, which are informative here:

• M1 (minimization): random opaque capsule identifiers, padded payload buckets, redacted structured logs, retention limits.
• M2 (sealed batch routing): recipient hints moved out of URL paths, batched multi-recipient delivery, timing jitter, queue-depth hiding.
• M3 (pairwise routing identifiers): opaque per-edge mailbox identifiers replacing stable principal names on routing operations.
• M4 (sender-hidden delivery): token-based delivery in which the sender's stable identity appears only inside the encrypted capsule.
• M5 (traffic-analysis resistance): cover traffic, fixed-size frames, batched delivery windows, and mix-style relays.

Future wire revisions reserve fields for opaque routing identifiers, routing epochs, padding policy identifiers, and delivery-token commitments, authenticated as associated data so endpoints can detect broker substitution.

Transport Adapters SADP objects are self-contained JSON documents; carriage requires only that bytes arrive intact.

HTTP:

The broker profile of is itself an HTTP API and is the reference transport.

A2A:

An SADP capsule is carried as an opaque payload part inside an A2A message or task . The A2A server routes and manages task lifecycle without payload visibility. Agent cards MAY advertise SADP support and registry location.

MCP:

An encrypted tool invocation is carried as an SADP tool_call capsule inside an MCP tool call. The tool runtime, as a distinct SADP principal, decrypts arguments and encrypts results; the MCP host sees only capsule bytes. This requires the tool runtime, not the host, to hold the recipient keys.

Queues and IPC:

Any at-least-once byte transport can carry capsules; receiver-side replay rejection () makes redelivery safe.

Error Handling Protocol errors are surfaced as typed conditions, and implementations MUST distinguish at minimum: validation failures (malformed, expired, replayed, unknown-critical), authentication failures (signature, transcript, AEAD), authorization failures (mailbox ownership, send policy, capability), and availability failures (rate limit, storage). Brokers MUST NOT reflect payload bytes in error responses. Receivers MUST treat all AEAD failures identically and without detailed reason codes on the wire, to avoid oracle behavior.

Security Considerations

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 (); downgrade resistance for the negotiated suite (signed transcript, ); and mailbox-level authorization with replay-protected request authentication ().

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 ); or revocation of data already disclosed. Deployments MUST NOT represent SADP as an anonymity system.

Initiator and Responder Authentication The v0.2 handshake authenticates the initiator explicitly by signature and the responder implicitly by key possession (). The binding between a signing key and a principal name is only as strong as the registry's registration proofing (); 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 and the WIMSE architecture work.

Cryptographic Profile Status The v0.2 profiles use conservative, widely deployed primitives: X25519 , Ed25519 , ChaCha20-Poly1305 , HKDF-SHA256 , SHA-256 , and ML-KEM-768 . 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.

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 () prevents forged headers from desynchronizing sessions. Brokers remain subject to ordinary volumetric denial of service and SHOULD deploy standard rate limiting per authenticated principal.

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.

IANA Considerations This document, if published, would request:

• Registration of the media type application/sadp+json for SADP capsules.
• Creation of an "SADP Scheme Identifiers" registry (Specification Required) with initial entries for the scheme identifiers defined in this document and in .
• Creation of an "SADP Message Types" registry (Specification Required) with the initial entries listed in .
• Registration of the X-SADP-Principal, X-SADP-Request-Id, X-SADP-Timestamp, X-SADP-Audience, and X-SADP-Signature HTTP field names.

This document makes no request of IANA at Internet-Draft stage.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data (AEAD) algorithm. RFC 7539, the predecessor of this document, was meant to serve as a stable reference and an implementation guide. It was a product of the Crypto Forum Research Group (CFRG). This document merges the errata filed against RFC 7539 and adds a little text to the Security Considerations section. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. Federal Information Processing Standard, FIPS JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. National Institute of Standards and Technology Informative References Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. Signal Messenger Biscuit project n.d. UCAN Working Group n.d. Agentic AI Foundation / Linux Foundation n.d. Model Context Protocol project AGNTCY Project, Linux Foundation n.d. SPIFFE Project, Cloud Native Computing Foundation n.d.

Example Exchange The following abbreviated flow shows a user tasking an agent through an untrusted broker. Keys and ciphertexts are truncated. Runtime registration (authenticated; proof of possession via the signed prekey bundle): Sender fetches a prekey bundle (authenticated), initiates a session, and posts the first capsule: The recipient authenticates its mailbox read, validates per (including capability-chain and audit checks from the companion document), verifies the signed session init, derives the root key, decrypts, executes or delegates the task, and replies with a task_result capsule on the same thread, advancing the ratchet.

Cryptographic Profile Summary

Purpose	Scheme identifier	Primitives
Session init	sadp-session-init-x25519-hkdf-sha256-v0.2	X25519, HKDF-SHA256, Ed25519, SHA-256
PQ hybrid	sadp-ml-kem-768-v0.1	ML-KEM-768
Ratchet	sadp-ratchet-hkdf-chacha20poly1305-v0.2	HKDF-SHA256, ChaCha20-Poly1305, X25519
Single-capsule AEAD	sadp-aead-chacha20poly1305-v0.1	ChaCha20-Poly1305
Pre-ratchet payload	sadp-pre-ratchet-x25519-hkdf-sha256-v0.1	X25519, HKDF-SHA256, ChaCha20-Poly1305
Capability grants	sadp-cap-ed25519-v0.2	Ed25519, SHA-256 (companion document)
Prekey bundles	sadp-prekey-ed25519-v0.1	Ed25519
Broker requests	sadp-request-ed25519-v0.2	Ed25519, SHA-256

Acknowledgments The session and ratchet design follows the public Signal protocol specifications , and this document's threat framing benefited from prior work on encrypted agent messaging and agent delegation .