UHP vs Agent Identity Protocol (AIP)

The one-sentence difference

UHP standardizes how a client asks a server to run a selected, configured complete harness; the proposals currently called Agent Identity Protocol (AIP) focus on identifying agents, expressing or delegating authority, and verifying or enforcing that identity at other trust boundaries.

Those concerns can coexist in one system, but they are not interchangeable. A UHP Response or Session is an execution object. An AIP identity, credential, delegation or signed tool-call token is an identity/authorization object whose exact form depends on which AIP proposal is meant.

“AIP” currently names more than one proposal

There is no single canonical Agent Identity Protocol represented by the bare acronym AIP. As of this review, at least three active individual Internet-Drafts use the name or a qualified variant. The IETF Datatracker explicitly states for each that an Internet-Draft may be submitted by anyone, is not endorsed by the IETF, and has no formal standing in the IETF standards process.

Proposal	Current observed draft	Main identity model	Status at this review
Cao / Arango Gutierrez	draft-aip-agent-identity-protocol-00	Registry-bound agent public keys plus per-tool-call signatures and an enforcement proxy that can allow, deny or hold calls	Active individual Internet-Draft; last updated 16 Mar 2026; expires 17 Sep 2026
Singla	draft-singla-agent-identity-protocol-03	W3C DIDs, capability-based authorization and cryptographic delegation chains for decentralized multi-agent workflows	Active individual Internet-Draft; last updated 9 Jun 2026; expires 12 Dec 2026
OpenA2A AIP	draft-fane-opena2a-aip-02; repository spec 1.0.1-draft	Cryptographic agent identity, did:opena2a, capabilities, challenge-response verification, trust scoring, governance, lifecycle and audit	Active individual Internet-Draft; last updated 6 Aug 2026; expires 7 Feb 2027

The naming collision is operationally important. Documentation, configuration or architecture diagrams should identify the author/project or exact draft identifier rather than saying only “AIP.” OpenA2A’s own specification makes the same disambiguation explicit by using OpenA2A AIP.

What the proposals actually standardize

Cao / Arango Gutierrez: signed identity plus an enforcement proxy

draft-aip-agent-identity-protocol-00 separates identity from enforcement. An AIP Registry binds an agent identifier to its public key and accountable principal. The agent signs outbound tool calls, and an AIP Proxy verifies the signature, evaluates an AgentPolicy, and returns an allow, deny or human-approval hold decision before the tool server is reached.

The draft names MCP as its primary tool-call interface but says the mechanism can apply to other structured tool invocation. It also explicitly does not replace service-level authentication such as OAuth or mTLS and does not define a new general transport protocol.

Singla: decentralized identity and delegation

draft-singla-agent-identity-protocol-03 takes a broader decentralized approach. Its core model combines DIDs, capability manifests, credential tokens, principal tokens, registration and resolution, revocation, endorsements and cryptographic delegation rules. Its stated goal is secure and auditable agent delegation without relying on a centralized identity provider.

OpenA2A AIP: identity, capabilities and trust

OpenA2A AIP’s current Internet-Draft is draft-fane-opena2a-aip-02; its repository specification identifies itself separately as 1.0.1-draft. It defines three deployment-oriented conformance levels and combines Ed25519 identity, optional post-quantum hybrid signing, did:opena2a, a structured capability vocabulary, challenge-response verification, behavioral trust scoring, portable signed credentials, transparency logging, governance policies, lifecycle and audit.

OpenA2A AIP explicitly describes itself as complementary to communication/tool protocols including A2A and MCP. That is a useful architectural cue: identity can be layered around an execution or communication protocol without replacing that protocol’s task, message or transport semantics.

Architectural comparison

Dimension	UHP	AIP proposals
Primary concern	Execute a selected configured complete harness behind one server contract	Establish and verify agent identity, authority, delegation, trust or policy enforcement
Typical boundary	Product/client ↔ UHP server ↔ harness	Agent/principal ↔ identity/verification infrastructure; in some proposals, agent ↔ policy proxy ↔ tool/server
Core objects	Harnesses, Responses, Sessions, Containers, Files and streamed Events	Varies by draft: identities, keys, DIDs, credentials, capabilities, delegations, policies, attestations and audit records
Transport role	HTTP resource API with SSE event streaming	Varies; identity is generally layered over existing interactions rather than replacing every application transport
Authentication scope	UHP requires authenticated endpoints except discovery and scopes server objects to the authenticated principal	AIP proposals try to make the agent actor itself cryptographically identifiable and/or constrain delegated authority
Tool-call control	UHP can restrict configured harness tools and exposes execution events, but does not define a portable agent-identity signature for every downstream tool call	Cao/Arango explicitly signs and gates tool calls; other AIP drafts express capabilities/delegation through their own credential models
Task/session semantics	Normative UHP Response and Session lifecycle	Not a replacement for UHP task/session lifecycle
Current maturity	UHP 2026-08-11 Draft with a 62-check conformance suite and a measured reference implementation	Multiple independent, evolving Internet-Drafts; none should be described as an IETF standard

Where UHP and an AIP can coexist

A deployment could use both layers without changing UHP’s external execution contract. For example:

1. A client authenticates to a UHP server and creates a task against a configured harness.
2. The UHP server owns the Response, Session, workspace and event lifecycle required by UHP.
3. The executing harness or delegated subagent carries an AIP-style cryptographic identity when it reaches a downstream tool or another agent.
4. A verifier or enforcement proxy evaluates that identity/delegation independently of the UHP task object.

That composition could improve attribution or delegated-authority controls, but it would be an implementation architecture. No standardized UHP ↔ AIP binding is established by the sources reviewed here. A current HarnessRouter repository search also found no Agent Identity Protocol or OpenA2A integration surface, so this guide does not claim HarnessRouter support for any AIP proposal.

UHP already has security rules, but not an AIP identity model

UHP 2026-08-11 requires authentication for every endpoint except GET /v1/uhp, scopes every server object to the principal that created it, requires cross-scope object requests to return 404, and defines credential, artifact, transport and error-hygiene requirements. It also gives clients controls such as disabledTools, task budgets and a visible event stream.

Those rules protect the UHP server boundary. They do not define how a portable cryptographic identity for an autonomous agent is issued, resolved, delegated or presented to every downstream tool or peer. That is the gap the AIP proposals are trying to address in different ways.

What not to infer

Caution

• An Internet-Draft is not an IETF standard, and the three AIP drafts reviewed here are individual submissions without IETF endorsement or formal standards-process standing.
• “AIP” without a qualifier is ambiguous. Use the project/author name or exact draft identifier.
• UHP bearer/authentication credentials are not automatically AIP agent identities or delegation credentials.
• AIP identity, trust or policy objects are not UHP Responses, Sessions or conformance classes.
• OpenA2A AIP being complementary to A2A/MCP does not establish a UHP binding.
• No primary source reviewed establishes native AIP support in HarnessRouter or native UHP adoption by any AIP project.

Related pages

Read UHP security for the protocol’s own trust-boundary requirements, UHP vs MCP for the tool/context boundary, UHP vs A2A for agent-to-agent communication, UHP vs ACP for editor/client-to-agent interaction, and the ecosystem map for other adjacent standards.

Primary sources

• UHP 2026-08-11 security considerations
• UHP 2026-08-11 architecture
• IETF Datatracker — Cao / Arango draft-aip-agent-identity-protocol-00
• IETF Datatracker — Singla draft-singla-agent-identity-protocol-03
• IETF Datatracker — OpenA2A draft-fane-opena2a-aip-02
• OpenA2A AIP repository specification 1.0.1-draft