---
title: "Human Delegation Provenance"
description: "Credited research and open-specification work on keeping human authorisation verifiable across chains of autonomous agents."
date: "2026-08-28"
updated: "2026-08-29"
type: research
topics:
  - "AI Governance & Security"
  - "Agentic Systems"
canonical: "https://dalugoda.com/hdp"
series: "Research notes"
affiliation: "Helixar research / open specification"
sources:
  - "https://helixar.ai/about/labs/hdp/"
  - "https://arxiv.org/abs/2604.04522"
  - "https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/"
  - "https://helixar.ai/research/"
---

## Working description

**Human Delegation Provenance (HDP)** is an open specification for recording, signing and verifying the human authorisation that sits behind an action taken by an autonomous agent. It is Helixar research and open-specification work, published through Helixar and released under the Apache 2.0 licence.

This page is independent context. It is not the specification, it does not claim sole authorship, and it should be read alongside the canonical material linked in the final section.

> HDP tries to answer one narrow question: which human authorised this action, under what declared scope, and through which chain of agent hops did the instruction actually arrive.

### In brief

- HDP defines a signed JSON token that binds a human authorisation event to a session and to a declared scope.
- Every delegation step, called a hop, is appended to a chain and signed over the entire history that came before it.
- Verification is fully offline: a verifier needs the issuer's Ed25519 public key, the current session identifier and the current time.
- The design goal is tamper evidence and provenance, not runtime enforcement of what an agent is allowed to do.
- The specification is explicit about what it does not solve, including chain truncation, mid-chain revocation and semantic scope checking.
- HDP is published as an arXiv preprint, an active individual IETF Internet-Draft and a reference implementation. It is not an adopted IETF standard.

## 1. The problem HDP addresses

Agentic systems have stopped being single-model call and response. A human instructs an orchestrator, the orchestrator decomposes the task and delegates to sub-agents, and those sub-agents invoke tool-execution agents with access to file systems, databases and external APIs.

The paper describes the structural consequence directly: when authorisation passes through that many layers, "the originating human authorization becomes progressively disconnected from terminal actions."

That disconnection has three practical effects, as set out in the preprint:

- Post-hoc audits cannot reconstruct who approved what, and when.
- A downstream agent has no runtime signal that distinguishes a legitimate delegated instruction from an injected one.
- Accountability for an autonomous action cannot be attributed to a specific human authorisation event.

The third effect is the one that turns an engineering inconvenience into a governance problem. If an organisation cannot point to the authorisation behind an action, it cannot answer a regulator, an auditor or a customer with anything better than an assertion.

## 2. Why logs are not evidence of authority

Most agentic stacks already emit a great deal of telemetry. Traces, spans, prompt records and tool-call logs make it possible to describe what happened in considerable detail.

The trouble is that a log is a narrative written by the same system whose behaviour is in question. It records what a component reported, not what a principal permitted, and nothing in it resists being edited, reordered or selectively omitted after the fact.

HDP's response is to move the record out of the observability layer and into a signed artefact that travels with the work:

- The root signature covers the header, the principal and the declared scope, so the terms of the authorisation cannot be rewritten later.
- Each hop signature covers all prior hops together with the root signature, so retroactive modification of any hop breaks verification for that hop and every hop after it.
- Verification requires no cooperation from the system that produced the record.

That is a meaningful shift. A log tells you what a component claims it did, whereas a verified HDP chain tells you what a holder of the issuer's private key committed to at the time.

## 3. What HDP proposes

An HDP token is a JSON object with six top-level fields, described in the v0.1 specification as follows:

- `hdp`, the protocol version string
- `header`, carrying the token identifier, issuance and expiry timestamps, and the session binding
- `principal`, identifying the authorising human
- `scope`, recording the authorised intent and its constraints
- `chain`, an append-only array of delegation hops
- `signature`, carrying the root Ed25519 signature and its key identifier

The `principal` object requires an identifier and an identifier type. Supported types include opaque application-defined identifiers, email, UUID, W3C DID and a proof-of-humanity credential, and the specification deliberately mandates no single identity model.

