HDP v0.1

1Overview#

• Downstream agents cannot verify that the action they are being asked to perform was actually authorized by a human.
• Post-hoc audits cannot reconstruct who approved what, and when.
• Prompt injection, where malicious content in the environment instructs an agent to act, cannot be distinguished from legitimate human delegation.

• Records the human principal, their declared scope, and the session binding at issuance.
• Accumulates a cryptographically signed hop record for each agent that handles the token.
• Allows any recipient to verify the entire chain, root signature plus all hop signatures, using only the issuer’s Ed25519 public key and the session identifier.

2Terminology#

Issuer

The system or person that creates and signs an HDP token on behalf of a human principal.

Principal

The human who authorized the agentic task. Represented in the token’s principal object.

Agent

Any AI system, model, or automated process that receives and acts upon an HDP token.

Hop

A single delegation event, recorded as a signed entry in the token’s chain array.

Root signature

The Ed25519 signature over the header, principal, and scope, computed by the issuer at token creation time.

Hop signature

The Ed25519 signature over the cumulative chain state at the time of extension. In v0.1 it is produced by the issuer using the same key as the root signature.

Session

A logical unit of work identified by a session_id string, established between the issuer and the agent framework before the token is issued.

3Token structure#

{
  "hdp"       : "0.1",          // protocol version
  "header"    : { ... },        // session binding + lifecycle
  "principal" : { ... },        // authorizing human
  "scope"     : { ... },        // authorized intent + constraints
  "chain"     : [ ... ],        // delegation hops (append-only)
  "signature" : { ... }         // root Ed25519 signature
}

3.1Header#

{
  "token_id"        : "550e8400-e29b-41d4-a716-446655440000",
  "issued_at"       : 1711483200000,
  "expires_at"      : 1711569600000,
  "session_id"      : "sess-20260326-abc123",
  "version"         : "0.1",
  "parent_token_id" : "..."
}

token_idREQUIRED

A version 4 UUID (RFC 9562). Unique identifier for this token.

issued_atREQUIRED

Unix milliseconds. Time of issuance.

expires_atREQUIRED

Unix milliseconds. The token MUST NOT be accepted after this time. Default lifetime is 24 hours.

session_idREQUIRED

Opaque string, established out of band between issuer and agent framework before token issuance. Provides replay defense: a token is only valid within the session for which it was issued.

versionREQUIRED

MUST equal the value of the top-level hdp field.

parent_token_idOPTIONAL

If present, identifies the token this token supersedes in a re-authorization chain, or the token it jointly extends. See §6 and §7.

3.2Principal#

{
  "id"             : "usr_alice_opaque",
  "id_type"        : "opaque",
  "display_name"   : "Alice Chen",
  "poh_credential" : "...",
  "metadata"       : {}
}

idREQUIRED

Identifier for the principal, interpreted according to id_type.

id_typeREQUIRED

One of the defined values below, or a custom string prefixed with x-.

display_nameOPTIONAL

Human-readable name. Omit where the receiving agent does not require a human-readable identity.

poh_credentialOPTIONAL

A Proof-of-Humanity credential. Verification semantics are application-defined. See §9.

metadataOPTIONAL

Application-defined object. Not interpreted by the protocol.

opaque

Application-defined identifier. No resolution semantics are implied.

email

An email address as defined in RFC 5321.

uuid

A UUID as defined in RFC 9562.

did

W3C Decentralized Identifier. DID resolution is application-defined and not required by this protocol.

poh

A Proof-of-Humanity credential identifier.

3.3Scope#

{
  "intent"               : "Analyze Q1 sales data and report.",
  "authorized_tools"     : ["database_read", "file_write"],
  "authorized_resources" : ["db://sales/q1-2026"],
  "data_classification"  : "confidential",
  "network_egress"       : false,
  "persistence"          : true,
  "max_hops"             : 3
}

intentREQUIRED

Free-form natural language description of the authorized task. This is the human-readable authorization statement.

data_classificationREQUIRED

One of public, internal, confidential, or restricted. The sensitivity level of data the agent is authorized to access.

network_egressREQUIRED

Boolean. Whether the agent is authorized to make outbound network requests.

persistenceREQUIRED

Boolean. Whether the agent is authorized to write persistent state.

authorized_toolsOPTIONAL

Array of tool identifiers the principal has explicitly authorized. Enforcement is application-defined.

authorized_resourcesOPTIONAL

Array of resource identifiers, such as URIs or paths, the principal has authorized access to.

max_hopsOPTIONAL

Positive integer. Maximum number of delegation hops permitted. Verification MUST reject tokens whose chain length exceeds this value. Omitting it leaves chain length unbounded.

3.4Chain#

{
  "seq"               : 1,
  "agent_id"          : "orchestrator-v2",
  "agent_type"        : "orchestrator",
  "agent_fingerprint" : "sha256:abc123...",
  "timestamp"         : 1711483260000,
  "action_summary"    : "Decompose task; delegate to sub-agents.",
  "parent_hop"        : 0,
  "hop_signature"     : "<base64url-encoded Ed25519 signature>"
}

