HDP: The Open Protocol That Gives AI Agents a Verifiable Chain of Authority

Today, Helixar Labs is publishing the Human Delegation Provenance Protocol (HDP), a v0.1 open specification for recording, signing, and verifying human authorization in agentic AI systems. HDP is free to implement, CC BY 4.0 licensed, and available now on GitHub.

It is, to our knowledge, the first open protocol designed to close the delegation gap without a central dependency.

An IETF individual draft addressing the same problem, the Intent Provenance Protocol (IPP, draft-haberkamp-ipp-00), was published the same month. We reviewed it carefully. The problem diagnosis is correct. The architectural choices are not deployable in the environments where this matters most.

The rest of this article explains what HDP does differently and why those differences are not incidental.

The Problem: Authorization Without a Record

Modern AI agents do not just answer questions. They book meetings, execute code, move files, call external APIs, and instruct other agents to do the same. A single human instruction at the start of a session can trigger dozens of downstream actions across multiple systems, none of which carry any verifiable record of what the original human intended.

This is not a theoretical concern. The OWASP Top 10 for Agentic Applications, published in 2026, lists Agent Goal Hijack and Identity and Privilege Abuse among the most critical risks in deployed agentic systems.¹ Both of these attacks are made significantly easier when there is no structured record of what the human actually authorized in the first place.

Research from Galileo AI, published in December 2025, found that in simulated multi-agent environments a single compromised agent poisoned 87% of downstream decision-making within four hours.² Research from Lakera AI, published the month before, demonstrated that indirect prompt injection via poisoned data sources can corrupt an agent's long-term memory across sessions, causing it to behave as if it holds authorization it was never granted.³ In both cases, the attack works in part because there is nothing to compare the agent's behavior against. There is no ground-truth record of what was authorized.

Why Existing Standards Do Not Solve This

The absence of a delegation provenance standard is not an oversight. It is a gap that emerged because the problem is genuinely new. Agentic AI systems did not exist at the scale or capability level where this gap matters until very recently.

The existing approaches each solve part of the problem but leave the core gap open:

HDP fills the space between identity (who the human is) and enforcement (what to do about violations). It provides a structured, signed, propagatable record that any security layer, audit system, or downstream agent can verify.

Why IPP Does Not Solve This Either

The Intent Provenance Protocol makes the correct diagnosis. The delegation gap is real, and Ed25519-signed hop chains are the right cryptographic primitive for it. But IPP embeds three architectural constraints that disqualify it for most production deployments.

1. The Genesis Seal creates a mandatory central dependency. Every IPP token must contain a cryptographic signature from the protocol's author personally, verified against a public key hosted at ipp.khsovereign.com. Any implementation must include attribution to that individual and to KH Sovereign, Inc. in the software itself. This is not a policy preference — it is an architectural requirement embedded in the token schema. Enterprise legal and procurement teams will not accept a security infrastructure dependency on a named individual at a private company. Regulated industries that require air-gapped deployment cannot use IPP at all. HDP has no Genesis Seal, no required attribution, and no founding key.

2. The revocation registry is a production liveness dependency. IPP requires agents to poll a revocation endpoint at revoke.khsovereign.com every 5 seconds before taking any action. If the registry is unreachable, agents must halt unless an offline grace period is configured. For production agentic systems handling financial workflows, infrastructure automation, or healthcare operations, this is a dependency on a third-party endpoint that did not exist a year ago. A DDoS against one endpoint stops your agents. HDP makes revocation implementation-defined. You own your revocation infrastructure.

3. The domain taxonomy is controlled by a private company. IPP's domain classification system — financial.treasury, healthcare.records.read, infrastructure.compute.provision — is maintained by KH Sovereign, Inc. as steward. New domains require a pull request to their repository. This means the vocabulary of what your agents are authorized to do is governed by a company whose continuity you cannot guarantee. HDP uses namespaced extension fields. Your domain vocabulary belongs to you.

What HDP Is (and Is Not)