The `scope` object records what the human actually authorised. Required fields cover the free-form intent statement, a data classification, whether network egress is permitted and whether persistence is permitted, with optional fields for authorised tools, authorised resources and a maximum hop count.

Each entry in `chain` records a sequential index starting at one, the agent identifier and type, a timestamp, a human-readable action summary, a parent hop index and a hop signature. Agents must not remove or modify existing entries, and gaps in the sequence are a protocol violation.

The cryptography is intentionally unexciting. Signatures are Ed25519 (RFC 8032), serialisation is canonical JSON per RFC 8785, and binary fields are base64url encoded per RFC 4648.

The one subtle construction is the hop signing payload. It is built as an array containing the root signature value, every previously signed hop with its signature intact, and the new hop without its signature, which is what makes each hop cryptographically dependent on the whole history preceding it.

For transport, tokens move in a dedicated HTTP header or by reference to server-side storage, and the specification states that implementations must not place tokens in URL query parameters. Issuers may publish their public keys at a well-known JSON endpoint.

## 4. What a verifier can check

Verification is a fixed pipeline of seven ordered steps, with rejection on the first failure:

- Check the protocol version
- Check that the token has not expired
- Verify the root signature over the header, principal and scope with an empty chain
- Check hop sequence integrity for gaps, duplicates and parent references
- Verify each hop signature by reconstructing the exact signing payload
- Check the chain length against `max_hops` where it is declared
- Check that the token's session identifier matches the verifier's current session

An optional eighth step validates a proof-of-humanity credential where one is configured.

The property the specification treats as its central architectural claim is that the complete trust state for all of this is the issuer's 32 byte Ed25519 public key, the current session identifier and the current time. No registry lookup, no network call and no third-party trust anchor is needed, which is what makes the scheme usable in air-gapped, edge and latency-sensitive deployments.

The paper reports that Ed25519 verification completes in under 100 microseconds on contemporary hardware, that a ten hop chain verifies in under two milliseconds, and that a ten hop token with typical field values runs to roughly 4 to 8 KB. Those are the paper's own figures rather than independent measurements.

## 5. Threat model and stated limits

The threat model is unusually candid, which is the main reason I think the work is worth reading even for people who never adopt it.

The modelled attacker can inject adversarial content into an agent's input stream, intercept and inspect tokens in transit, replay captured tokens in other sessions, attempt to forge or modify tokens, and attempt to insert fabricated hops into a chain.

The specification explicitly does not model an attacker who holds the issuer's private key, who can break Ed25519 or SHA-512, or who can tamper with the out-of-band session establishment channel. Key compromise is treated as an operational security problem rather than a protocol problem.

Just as important is the list of things HDP states it does not protect:

- Agent behaviour beyond what is recorded in the token
- Semantic correctness of an action relative to the declared scope
- Confidentiality of token contents, since tokens are signed rather than encrypted

The specification puts the boundary in one sentence:

> "HDP is designed to provide provenance and tamper evidence, not runtime enforcement."

The Internet-Draft goes further and names its own gaps. Deleting hops from the end of a chain yields a token that still passes every verification step, so completeness cannot be proven at the protocol level and must be addressed with application-layer receipts or out-of-band commitments. There is no mechanism to revoke authority for a single delegate mid-chain without invalidating the whole token, and a compromised or uncooperative agent can simply decline to append a hop for an action it takes.

On prompt injection, the claim is bounded rather than absolute. An injected action that never extends the chain leaves a detectable gap, and a fabricated hop fails signature verification, but an injected instruction that causes a legitimate agent to record a genuine hop with a misleading action summary is not detectable by the protocol alone.

Version 0.1 also signs every hop with the issuer's key rather than per-agent keys. The paper is direct about the consequence: a hop signature attests that the hop was recorded at the issuer, not that a specific agent produced it. Per-agent key binding is described as planned work.

## 6. Open questions

These are my own, not positions taken by the specification.

