Shawn Sammartano

Posted on Jun 6

N-PAMP: A Post-Quantum Wire Protocol for AI Agents (early IETF draft, feedback welcome)

#ai #cryptography #opensource #security

AI agents are increasingly talking to each other, not just to humans. Tool
calls, task delegation, memory sync, identity attestation, telemetry - all of it
now rides over a patchwork of application-layer agent protocols (MCP, A2A, AG-UI,
and a dozen others). Each one brings its own transport assumptions and its own
security posture.

Underneath them all sits TLS 1.3 and QUIC, which are excellent. But there's no
common, binary, agent-oriented wire substrate that bakes in post-quantum key
exchange, semantic channel multiplexing, and mandatory authenticated encryption
tuned for the long-lived associations agents actually form.

I've been designing one. It's called N-PAMP (Native Post-Quantum Agent
Messaging Protocol), and I just posted it as an IETF Internet-Draft. This post is
the design rationale - and an open invitation to poke holes in it.

Status, up front (so I'm not overselling)

N-PAMP is an early-stage Internet-Draft on the IETF Independent Submission
stream (draft-bubblefish-npamp-00, Informational). To be completely honest about
where it is:

It has not been through IETF or independent expert review yet.
There is no public reference implementation yet - this is a specification, published so the wire format and cryptographic choices can be reviewed before the tooling hardens.
The IANA requests (an ALPN identifier and a URI scheme) are filed but not yet approved.

If you find a flaw in the framing, the wire format, or the crypto, that is exactly
the feedback I'm looking for.

The gap N-PAMP tries to fill

Existing transports don't, by themselves, give agent-to-agent traffic:

a single binary frame format with semantic channel multiplexing (so one association can carry control, memory, capability, identity, telemetry, and streaming traffic with independent sequence spaces and per-channel keys);
profile-negotiated cryptographic strength that can escalate without changing the wire format;
mandatory authenticated encryption on every frame; and
post-quantum key establishment by default, so a recorded session today isn't trivially decryptable by a future quantum adversary ("harvest now, decrypt later").

N-PAMP is deliberately scoped as a transport substrate. It does not define what
the data on its channels means - that's left to companion specs and the
application protocols above it.

What N-PAMP looks like

Every message is a frame: a fixed 36-octet header, optional extension TLVs, and
an AEAD-protected payload.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|     'N'       |     'P'       |     'A'       |     'M'       |
+---------------+---------------+---------------+---------------+
| Ver  | Flags  |          Frame Type           |  Channel ID   |
+---------------+---------------+---------------+---------------+
|                  Sequence Number (64 bits)                    |
+---------------------------------------------------------------+
|                  Payload Length (32 bits)                     |
+---------------------------------------------------------------+
|                  CRC32C over the header                       |
+---------------------------------------------------------------+
|              Reserved + Padding (11 octets, zero)             |
+---------------------------------------------------------------+

Four design decisions are worth explaining.

1. A fixed header with a CRC and mandatory AEAD

The header is a constant 36 octets with a magic value (NPAM), a CRC32C for fast
rejection of corrupted frames before any crypto runs, and a flag that marks the
payload as AEAD-sealed. The associated data covers the header, so you can't swap a
header onto someone else's ciphertext. Channel ID and Frame Type stay in the
clear, on purpose, so middleboxes can prioritize by channel without decrypting
anything.

2. Twenty channels, all full-duplex

N-PAMP multiplexes traffic over twenty channels (control, memory, capability,
identity, governance, telemetry, audit, streaming, and more). Each channel has its
own per-direction sequence space and its own per-direction traffic keys, so both
peers can transmit at once and a key or nonce is never shared across directions or
channels. One channel is a general-purpose multiplexed full-duplex stream for
tokens, audio, video, and file transfer.

3. Hybrid post-quantum key establishment

Every profile uses a hybrid KEM: classical X25519 concatenated with a
NIST-standardized module-lattice KEM (ML-KEM, FIPS 203). The shared secrets are
combined before key derivation, so the association stays confidential as long as
either the classical or the post-quantum half remains unbroken. An attacker has
to defeat both. (I'm careful not to call this "quantum-proof" - it's
post-quantum hybrid security against the adversaries its component primitives
address, nothing more.)

Records are protected with AES-256-GCM or ChaCha20-Poly1305; signatures use Ed25519
and ML-DSA-87 (FIPS 204); key derivation is HKDF.

4. Three profiles, one wire format

There are three negotiated profiles - Standard, High, and Sovereign -
that hold the wire format constant while escalating the cryptographic primitives
and operational requirements (stronger KEM parameters, stronger hash, per-frame
diversification, downgrade refusal). The negotiated profile is bound into the
handshake transcript, so an attacker who strips or downgrades it invalidates the
Finished MAC and the handshake aborts.

It runs over QUIC (primary) or TCP with TLS 1.3 (fallback), and negotiates
itself with the ALPN identifier n-pamp/2.

Where it is, and what I'm asking for

The specification is the Internet-Draft, and the repository has the draft source,
the IANA registration text, and the supporting docs. What would help most:

Tell me where the threat model is thin or wrong.
Tell me where a design choice (the CRC, the cleartext header fields, the channel model, the hybrid KEM construction) is a mistake.
Tell me if you'd implement against this - and what would make it easier.

I'd rather hear "this is wrong because X" now, at the draft stage, than after the
wire format is frozen.

DEV Community