seqREQUIRED

Positive integer, starting at 1. MUST be exactly one greater than the previous hop’s seq. Gaps are a protocol violation.

agent_idREQUIRED

Identifier of the agent adding this hop. MAY be an opaque, per-delegation identifier.

agent_typeREQUIRED

One of orchestrator, sub-agent, tool-executor, or custom.

timestampREQUIRED

Unix milliseconds. Time of hop extension.

action_summaryREQUIRED

Human-readable description of the action this agent intends to take.

parent_hopREQUIRED

Non-negative integer. Index of the hop that triggered this delegation, where 0 indicates the root human authorization.

hop_signatureREQUIRED

Base64url-encoded, no padding, Ed25519 signature. See §4.2. Absence is a protocol violation.

agent_fingerprintOPTIONAL

Model or binary fingerprint for the acting agent.

3.5Signature#

{
  "kid"   : "alice-signing-key-v1",
  "alg"   : "Ed25519",
  "value" : "<base64url Ed25519 signature over canonical JSON>"
}

algREQUIRED

MUST be Ed25519 for HDP v0.1. Verifiers MUST reject any other value.

kidREQUIRED

Key identifier. SHOULD be used by verifiers to select the correct public key when multiple keys are in circulation.

valueREQUIRED

Base64url-encoded, no padding, Ed25519 signature over the canonical JSON payload. See §4.1.

4Cryptographic signing#

4.1Root signature#

1. 1.Construct the unsigned token object containing the hdp, header, principal, scope, and chain fields, where chain is an empty array at issuance.
2. 2.Serialize the object to canonical JSON per RFC 8785.
3. 3.Compute the Ed25519 signature over the canonical JSON bytes using the issuer’s private key.
4. 4.Encode the signature bytes as base64url with no padding.
5. 5.Attach the signature object, carrying kid, alg, and value, to the token.

4.2Hop signature#

1. 1.Construct the new hop record, with all fields except hop_signature.
2. 2.Build the signing payload as a JSON array of the previously signed hops, each WITH its hop_signature, followed by the new hop WITHOUT its hop_signature.
3. 3.Prepend the root signature value, a base64url string, as the array’s first element. This chains the hop signature to the root.
4. 4.Serialize the array to canonical JSON per RFC 8785.
5. 5.Compute the Ed25519 signature over the canonical JSON bytes using the issuer’s private key.
6. 6.Encode as base64url and attach as the hop_signature field on the new hop record.
7. 7.Append the signed hop to the token’s chain array.

[
  root_signature_value,   // base64url string, chains this hop to the root
  hop_1,                  // WITH its hop_signature
  hop_2,                  // WITH its hop_signature
  ...
  new_hop_unsigned        // WITHOUT its hop_signature
]

4.3Chain integrity rules#

1. 1.Hop seq values MUST start at 1 and increment by exactly 1. No gaps are permitted.
2. 2.Existing hop records MUST NOT be modified or removed.
3. 3.A hop’s parent_hop MUST reference a valid prior hop index: 0 for the root human authorization, or the seq value of a prior hop.
4. 4.If scope.max_hops is set, the chain length MUST NOT exceed it. A token with a full chain MUST NOT be extended.
5. 5.Each hop’s timestamp SHOULD be monotonically non-decreasing.
6. 6.The hop_signature field MUST be present on every hop. A hop without one is a protocol violation and MUST cause verification to fail.

5Verification pipeline#

1. 1.Version check. The hdp field MUST contain a recognized protocol version string. For this specification the only recognized value is 0.1. The header.version field MUST equal the hdp field; a mismatch MUST cause rejection.
2. 2.Expiry check. header.expires_at MUST be strictly greater than the current time. Expired tokens MUST be rejected.
3. 3.Root signature verification. Reconstruct the canonical JSON payload by removing the signature field and resetting chain to an empty array, then serializing per RFC 8785. Verify that signature.alg is Ed25519, then verify signature.value against this payload using the issuer’s public key. Failure indicates tampering with the header, principal, or scope.
4. 4.Hop sequence and structure integrity. For each hop, verify that seq equals its index plus one; any gap or duplication MUST cause rejection. Verify that each parent_hop references either 0 or the seq of a prior hop; an out-of-range value MUST cause rejection.
5. 5.Hop signature verification. For each hop at index i: confirm hop_signature is present, where absence MUST cause rejection; reconstruct the signing payload described in §4.2 using hops 0 through i-1 with their signatures, plus the hop at i without its own, prepended by the root signature value; then serialize per RFC 8785 and verify against the issuer’s public key.
6. 6.max_hops check. If scope.max_hops is defined, the length of chain MUST NOT exceed it.
7. 7.Session binding check. header.session_id MUST exactly match the session identifier supplied by the verifying application. This prevents token replay across sessions.

6Re-authorization#

• Has a new token_id, issued_at, and expires_at.
• Inherits session_id, principal, and scope from the original unless explicitly overridden.
• Starts with an empty chain, so the delegation count resets.
• Records parent_token_id pointing at the original, creating an auditable lineage of scope evolution.

