UHP vs N-AALP / N-PAMP

The one-sentence difference

UHP standardizes how a product asks a server to execute work through a selected, configured complete agent harness; N-AALP proposes how consequential agent application objects carry signed identity, effect, approval and audit semantics, while N-PAMP proposes a post-quantum multi-channel wire substrate for carrying agent traffic.

These are different architectural planes. A deployment could use UHP for the product-to-harness execution contract while separately using N-AALP objects or N-PAMP transport inside, beside or downstream of the harness. None of the primary sources reviewed establishes a standardized UHP binding or native HarnessRouter integration for either proposal.

Current status

The current observed N-AALP revision is draft-bubblefish-naalp-01, dated 6 September 2026. The IETF Datatracker lists it as an active individual Internet-Draft, states that it is not endorsed by the IETF and has no formal standing in the IETF standards process, and currently shows no RFC stream. The document header says Intended status: Informational and expires 10 March 2027 unless updated or replaced.

The current observed N-PAMP revision is draft-bubblefish-npamp-02, also dated 6 September 2026. Datatracker likewise lists it as an active individual Internet-Draft with no RFC stream and no IETF endorsement; its document header also says Intended status: Informational and expires 10 March 2027.

Caution

Neither N-AALP nor N-PAMP is an RFC or IETF standard. Their current Internet-Draft status is work in progress, and protocol details can change.

Two layers in one proposed stack

The two drafts deliberately separate application semantics from transport mechanics.

N-AALP (Native Agentic Application Layer Protocol) makes the object the unit of security and governance. Its objects are deterministically encoded CBOR structures signed with COSE. Under one signature, an object can bind content identity, signer identity, a closed effect label, approval/audit relationships and causal derivation. The draft defines object state machines, delivery stages, streaming, transport bindings and foreign-protocol carriage by class.

N-PAMP (Native Post-Quantum Agent Messaging Protocol) sits below application protocols. It defines a binary multi-channel wire format, fixed-size frame header, channel multiplexing, security-profile negotiation, hybrid X25519 + ML-KEM key establishment, authenticated encryption and a forward-secure key schedule. Revision -02 names QUIC as the primary transport, TCP with TLS 1.3 as fallback and n-pamp/3 as the ALPN identifier.

N-AALP explicitly says it can ride N-PAMP but does not require it: the same signed application object can also be carried over QUIC, WebSocket or HTTP. That separation is important when comparing the proposals with UHP, because UHP is itself an HTTP execution contract rather than a replacement wire-security protocol.

N-AALP’s key idea: signed effect as an authorization input

N-AALP’s most distinctive boundary is not merely message signing. Its application envelope makes an object’s declared effect part of the governed signed object.

The reference repository exposes a closed four-value effect vocabulary:

• read_only
• idempotent_write
• non_idempotent_write
• destructive

Unknown effects fail closed to destructive, and the project describes the effect as an authorization input rather than a hint. The proposal also defines self-certifying signer identity, content addressing, single-use approvals, receipt/audit chaining and causal relationships.

UHP has a different responsibility. It defines server-owned Responses and Sessions, lifecycle/events, continuation, cancellation, files/artifacts and complete-harness execution. UHP security requirements still matter, but UHP 2026-08-11 does not turn every application object into an N-AALP-style deterministic CBOR + COSE governance envelope.

Foreign-protocol carriage is wrapping, not adoption

N-AALP includes foreign-protocol carriage by class. The draft can carry foreign payload bytes inside its governed signed envelope and defines additive families involving MCP tool calls and A2A task transitions.

That must not be overstated. The draft itself says it does not replace the foreign protocols it carries. The repository’s A2A material treats the task-state vocabulary as imported carriage rather than adoption, and a wrapped MCP/A2A payload does not make MCP or A2A identity automatically become N-AALP authorization identity.

The same boundary applies to UHP. An implementation could theoretically carry UHP-related payload material inside another signed envelope, but no current primary source defines a standard UHP ↔ N-AALP carriage profile. Foreign-protocol carriage support should therefore not be reported as native UHP adoption.

N-PAMP’s boundary is below UHP

N-PAMP addresses a wire/association problem that UHP deliberately does not own. Its current draft defines:

• a fixed 36-octet frame header;
• multiplexed semantic channels with independent sequence spaces;
• Standard, High and Sovereign security profiles;
• hybrid classical/post-quantum key establishment using X25519 plus ML-KEM;
• AEAD-protected payloads and forward-secure key updates;
• QUIC primary carriage and TCP/TLS 1.3 fallback;
• ALPN n-pamp/3 for the current cryptographic generation.

The draft explicitly says it does not define application-layer semantics and is not a general-purpose VPN. UHP, by contrast, defines application-level harness execution objects over HTTP/TLS and leaves the server-to-harness mechanism implementation-defined.

