Helixar Labs
Open Protocolv0.1 Draft·CC BY 4.0·March 2026

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-00

IETF 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.

Offline verification
No central dependency
Multi-hop chain
Cryptographic signing
Human intent capture
No required attribution
Framework agnostic
Score
HDPThis protocol
7/7
IPPdraft-haberkamp-ipp-00
3.5/7
OAuth / JWTRFC 6749 / RFC 7519
5/7
Audit logsPost-hoc only
3.5/7
Prompt loggingPlain text capture
4.5/7
LegendFully supportedPartialNot supportedFull comparison in COMPARISON.md →

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_id

Unique token identifier (UUID). Used for deduplication and revocation.

session_id

Ties the token to a specific agentic session. Checked on every verification.

issued_at

Unix timestamp (ms) of token creation.

expires_at

Expiry timestamp. Implementations must reject expired tokens. Max 24h recommended.

version

HDP protocol version. Must match top-level hdp field.

.principal

id

Principal identifier. Format is implementation-defined (UUID, email, DID). Required.

id_type

Identifier type: email, uuid, did, poh, or opaque. Required.

poh_credential

Optional. Proof of Human nullifier hash (e.g. World ID) binding a verified human identity.

display_name

Optional. Human-readable name for audit trail readability only. Not used in verification.

.scope

intent

Plain-language statement of what the human instructed. Required. Populated from actual human input, not an LLM summary.

authorized_tools

Tool identifiers the principal explicitly approved. Wildcard * means all tools.

authorized_resources

Resource patterns (URIs, paths, API base URLs) the agent may access. Glob patterns permitted.

data_classification

Highest data sensitivity level authorized: public, internal, confidential, or restricted.

network_egress

Whether the agent may make outbound network connections. Boolean. Required.

persistence

Whether the agent may write persistent state. Boolean. Required.

max_hops

Optional. Maximum delegation hops before re-authorization is required.

constraints

Structured constraint objects: time_window, resource_limit, action_count, or custom.

.chain[ ]

seq

Hop sequence number. Starts at 1, increments by 1. Gaps indicate a removed hop record.

agent_id

Identifier for the agent taking this hop.

agent_type

Type: orchestrator, sub-agent, tool-executor, or custom.

agent_fingerprint

Optional. Hash of agent model, version, and tool manifest at hop time. Enables substitution detection.

timestamp

Unix timestamp (ms) when this hop occurred.

action_summary

Plain-language description of what this agent was instructed to do.

parent_hop

seq value of the spawning hop. 0 if spawned directly by the principal.

hop_signature

Signature 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.

delegation-chain
HumanTokenAgent AAgent BAgent CsignsdelegatesdelegatesdelegatesEd25519 root sighop sig 1hop sig 2hop sig 3verified offline · no registry · no network

Verification Steps

A verifier must perform these steps in order. Passing all steps is required to return VALID.

1

Parse the token and confirm the hdp version field is recognized.

2

Check header.expires_at against the current timestamp. Reject expired tokens.

3

Verify the root Ed25519 signature over the canonical JSON of header, principal, and scope.

4

For each hop record in chain order: verify the hop_signature over the cumulative chain state.

5

Confirm that seq values are contiguous and begin at 1. A gap indicates a removed hop.

6

If scope.max_hops is set, confirm chain length does not exceed it.

7

Check header.session_id against the current session identifier. A mismatch is a verification failure even if cryptographic checks pass.

8

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

LangGraph:hdp_token in agent metadata
AutoGen:hdp_token in message metadata
CrewAI:hdp_token in task context
MCP:hdp_token as top-level session context field

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