7Multi-principal delegation#

1. 1.Verify each token individually against its issuer’s public key using the standard seven-step pipeline.
2. 2.Verify that T[i].header.parent_token_id equals T[i-1].header.token_id for all i greater than 0.
3. 3.Verify that all tokens in the chain share the same session_id.

8Transport#

8.1HTTP header: HDP-Token#

POST /api/task HTTP/1.1
Host: agent.example.com
HDP-Token: eyJoZHAiOiIwLjEiLCJoZWFkZXIiOnsi...
Content-Type: application/json

8.2Token by reference: HDP-Token-Ref#

POST /api/task HTTP/1.1
Host: agent.example.com
HDP-Token-Ref: 550e8400-e29b-41d4-a716-446655440000

8.3Key distribution#

{
  "keys": [
    {
      "kid" : "alice-signing-key-v1",
      "alg" : "Ed25519",
      "pub" : "<base64url-encoded 32-byte Ed25519 public key>"
    }
  ]
}

9Privacy considerations#

• Store tokens with explicit retention periods derived from header.expires_at.
• Provide deletion mechanisms that remove stored tokens upon erasure requests.
• Use opaque identifiers in principal.id where possible, maintaining a separate mapping that can be destroyed independently of the token audit log.

10Security considerations#

Threat model

HDP provides provenance and tamper evidence, not runtime enforcement. It creates an evidence trail, not a capability boundary. Applications requiring runtime enforcement MUST implement it at the application layer, using the token as audit input.

Token forgery

A forged token fails step 3, the root signature check. Security rests on the unforgeability of Ed25519 and the collision resistance of SHA-512, used internally by Ed25519. An attacker without the issuer’s private key cannot produce a valid root signature for a modified token.

Chain tampering

Modification, reordering, or removal of any non-trailing hop is detectable: it either breaks the sequence check at step 4 or invalidates the hop signatures of all subsequent hops at step 5, because each hop signature covers all previous hops and the root signature.

Chain truncation

Each hop signature covers only the hops preceding it. Deleting trailing hops, or presenting an earlier and shorter copy, yields a token that still passes every step. HDP provides tamper evidence for the hops that are present, and does not by itself prove the chain is complete.

Replay defense

Two orthogonal defenses: short lifetimes via expires_at, enforced at step 2, and session binding, so a token is valid only within its issuing session. Applications with high security requirements SHOULD use lifetimes measured in minutes, and SHOULD generate session_id values with at least 128 bits of entropy from a cryptographically secure source.

Revocation

HDP does not provide mid-chain revocation. A token becomes invalid when it expires or when its session ends. Proof that an action was authorized is not by itself proof that the authorization is still current. Deployments needing fine-grained revocation SHOULD keep lifetimes short and rely on re-authorization, or layer a capability system at the application layer.

Prompt injection

HDP mitigates but does not prevent prompt injection. An HDP-aware agent SHOULD refuse to extend a chain with an action_summary that contradicts scope.intent, though the protocol cannot enforce this semantically. The mitigation is evidentiary: each delegation action is recorded as a signed hop, supporting post-hoc detection.

Key management

All guarantees depend on confidentiality of the issuer’s Ed25519 private key. Implementations MUST store private keys in a secrets manager, HSM, or equivalent, never in source code, configuration files, or environment variables in production; MUST use distinct key pairs per environment; and MUST support rotation by issuing new tokens under a new kid while retaining the old key until every token signed with it has expired.

AAppendix A: complete token example#

{
  "hdp": "0.1",
  "header": {
    "token_id"   : "550e8400-e29b-41d4-a716-446655440000",
    "issued_at"  : 1711483200000,
    "expires_at" : 1711569600000,
    "session_id" : "sess-20260326-abc123",
    "version"    : "0.1"
  },
  "principal": {
    "id"           : "usr_alice_opaque",
    "id_type"      : "opaque",
    "display_name" : "Alice Chen"
  },
  "scope": {
    "intent"              : "Analyze Q1 sales data and report.",
    "authorized_tools"    : ["database_read", "file_write"],
    "data_classification" : "confidential",
    "network_egress"      : false,
    "persistence"         : true,
    "max_hops"            : 3
  },
  "chain": [
    {
      "seq"            : 1,
      "agent_id"       : "orchestrator-v2",
      "agent_type"     : "orchestrator",
      "timestamp"      : 1711483260000,
      "action_summary" : "Decompose task; delegate to sub-agents.",
      "parent_hop"     : 0,
      "hop_signature"  : "base64url-sig-1..."
    },
    {
      "seq"            : 2,
      "agent_id"       : "sql-agent-v1",
      "agent_type"     : "sub-agent",
      "timestamp"      : 1711483320000,
      "action_summary" : "Execute read query on sales database.",
      "parent_hop"     : 1,
      "hop_signature"  : "base64url-sig-2..."
    }
  ],
  "signature": {
    "kid"   : "alice-signing-key-v1",
    "alg"   : "Ed25519",
    "value" : "base64url-root-sig..."
  }
}