A UHP server therefore does not need N-PAMP to conform to UHP, and an N-PAMP endpoint does not become a UHP server merely because it provides a secure agent transport.

Architectural comparison

Dimension	UHP	N-AALP	N-PAMP
Primary concern	Complete-harness task/session execution	Signed, governed application objects	Agent messaging wire substrate
Current status	2026-08-11 Draft with runnable conformance	draft-bubblefish-naalp-01, active individual I-D	draft-bubblefish-npamp-02, active individual I-D
Main boundary	Product/client ↔ UHP server ↔ configured harness	Agent/application object ↔ verifier/governance policy	Agent endpoint ↔ agent endpoint secure association
Core unit	Response / Session / event / file	Deterministic signed object	Binary frame / channel / association
Encoding	HTTP API objects; JSON/SSE surfaces	Deterministic CBOR + COSE signed object	Binary fixed-header frame + protected payload
Authorization emphasis	Server/principal/object and harness execution policy	Closed signed effect + approvals/capabilities/audit	Transport authentication, negotiated crypto profiles and channel protection
Lifecycle	Normative task/session continuation, cancellation, events and artifacts	Object/delivery/stream/approval/reconcile state machines	Association, handshake, channels, key update and close
Transport	HTTP over TLS; SSE for streaming	N-PAMP, QUIC, WebSocket or HTTP bindings	QUIC primary; TCP + TLS 1.3 fallback
PQ cryptography	Not a UHP protocol requirement	ML-DSA profile proposed for object signatures	X25519 + ML-KEM hybrid establishment and PQ-aware profiles
MCP/A2A relationship	Separate protocols; no implicit adoption	Foreign carriage/additive bindings proposed	Can carry application traffic; does not define its semantics
UHP conformance	Dedicated current 64-check suite	Separate project corpus; not UHP conformance	Separate project tests; not UHP conformance

Reference implementation evidence is project evidence

The N-AALP repository is substantially more concrete than a prose-only proposal. At the checked cutoff it publishes reference implementations in ten languages and describes a 565-case conformance corpus, deterministic cross-language ML-DSA checks and byte-parity gates. The repository also contains integration packages for neighboring protocols and frameworks.

That is useful implementation evidence, but its scope must stay precise. The implementations, vectors and ecosystem packages are maintained within the same N-AALP project. They do not establish independent multi-vendor adoption, IETF consensus, UHP conformance or a production UHP↔N-AALP interoperability profile.

Similarly, N-PAMP publishes its own tagged draft and implementation line. Passing N-PAMP’s project tests would establish behavior against that proposal, not UHP’s separate conformance suite.

Where the layers could coexist

A plausible architecture could compose the boundaries without merging them:

1. A product submits a UHP Response to a UHP server selecting a configured complete harness.
2. The UHP server owns task/session lifecycle, streaming, cancellation, files and artifacts.
3. The harness produces or consumes a consequential inter-agent object.
4. That object is represented as an N-AALP signed, effect-labeled object for downstream verification or governance.
5. The object is carried over HTTP/QUIC directly, or over an N-PAMP association when that substrate is selected.
6. UHP results remain UHP protocol objects; N-AALP signatures/approvals/audit and N-PAMP transport evidence remain evidence at their own layers.

This is an architectural composition example only. No standardized UHP↔N-AALP mapping, UHP-over-N-PAMP profile, HarnessRouter N-AALP/N-PAMP backend, or native UHP adoption by the BubbleFish projects was verified.

What not to infer

Caution

• N-AALP and N-PAMP are not IETF standards or RFCs; they are active individual Internet-Drafts.
• N-AALP’s reference implementations and corpus do not establish independent ecosystem adoption.
• N-AALP carriage of MCP/A2A material does not mean MCP or A2A has adopted N-AALP.
• An N-AALP effect label is not automatically a UHP authorization rule.
• An N-PAMP secure association is not a UHP Response, Session or conformance result.
• UHP does not require post-quantum transport or N-PAMP.
• No primary source reviewed establishes native HarnessRouter integration for N-AALP or N-PAMP.

Related pages

Read UHP architecture and Security for UHP’s own execution boundary, UHP vs MCP for tool/context interoperability, UHP vs A2A for agent-to-agent task communication, UHP vs Agent Authorization Envelope for portable action authorization, and Agent Control Delivery Evidence for evidence that a control reached and affected its intended target.

Primary sources

• IETF Datatracker — draft-bubblefish-naalp
• IETF HTML — draft-bubblefish-naalp-01
• N-AALP reference repository
• IETF Datatracker — draft-bubblefish-npamp
• IETF HTML — draft-bubblefish-npamp-02
• N-PAMP reference repository
• UHP 2026-08-11 architecture
• UHP 2026-08-11 security considerations