HDP
Human Delegation Provenance Protocol
An open standard for recording, signing, and verifying human authorization in agentic AI systems. When a human delegates to an AI agent, HDP creates a cryptographically verifiable record of what was authorized, which propagates across every subsequent delegation hop.
Status
DRAFT — Open for comment
Version
0.1.0
License
CC BY 4.0 — Free to implement
Signing
Ed25519 (required) / ES256
Authors
Helixar Labs
IETF Draft
draft-helixar-hdp-agentic-delegation-00IETF Individual Draft — March 2026
HDP has been submitted to the IETF as an individual informational draft: draft-helixar-hdp-agentic-delegation-00. The full title is “Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems.” The architectural comparison with the Intent Provenance Protocol (IPP, draft-haberkamp-ipp-00) is on the formal record. Neither draft has been adopted by a working group. That conversation is now open. Standards practitioners are encouraged to engage via the IETF datatracker.
The Problem HDP Solves
Modern AI agents act autonomously: they call APIs, execute code, spawn sub-agents, and move data across systems. A single human instruction at the start of a session can trigger dozens of downstream actions. By the time any individual action executes, nothing in the execution context carries a verifiable record of what the original human authorized.
This is the delegation gap. Security systems cannot distinguish authorized agent behavior from compromised agent behavior. Audit trails are incomplete. Accountability is impossible.
Without HDP
- ✕No record of what the human authorized
- ✕No way to verify actions are within intended scope
- ✕No tamper-evident chain of delegation
- ✕Security tools have no baseline to compare against
With HDP
- ✓Signed record of human intent at authorization time
- ✓Scope envelope every agent hop can verify
- ✓Hash chain detects tampering at any hop
- ✓Verifiable provenance for audit and enforcement
How HDP Compares
Every existing approach addresses part of the delegation problem. None address all of it. HDP is designed to fill the gap, not replace the surrounding stack.
Protocol Design
HDP is infrastructure, not a policy engine. It deliberately stops at capture, structure, and verification. What systems do with delegation context — enforcement, scoring, threat detection — is explicitly out of scope.
Minimal
Captures only what is necessary to establish delegation provenance. No opinions on enforcement.
Verifiable
Ed25519-signed tokens. Any party in the chain can independently verify integrity.
Propagatable
Tokens flow through agent hops without losing integrity. Each hop extends the chain.
Framework-agnostic
No dependency on any specific LLM provider, agent framework, or orchestration system.
Human-readable
Core schema is plain JSON, comprehensible without tooling. Complexity lives in the signing layer.
Open
CC BY 4.0. Freely implementable without licensing constraints or vendor lock-in.
Analogy
TLS provides encrypted transport. It does not decide what content is acceptable. JWT provides signed identity claims. It does not decide who gets access. HDP provides delegation provenance. It does not decide which agent actions are acceptable. That is a feature, not a limitation.
Token Schema
An HDP Token is a JSON object with four top-level sections plus a signature. The root is immutable once signed. The chain is appendable: each delegation hop adds a record without modifying what came before.
.header
token_idUnique token identifier (UUID). Used for deduplication and revocation.
session_idTies the token to a specific agentic session. Checked on every verification.
issued_atUnix timestamp (ms) of token creation.
expires_atExpiry timestamp. Implementations must reject expired tokens. Max 24h recommended.
versionHDP protocol version. Must match top-level hdp field.
.principal
idPrincipal identifier. Format is implementation-defined (UUID, email, DID). Required.
id_typeIdentifier type: email, uuid, did, poh, or opaque. Required.
poh_credentialOptional. Proof of Human nullifier hash (e.g. World ID) binding a verified human identity.
display_nameOptional. Human-readable name for audit trail readability only. Not used in verification.
.scope
intentPlain-language statement of what the human instructed. Required. Populated from actual human input, not an LLM summary.
authorized_toolsTool identifiers the principal explicitly approved. Wildcard * means all tools.
authorized_resourcesResource patterns (URIs, paths, API base URLs) the agent may access. Glob patterns permitted.
data_classificationHighest data sensitivity level authorized: public, internal, confidential, or restricted.
network_egressWhether the agent may make outbound network connections. Boolean. Required.
persistenceWhether the agent may write persistent state. Boolean. Required.
max_hopsOptional. Maximum delegation hops before re-authorization is required.
constraintsStructured constraint objects: time_window, resource_limit, action_count, or custom.
.chain[ ]
seqHop sequence number. Starts at 1, increments by 1. Gaps indicate a removed hop record.
agent_idIdentifier for the agent taking this hop.
agent_typeType: orchestrator, sub-agent, tool-executor, or custom.
agent_fingerprintOptional. Hash of agent model, version, and tool manifest at hop time. Enables substitution detection.
timestampUnix timestamp (ms) when this hop occurred.
action_summaryPlain-language description of what this agent was instructed to do.
parent_hopseq value of the spawning hop. 0 if spawned directly by the principal.
hop_signatureSignature over all hop records with seq up to and including this one, plus the root signature. Creates a hash chain.
Example Token
{
"hdp": "0.1",
"header": {
"token_id": "tok_01HXYZ...",
"session_id": "sess_01HABC...",
"issued_at": 1743000000000,
"expires_at": 1743086400000,
"version": "0.1"
},
"principal": {
"id": "user-uuid-xxxx",
"id_type": "uuid"
},
"scope": {
"intent": "Research recent MCP vulnerabilities and summarize findings.",
"authorized_tools": ["web_search", "read_file"],
"authorized_resources": ["https://cve.mitre.org/*"],
"data_classification": "internal",
"network_egress": true,
"persistence": false,
"max_hops": 3,
"constraints": [
{ "type": "action_count", "params": { "tool": "web_search", "max_count": 20 } }
]
},
"chain": [
{
"seq": 1,
"agent_id": "orchestrator-01",
"agent_type": "orchestrator",
"timestamp": 1743000001000,
"action_summary": "Searching CVE database for MCP server vulnerabilities.",
"parent_hop": 0,
"hop_signature": "..."
}
],
"signature": {
"alg": "Ed25519",
"kid": "key-1",
"value": "base64url-encoded-signature"
}
}How Signing Propagates
Each delegation hop extends the chain by appending a new hop record signed over all prior state. Any verifier can independently reconstruct and check the entire chain without contacting any external service.
Verification Steps
A verifier must perform these steps in order. Passing all steps is required to return VALID.
Parse the token and confirm the hdp version field is recognized.
Check header.expires_at against the current timestamp. Reject expired tokens.
Verify the root Ed25519 signature over the canonical JSON of header, principal, and scope.
For each hop record in chain order: verify the hop_signature over the cumulative chain state.
Confirm that seq values are contiguous and begin at 1. A gap indicates a removed hop.
If scope.max_hops is set, confirm chain length does not exceed it.
Check header.session_id against the current session identifier. A mismatch is a verification failure even if cryptographic checks pass.
If a poh_credential is present, optionally verify it against the PoH provider endpoint.
Transport and Integration
HDP tokens travel alongside agent invocations. The transport mechanism is framework-specific, but HDP recommends standard field names for common agent frameworks.
HTTP API Calls
X-HDP-Token: <base64url-encoded token> # Token-by-reference (large tokens): X-HDP-Token-Ref: <token_id>
Agent Frameworks
Scope Boundaries
These are permanent design decisions, not temporary gaps. Understanding what HDP does not do is as important as understanding what it does.
In Scope
- ✓Token schema definition
- ✓Delegation chain structure and extension rules
- ✓Signing and verification mechanisms
- ✓Transport and propagation recommendations
- ✓PoH credential binding
- ✓Extensibility namespacing (x- prefix)
Out of Scope (by design)
- ✕Enforcement decisions (block, flag, or permit)
- ✕Threat scoring or risk assessment
- ✕Anomaly detection or behavioral analysis
- ✕Key management infrastructure
- ✕Agent identity registration
- ✕Token revocation infrastructure
Implementation Guidance
Recommendations for implementers. These are non-normative guidance, not requirements.
Start in observe mode
Generate and propagate tokens, log verification results, but do not enforce rejection on missing or invalid tokens. This mirrors ATP observe-mode defaults and allows calibration before enforcement disrupts legitimate workflows.
Issuance belongs in the framework, not the model
Tokens should be issued by the agent framework or orchestration platform at session initialization. The LLM receives the token as part of its context. The model consuming authorization context should not be the same component generating it.
Verify at every hop, not just at session start
A token that was valid at hop 1 may have been tampered with by hop 3. Ed25519 verification runs in under a millisecond. There is no performance justification for skipping it on internal hops.
Treat natural language fields as untrusted
The scope.intent and hop.action_summary fields must not be passed to an LLM without explicit sanitization. The signature proves a field has not been altered. It does not validate the field content against prompt injection.
Set conservative expiry and action limits
A task expected to complete in 10 minutes should not have a 24-hour token. Use scope.constraints of type action_count for tools with destructive or irreversible consequences such as file deletion, financial transactions, or external communications.
Design Decisions
Key design questions from v0.1. Resolved items are closed. Open items are active areas for community discussion and implementation feedback via the GitHub repository.
Resolved
Key management
Resolved in v0.1. KeyRegistry (src/crypto/registry.ts) provides kid-to-public-key mapping with well-known endpoint support, 32-byte key validation, and Ed25519 algorithm guardrails. Import/export utilities included for key distribution.
Streaming sessions / Re-authorization
Resolved in v0.1. issueReAuthToken() handles long-running sessions. Parent token linkage is covered by the root signature, scope can evolve, and fresh hop budgets are issued without breaking chain integrity.
Multi-principal delegation
Resolved for sequential approval. verifyPrincipalChain() walks parent_token_id chains and enforces session_id consistency across chains. Simultaneous threshold signing (FROST/Schnorr via CoAuthorizationRequest) is on the v0.2 roadmap.
Standardization path
Resolved. HDP has been submitted to the IETF as draft-helixar-hdp-agentic-delegation-00 (March 2026). The architectural comparison with IPP is on the formal record. Neither draft has been adopted by a working group yet.
Open for community input
Offline verification
How should tokens be verified in fully air-gapped environments where well-known key endpoints are also unreachable? Pre-distributed public key bundles are the likely answer, but the mechanism is not yet specified.
Agent anonymity
In some architectures, agent identities may not be stable across invocations. Should HDP define a mechanism for anonymous-but-accountable agent participation in the chain?
Contribute to HDP
HDP is a v0.1 draft open for community review. We are looking for three things: feedback on where the design is wrong or incomplete — particularly the COMPARISON.md analysis of IPP; implementation reports from agent frameworks and security tools; and engagement on the IETF draft (draft-helixar-hdp-agentic-delegation-00), including working group suggestions and architectural feedback.
HDP records the authorization. Helixar detects what happens next.
Deploy HDP in your agent framework. Let Helixar score whether agents stayed within scope, flag drift, and stop what should not have started.
See Helixar in action