- What a workable completeness commitment looks like in practice, given that truncation resistance is pushed to the application layer
- How issuer keys get distributed and rotated across organisational boundaries once chains routinely cross vendors
- Whether per-agent signing, once introduced, adds enough key management burden to erode the offline verification advantage
- Whether an opaque principal identifier satisfies a regulator who wants to know which human approved a specific action
- What the failure mode is when verification fails in production, since the protocol defines rejection but the operational response is left undefined

## 7. Where this meets human-gated delivery

HDP is the cryptographic half of an argument I make elsewhere on this site in operational terms. The [Agentic Sprint](/agentic-sprint) describes a delivery model in which agents execute and humans retain authority over intent, architecture, quality and release.

That model depends on gates being real. A gate that exists only as a step in an orchestration graph is a convention, whereas a gate that produces a signed, verifiable authorisation record is closer to evidence.

The [Autonomous Loop](/autonomous-loop) sharpens the same point from the other direction. Once a system is designed to keep running across many goals without per-step prompting, the human authorisation event becomes rarer and therefore more load-bearing, and the distance between that event and the terminal action grows.

HDP does not resolve the governance question in either model, because it enforces nothing. What it offers is a way to make the authorisation at the top of a long autonomous run auditable at the bottom of it.

## 8. Status, attribution and how to read the canonical material

HDP is Helixar research and open-specification work. The normative specification, the reference implementations in TypeScript and Python, and the JSON Schema are published by Helixar under the Apache 2.0 licence, and the specification is currently at v0.1 and open for comment.

The standardisation status needs stating plainly. The work exists as an active Internet-Draft, `draft-helixar-hdp-agentic-delegation`, currently at revision 01, authored by Asiri Dalugoda of Helixar Limited and last updated in August 2026. It is an individual submission, it has not been adopted by any IETF working group, and it is not an adopted IETF standard.

To read the primary sources:

- The [HDP specification page at Helixar](https://helixar.ai/about/labs/hdp/) for the normative token structure, signing procedures and verification pipeline
- The [arXiv preprint 2604.04522](https://arxiv.org/abs/2604.04522) for the threat model, security analysis and the comparison against OAuth 2.0 Token Exchange, JWT, UCAN and the Intent Provenance Protocol
- The [IETF Internet-Draft](https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/) for the normative wording, security considerations and IANA requests
- The [Helixar research index](https://helixar.ai/research/) for the wider publication record

A companion specification, HDP-P, extends the model to physical AI agents such as robots and vehicles, adding an irreversibility classification and pre-execution authorisation checks for actions that cannot be undone. It is listed in the author's publication record as an SSRN companion to HDP and is best read there rather than summarised here.

Helixar has since published a press piece on HDP-P and physical AI agents, [When AI Agents Control Physical Systems, a Prompt Injection Becomes a Physical Event](https://helixar.ai/press/gemma-4-hdp-p-physical-ai-agents/), arguing that Gemma 4 running offline on edge hardware with native function calling closes the gap between an agent that can act and one that can actuate. It is accompanied by an [interactive demonstration on Hugging Face](https://huggingface.co/spaces/helixar-ai/hdp-physical-demo), where a simulated robot arm is sent an adversarial override command and a pre-execution guard rejects it as a Class 3 action before any motion. Both are published by Helixar; the demonstration is released under the Apache 2.0 licence.

I contributed to this work, so treat this page as informed context rather than neutral review. Where this note and the specification disagree, the specification is correct.

## Sources and attribution

Affiliation: Helixar research / open specification.

Human Delegation Provenance (HDP) is Helixar research and open-specification work. The canonical research and specification are published through Helixar. This page is an independent context page; it does not claim sole authorship or describe HDP as an adopted IETF standard.

- [Canonical HDP research and specification from Helixar](https://helixar.ai/about/labs/hdp/)
- [Reference](https://arxiv.org/abs/2604.04522)
- [Reference](https://datatracker.ietf.org/doc/draft-helixar-hdp-agentic-delegation/)
- [Helixar research index](https://helixar.ai/research/)