HDP is infrastructure, not a policy engine. Its design is deliberately narrow. The protocol covers four things: capturing authorization at the moment a human delegates to an agent, structuring that authorization in a standard schema, signing it so modifications are detectable, and propagating it through every subsequent agent hop. That is it.

HDP is to agentic security what JWT is to authentication: a standard for expressing a claim, not a policy engine. TLS provides encrypted transport without deciding what content is acceptable. HDP provides delegation provenance without deciding which actions are acceptable.

This boundary also defines HDP's relationship to Helixar's commercial products. HDP is the open protocol. Helixar's ATP layer and BearTrap egress enforcement are what you build when you need to act on HDP provenance — scoring session behavior against the authorized scope, enforcing egress limits, detecting scope drift. The protocol is the commons. The security intelligence is the product. These are not in conflict, the same way TLS being open does not prevent companies from building products on top of it.

What HDP does not do is equally important. It does not score risk. It does not detect anomalies. It does not block actions. Those are decisions for the security layer consuming HDP data. This boundary is not a gap in the protocol. It is the protocol's core design decision. A protocol that bundles enforcement opinions becomes a product. A protocol that provides clean, verifiable provenance data becomes infrastructure that any product can build on.

How the Protocol Works

At the moment a human issues an instruction, an HDP Token is created. The token is a signed JSON object with four sections. The header contains a unique token ID, a session ID, and an expiry timestamp. The principal section identifies the human, with optional binding to a Proof of Human credential such as World ID.⁴ The scope section captures what the human authorized: their plain-language intent, the tools they approved, the resources they permitted access to, and whether the agent may write persistent state or make outbound network connections. The chain section starts empty and grows with each delegation hop.

{
  "hdp": "0.1",
  "header": {
    "token_id": "tok_01HXYZ...",
    "session_id": "sess_01HABC...",
    "issued_at": 1743000000000,
    "expires_at": 1743086400000
  },
  "principal": {
    "id": "user-uuid-xxxx",
    "id_type": "uuid"
  },
  "scope": {
    "intent": "Research recent vulnerabilities in MCP servers and summarize findings.",
    "authorized_tools": ["web_search", "read_file"],
    "authorized_resources": ["https://cve.mitre.org/*"],
    "data_classification": "internal",
    "network_egress": true,
    "persistence": false
  },
  "chain": [],
  "signature": { "alg": "Ed25519", "kid": "key-1", "value": "..." }
}

When the orchestrating agent spawns a sub-agent, it appends a hop record to the chain. The hop record includes the sub-agent's identity, a timestamp, a plain-language summary of what it was asked to do, and a signature over the cumulative chain state. This creates a hash chain: tampering with any earlier hop invalidates every hop signature that follows it.

Verification is deterministic. Any party in the chain can check the root signature, verify each hop signature in sequence, confirm that sequence numbers are contiguous, and check the session ID against the active session. Ed25519 verification runs in under a millisecond on modern hardware, so there is no performance justification for skipping it on internal hops.

The Security Considerations

The HDP specification includes a detailed security considerations section (Section 12) covering ten specific threat classes. Several are worth highlighting here, because they illustrate both the protocol's protections and its honest boundaries.

Prompt injection into natural language fields. HDP tokens contain plain language in the scope.intent and hop.action_summary fields. These fields must not be passed to a language model without explicit sanitization. Research published in January 2026 found that adaptive prompt injection strategies achieved success rates above 85% when targeting fields that agents treat as trusted.⁵ The signature in HDP proves a field has not been altered since it was signed. It does not validate the content of the field against injection. Both protections are necessary and neither replaces the other.

Supply chain attacks via MCP servers. Incidents in 2025 demonstrated tool poisoning against MCP servers, where malicious instructions were embedded in tool metadata fields designed to appear as documentation. The GitHub Copilot CVE-2025-53773 (CVSS 9.6) demonstrated that write access to configuration metadata could enable privilege escalation through agent auto-approval mechanisms.⁶ HDP's hop records include an optional agent_fingerprint field for hashing the tool manifest at invocation time, enabling detection of runtime tool substitution.

