Comparison
UHP vs Agent Authorization Envelope (AAE)
UHP standardizes complete-harness execution. AAE is an active individual Internet-Draft for carrying machine-evaluable authorization around autonomous-agent actions.
The one-sentence difference
Section titled “The one-sentence difference”UHP standardizes how a client asks a server to run a selected, configured complete harness; AAE standardizes a portable authorization assertion describing what an autonomous agent may do, under which constraints, and for how long.
These are complementary boundaries. A UHP Response or Session is an execution-lifecycle object. An Agent Authorization Envelope is a signed authorization object presented to a relying party evaluating an agent action.
Current AAE status
Section titled “Current AAE status”The current observed revision is draft-kroehl-agentic-trust-aae-02, published 6 September 2026 with intended status Informational. It is an active individual Internet-Draft. It is not an RFC, not an IETF standard, and is not endorsed by the IETF.
The draft defines AAE as protocol-agnostic and independent of any specific AI framework or transport. That scope is important: AAE can sit beside an execution, tool, agent-to-agent or ordinary application protocol without replacing that protocol’s own request, task or session semantics.
Revision -02 materially expands the enforceable model beyond a coarse action allowlist. It adds transaction-oriented grant semantics, action binding and deterministic enforcement evidence, strengthens delegation handling, and documents capabilities that remain deferred when safe external resolution is unavailable.
What an AAE contains
Section titled “What an AAE contains”An AAE is defined as a W3C Verifiable Credential whose credentialSubject.aae contains three mandatory blocks:
- MANDATE — what the agent is authorized to do, including required action identifiers and optional purpose/scope/principal information.
- CONSTRAINTS — machine-evaluable limits such as transaction-value bounds, domain allowlists and rate limits.
- VALIDITY — temporal validity plus optional controls such as revocation checking and single-use semantics.
The secured envelope is a compact JWS. The draft fixes EdDSA/Ed25519 for signing and binds the issuer signing key to a W3C DID verification method. The unsecured VC payload uses application/aae+json; the secured form is transported as application/jose with cty: aae+json.
This makes AAE more than an identity claim. The relying party is expected to verify structure, signature authority, time bounds, subject binding where applicable, action scope, constraints and other enabled controls before returning an authorization result.
Per-transaction grants in revision -02
Section titled “Per-transaction grants in revision -02”The MANDATE can include an optional grants array alongside its required coarse actions list. When grants are present they are binding: a relying party that does not evaluate them must reject rather than fall back to the broader action list.
That distinction gives the envelope two authorization granularities:
actionssays which action identifiers are permitted at all;- a grant says when a particular action type is authorized for the concrete transaction being evaluated.
The draft also defines action-binding and deterministic digest material so independent verifiers evaluating the same mandate and transaction can derive the same structured enforcement core. Human-readable diagnostic reason text is deliberately kept outside that reproducible digest.
Delegation must attenuate authority
Section titled “Delegation must attenuate authority”AAE supports root and delegated envelopes. The important invariant is non-amplification: a child authorization must remain no broader than its parent.
The draft applies that rule across dimensions such as permitted actions, numeric limits, allowlists, validity windows, required constraints and delegation depth. Where a verifier cannot prove that a child is equal to or narrower than its parent, the safe result is rejection rather than guessing that the change is restrictive.
Revision -02 also bounds what a conforming implementation can claim today. Ancestor material used for delegation verification is supplied to the relying party; the revision does not require unrestricted network fetching of ancestors during evaluation. Capabilities that would require unconstrained external resolution are explicitly treated as deferred/fail-closed rather than silently assumed available.
Architectural comparison
Section titled “Architectural comparison”| Dimension | UHP | AAE |
|---|---|---|
| Primary concern | Execute a configured complete harness through one server contract | Carry and evaluate agent authorization for an action |
| Current status | UHP 2026-08-11 Draft | draft-kroehl-agentic-trust-aae-02, active individual Internet-Draft |
| Main boundary | Product/client ↔ UHP server ↔ harness runtime | Agent/presenter ↔ relying party evaluating authority |
| Core objects | Harnesses, Responses, Sessions, Containers, Files and streamed Events | Signed VC envelope with MANDATE, CONSTRAINTS, VALIDITY, grants and optional delegation |
| Lifecycle semantics | Normative task/session execution, continuation, cancellation and artifact/event behavior | Authorization validity and delegation state; not a replacement for harness task/session lifecycle |
| Identity/crypto | UHP authenticates server endpoints and scopes objects to the authenticated principal | JWS/Ed25519 plus DID-bound issuer verification and VC subject data |
| Action control | UHP configures harness execution and tool availability at its boundary | Relying party evaluates permitted actions, transaction grants and constraints |
| Transport role | HTTP resource API with SSE event streaming | Protocol-agnostic authorization container carried alongside another interaction |
| Conformance relationship | UHP has a dedicated 64-check conformance suite | AAE conformance is separate and does not become UHP conformance |
Where UHP and AAE could coexist
Section titled “Where UHP and AAE could coexist”A deployment could compose the two layers without changing either protocol’s core role:
- A client authenticates to a UHP server and creates a task against a configured harness.
- The UHP server owns the UHP
Response,Session, workspace, file and event lifecycle. - The running harness or a delegated component attempts a consequential downstream action.
- That action is accompanied by an AAE issued for the relevant agent/principal relationship.
- The downstream relying party verifies the AAE and evaluates the mandate, grant, constraints, validity and delegation before allowing the effect.
That composition is an architectural possibility, not a standardized binding. No UHP ↔ AAE binding is established by the primary sources reviewed here, and no native HarnessRouter AAE integration is established by this review.
AAE is adjacent to AIP, not the same thing
Section titled “AAE is adjacent to AIP, not the same thing”The site separately tracks several proposals named Agent Identity Protocol (AIP). Those proposals center on agent identity, capability/delegation credentials, trust or enforcement in different forms. AAE has a narrower named artifact: a machine-evaluable authorization envelope that a relying party evaluates for an action.
There is conceptual overlap, especially around DIDs, delegated authority and attenuation, but the specifications are independent. Documentation should therefore use the exact names and draft identifiers rather than treating AAE as another revision of any AIP proposal.
What not to infer
Section titled “What not to infer”Related pages
Section titled “Related pages”Read UHP security for the protocol’s own trust-boundary requirements, UHP vs AIP for adjacent identity/delegation proposals, Tool-call execution finality for final-dispatch authorization binding, Agent Control Delivery Evidence for evidence that controls were delivered and enforced, and the ecosystem map for other adjacent standards.