UHP vs AC2 (Agentic Communication and Control Protocol)
UHP standardizes how a product executes work through a complete harness. AC2 standardizes a cryptographically authenticated controller-to-agent channel for communication and user-controlled signing. They address different trust boundaries.
Page reviewed 4 Oct 2026 Source and review policy
Bind signing consent to the exact requested operation
Section titled “Bind signing consent to the exact requested operation”The AC2 specification remains Draft, with conformance still TBD. The latest OpenClaw reference 1.0.1, published 14 September 2026, includes fixes for session-scoped Git signing and consent in payment demos. Those are implementation changes, not AC2 protocol 1.0.1. UHP is UHP 2026-09-28 Draft; both sides were checked 4 October 2026.
| Signing step | Evidence to retain |
|---|---|
| Harness requests a signature | Exact operation and intended principal |
| Controller displays consent | Bytes or bounded operation the user actually reviewed |
| Controller signs locally | Signature and bound operation; private key stays with controller |
| Harness uses the signature | Outcome of that authorized operation, not permission for other work |
If a UHP-served harness creates Git commits, the signing request should identify the intended session-created commits. The controller must not inadvertently sign unrelated workspace history. The release’s scoping fixes illustrate why the signing target matters independently of an authenticated channel.
A UHP cancellation can stop further harness work without undoing a signature already issued. Reconcile the signing operation separately and retain execution finality evidence. The controller-channel approval is not a grant over every UHP object, and the composition is not a standardized AC2 binding.
The one-sentence difference
Section titled “The one-sentence difference”UHP is a live execution contract between a product/client and a server that runs complete agent harnesses; AC2 is a peer-to-peer authenticated communication and control protocol between a human controller and an AI agent, with explicit user approval for digital-signing operations.
The two therefore address different boundaries: UHP normalizes harness execution; AC2 keeps signing authority and private keys with the human controller while the agent requests approved actions.
Status first
Section titled “Status first”- UHP is
2026-09-28Draft; the current executable registry contains 85 checks (2026.9.28.post3). Historical measured results remain revision-bound. - AC2 is an Algorand Foundation Draft specification created 1 Apr 2026 and publicly launched on 25 Aug 2026 for community review. Its specification says changes are expected as it matures.
- AC2’s specification currently lists Conformance: TBD. It should not be described as having a completed conformance model or interoperable certification regime.
- The repository first published
ac2-open-claw-reference@1.0.0on 25 Aug 2026; the current reference package is1.0.1as described above. That is the version of the OpenClaw reference package, not an AC2 protocolv1.0specification release.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP | AC2 |
|---|---|---|
| Primary boundary | Product/client ↔ UHP server ↔ complete harness runtime | Controller/user ↔ AI agent |
| Main purpose | Execute and control work consistently across harness runtimes | Authenticated controller-agent communication and human-controlled signing delegation |
| Core transport | HTTP; SSE for streaming | Liquid Auth connection establishment using FIDO2/WebAuthn and WebRTC DataChannels |
| Identity/authentication | UHP server authentication plus per-principal object scoping | DIDs and passkey-based credentials through Liquid Auth |
| Message model | UHP responses, sessions, events, files and artifacts | DIDComm v2-compatible message shapes extended for streaming and signing workflows |
| Human signing approval | No protocol-level controller-to-agent digital-signing approval channel | Signing requests are presented to the controller; the controller signs locally and returns a delegated signature |
| Private-key model | Outside UHP’s harness-execution contract | Designed so the agent does not receive the controller’s private key |
| Streaming | SSE events within UHP task execution | Real-time voice/text streaming over the authenticated P2P channel |
| Relationship to MCP/A2A | Can coexist with other protocols, but does not require them | AC2’s own spec states no direct relationship to MCP or A2A; it targets owner/controller-to-agent communication |
| Conformance | 85-check current Core/Extended/Full registry | TBD in the current Draft specification |
| Maturity snapshot | Draft protocol with reference implementation and conformance suite | Draft protocol with SDK/CLI/OpenClaw reference implementation; conformance not yet defined |
What AC2 standardizes
Section titled “What AC2 standardizes”AC2’s architecture has two principal participants:
- the Controller, normally a user’s wallet or identity-capable application; and
- the Agent, which can request communication or signing operations while remaining unable to access the controller’s private keys.
The required AC2 transport layer is Liquid Auth. The specification describes a signaling service for initial connection establishment, FIDO2/WebAuthn-based authentication, and direct WebRTC DataChannels for the end-to-end encrypted peer channel. The signaling service is not the message relay: after establishment, AC2 messages travel peer to peer.
For a signing flow, the agent sends a request containing the operation context, the controller reviews and approves it locally, and the resulting signature is returned to the agent for the approved operation. The specification uses payments, Git commit signing and document signatures as examples, while keeping the protocol use-case agnostic.
AC2, A2A and MCP are different boundaries
Section titled “AC2, A2A and MCP are different boundaries”The AC2 specification explicitly describes no direct relationship with A2A or MCP. That is useful because all three can otherwise be grouped too loosely as “agent protocols”:
- AC2: human/controller ↔ agent authenticated communication and signing control;
- A2A: independent agentic system ↔ independent agentic system collaboration;
- MCP: AI application ↔ external tools, resources and prompts;
- UHP: product/client ↔ server ↔ complete harness runtime execution.
A system may use more than one of these boundaries without one protocol subsuming the others.
How UHP and AC2 could coexist
Section titled “How UHP and AC2 could coexist”A UHP-driven harness could, in principle, use AC2 internally when an operation requires a human-controlled digital signature. For example:
Product / client │ │ UHP — start and control harness work ▼UHP server → selected harness / agent │ │ AC2 — request user-controlled signature ▼ ControllerThe UHP client could continue to observe the outer task/session lifecycle while the running harness uses AC2 for the separate controller-approval boundary.
Security and authority boundary
Section titled “Security and authority boundary”AC2 assumes a semi-trusted agent. Its stated model keeps controller private keys outside the agent, requires signing requests rather than direct key access, and places approval in the controller application. This is a different control plane from UHP’s server authentication and object-scoping rules.
Using both protocols would therefore require both trust models to remain intact: UHP authorization controls access to harness tasks, sessions, files and artifacts, while AC2 controls the separate controller-agent channel and signing authority. An AC2 approval should not be treated as automatically authorizing unrelated UHP objects, and UHP authentication should not be treated as a substitute for a user’s signing approval.
Maturity boundaries that matter
Section titled “Maturity boundaries that matter”The 25 Aug public launch is a meaningful implementation milestone, but several claims would be premature:
- AC2 is not a finalized formal standard. Its own status is Draft.
- Conformance is not defined yet. The current specification says
TBD. ac2-open-claw-reference@1.0.0is not “AC2 protocol v1.0”. It is a reference-package release.- The OpenClaw reference implementation does not prove cross-vendor interoperability. It proves that the protocol has a working implementation path.
- AC2 does not establish UHP adoption. Neither current specification names the other.
What AC2 does not replace
Section titled “What AC2 does not replace”- It does not replace UHP’s harness discovery, task/session lifecycle, streaming-event contract, cancellation, files or artifacts.
- It does not replace A2A’s agent-to-agent collaboration model.
- It does not replace MCP’s tool/resource/prompt capability boundary.
- It does not make every controller-approved signature safe or correct; the controller still has to understand and approve the requested operation.
- It does not give a UHP server or harness a standardized AC2 capability automatically.
Related pages
Section titled “Related pages”Read UHP security, UHP vs A2A, UHP vs MCP, Harness composition, and the ecosystem map for neighboring execution, delegation and trust boundaries.