Autonomous retry and adaptive persistence. Agentic systems can retry failed operations and adapt their approach across extended time windows without human intervention. Research published by Barracuda Networks in February 2026 documented this as a distinct threat class: once compromised, an agent becomes a persistent, adaptive attack vector that does not require continued attacker presence.⁷ HDP addresses this through the scope.constraints field, which supports action count limits per tool and time window constraints. Conservative expiry on the token itself is the simplest mitigation.

Privacy by Design

HDP tokens contain personal data: the principal's identifier, their plain-language intent, and potentially a Proof of Human credential derived from biometric data. The specification treats this seriously.

The UK ICO published detailed guidance on agentic AI and data protection in 2026, flagging that agentic systems create pressure to define authorization broadly, capturing more context than strictly necessary, and identifying this as a compliance risk.⁸ The Spanish AEPD published a technical guide in February 2026 applying GDPR to agentic AI deployments, stating that the organization deploying an agentic system remains the data controller, fully accountable for the system's data processing regardless of the system's autonomy.⁹

HDP's scope design mirrors the GDPR data minimization principle structurally. The authorized_resources field should list the most specific patterns possible. The scope.intent field should capture what the principal wants done, not why. Theprincipal section should use opaque identifiers rather than direct personal identifiers wherever the use case permits. The specification includes a full privacy considerations section (Section 13) covering personal data fields, retention and deletion obligations, cross-border transfer requirements, and data subject rights under GDPR Articles 15 to 22.

MCP-Specific Guidance

Model Context Protocol servers are a particularly high-value integration point for HDP. Every MCP tool call is an agent action that may or may not have verifiable delegation provenance, and MCP servers are currently one of the most active surfaces for prompt injection and tool poisoning attacks.

The specification recommends that MCP servers check for an HDP token in the session context on every invocation, log the presence or absence of HDP context for each tool call, and expose anhdp_required configuration flag that rejects calls without a valid token when enabled. HDP transport via MCP uses the hdp_token field as a top-level field in the MCP session context object, keeping it separate from the prompt content.

Proof of Human Integration

HDP includes optional binding to Proof of Human credentials. Systems like World ID provide selective disclosure: they prove that a unique human exists behind a session without revealing the person's identity.⁴ When a PoH credential is bound to an HDP token, the nullifier hash is included in the root signature, making it tamper-evident.

Neither system requires the other. HDP tokens are valid without a PoH credential. PoH credentials are useful without HDP. When combined, they provide a stronger guarantee: the action was authorized by a Principal who was a verified human, and that authorization is cryptographically traceable across every subsequent delegation hop.

One important caveat: a PoH credential confirms uniqueness and humanness at registration time. It does not confirm that the human was acting willfully, was not coerced, or that their delegation was not manipulated through social engineering.

Implementation Path

The specification recommends that new implementations start in observe mode: generate and propagate tokens, log verification results, but do not enforce rejection on missing or invalid tokens. This follows the same approach as ATP observe modes in security platforms, allowing calibration before enforcement disrupts legitimate workflows.

The token issuance component should be part of the agent framework or orchestration platform, not generated by the LLM itself. The LLM receives the token as part of its context. This is a critical architectural boundary: the model consuming authorization context should not be the same component generating it.

What We Are Asking For

This is a v0.1 draft. The protocol is complete enough to implement and evaluate. It is not finished in the sense that several design questions remain open, and we expect community feedback to shape the path to v1.0.

We are asking for three things from the community. First, review the specification and the COMPARISON.md document on GitHub, which provides a full field-by-field comparison with IPP. Tell us where our analysis is wrong. Second, implement HDP in your agent framework or security tool and share what you find. Third, if you work in agent framework development, security tooling, or standards bodies, the IETF draft (draft-helixar-hdp-agentic-delegation-00) is the right place to engage. Comments on the draft, working group suggestions, and architectural feedback are all useful. The right home for this protocol is a community, not a single company.

The full specification, JSON schema, and example token are available at github.com/Helixar-AI/HDP. The canonical specification URL is helixar.ai/about/labs/hdp.

What Ships With This Article

Words without working code are just positioning. HDP ships with four things:

All CC BY 4.0 licensed. All runnable without creating an account.