HDP: The Binding Layer for AI Agent Governance

The Human Delegation Provenance Protocol (HDP) is Helixar's foundational protocol for verifiable delegation provenance in agentic systems. It creates a portable, signed record that runs from the authorising human or organisational principal, and the request they made, through every agent acting under that mandate. Each hop states how that agent read the task it was given. Any auditor can verify where the request originated, which scope was declared, how the task travelled through the agent chain, and where each agent's reading of it diverged, using only the issuer's public key.

HDP works with the enterprise security stack. OAuth protects resource access. IAM establishes principals and permissions. SPIFFE authenticates workloads. Capability systems express delegable rights. Policy engines decide. Audit systems retain events. HDP binds the evidence from these layers to the human request, so a reviewer works from one consistent account rather than a collection of disconnected credentials and logs.

Helixar 360 makes the decisions. It manages policy, evaluates agent behaviour at the moment of action, applies graduated enforcement, routes designated actions for human approval, contains risky workloads, and writes each decision into the HDP record and a tamper-evident evidence trail. The division is strict. Since revision -03 of the HDP Internet-Draft, an HDP token must not be an input to any access decision. HDP answers what was asked and how each agent understood it. Helixar 360 decides what is allowed now.

HDP is the binding layer

The first article in this series, AI Agents Have Identities. What They Need Is Verifiable Authority, defines the evidence contract for a governed agent action. HDP turns the evidence half of that contract into a protocol.

An HDP token carries the principal, their request in natural language, the declared tools and resources, data classification, egress and persistence conditions, the session, and the recorded hop chain, with expiry and recording depth as record metadata. The declared scope is fixed after issuance, so a downstream agent cannot silently rewrite what the human said. Ed25519 signatures over every hop and the root make alteration visible and allow the recorded chain to be verified offline.

The protocol creates a stable evidence spine across otherwise heterogeneous systems:

Identity says which workload is presenting the request. A resource credential says what the target service is prepared to accept. Enterprise policy, held by Helixar 360, says what this task permits. Helixar 360 evaluates all three before the governed action proceeds. HDP records the request behind the action and how every agent along the way read it, so the decision can later be checked against what the person actually wanted.

OAuth and OIDC provide resource access

RFC 6749 defines delegated access to protected resources, and OIDC adds end-user authentication semantics. RFC 8693 OAuth Token Exchange can distinguish a subject from a current actor and retain prior actors through nested act claims. RFC 9396 Rich Authorization Requests supports structured transaction details rather than only coarse scope strings.

These are strong resource-authorisation mechanisms, and they are where task-level authorisation belongs. HDP adds something they do not carry: a consistent record of the human request and each agent's reading of it that survives multiple token exchanges, resource servers, model providers, and agent frameworks. The OAuth token can remain short-lived and audience-specific while the HDP record accumulates the whole journey for audit.

Sender-constrained mechanisms such as DPoP strengthen the presenter binding of access tokens. HDP complements that assurance on the evidence side. The gateway records which presenter it authenticated alongside the token it received, and an auditor compares that presenter with the agent named in the final HDP hop. A mismatch exposes a shorter, earlier copy of the record presented by someone else.

IAM and SPIFFE establish trusted actors

IAM manages people, service identities, roles, attributes, federation, sessions, and permissions. AWS source identity, for example, can persist across role chaining and appear in CloudTrail. SPIFFE provides verifiable workload identities across dynamic infrastructure.

HDP uses these identity foundations rather than competing with them. A principal or agent identifier in an HDP record becomes operationally valuable when Helixar 360 can resolve it to the authenticated person, workload, team, and policy domain. HDP then preserves why that actor was operating, who delegated to it, and how it understood the task. The identifiers themselves can be opaque: accountability in a delegation chain is recursive, so each delegator only needs to be able to identify the party it delegated to.

Across organisations, the same separation is useful. Federation establishes which identities and issuers a receiving domain trusts, and the resource owner's own access control decides whether to allow the operation. The HDP record shows the receiving domain, and later its auditors, the request and the readings behind that operation.

Capability systems express delegable rights

Capability systems provide valuable machinery for delegating and narrowing resource rights. SPKI certificate theory addresses authorisation and delegation. Macaroons add contextual caveats. Biscuit combines public-key verification, chained blocks, attenuation, and a Datalog-based authorisation language. UCAN represents capabilities and proof chains.

Capability certificates presented at a resource are a strong record of the authority each agent exercised. What they do not record is what the principal asked for or how each agent read the task. HDP supplies exactly that part. Helixar 360 joins them at the action boundary: the capability and enterprise policy decide whether the operation proceeds, and the HDP record holds the request and the reading of it that the operation served.

Revision -03 of the HDP draft takes the composition a step further. On a deployment that already uses UCAN, the HDP content can travel inside the certificates' own signed meta field instead of a separate token. The principal's request goes in the first certificate the principal or their agent signs, and each delegating agent's reading of the task goes in every certificate below it. Each reading is then signed by the agent that wrote it, using the capability system's existing keys. A similar form is proposed for ZCAP-LD.

This composition is stronger than asking one token to carry every concern. Resource systems retain their native authorisation model, while HDP supplies a framework-independent record of intent and interpretation that policy, enforcement, and audit controls can all refer to.

Helixar 360 makes the decisions, HDP keeps the record

A signature makes the mandate and delegation chain verifiable. Helixar 360 makes governance operational.

Its policy-management layer versions the enterprise rules for approved tools, resources, data classes, egress, persistence, delegation depth, and approval thresholds. Policy changes and exceptions remain governed decisions with their own evidence.

At runtime, Helixar 360 evaluates the authenticated actor, resource credential, exact operation, arguments, session, current policy, and behavioural context. The response is graduated according to risk and organisational choice:

1. Observe the action and record it as a hop in the task's HDP record.
2. Alert the responsible owner when behaviour crosses a policy threshold.
3. Require approval when the action needs a fresh human decision.
4. Block or contain when the request conflicts with authority, policy, or behavioural controls, and record the blocked attempt rather than suppressing it.

This is the architectural distinction that makes HDP valuable. The protocol provides portable cryptographic binding of evidence. Helixar 360 provides policy semantics, live behaviour analysis, enforcement, lifecycle decisions, and accountable human intervention.

Audit becomes an authority record, not only an activity log

Conventional logs are excellent at recording who called which API, when, with which credential, and what the system returned. HDP lets Helixar 360 connect those events to the human request and the delegation path behind them.

Each governed event can carry the HDP reference, authenticated workload, request digest, policy version, decision, response tier, approval record, and execution result. Helixar 360 signs and hash-links these events into a tamper-evident trail that can be exported with an offline verifier. An auditor can therefore inspect both sides of the control question: what the agent did, and the request and readings behind each action Helixar permitted, challenged, or stopped.

The HDP record also shows a failure that no permission log can. An action can stay inside every policy and still drift a long way from what the person asked for, like an intern sent out for a coffee who comes back with a pound of beans. Every step was allowed, so nothing was denied. Because HDP keeps the request beside each agent's reading of it, a reviewer can see where the task changed and at which hop.

HDP also provides portability. When an agent crosses provider or framework boundaries, the record travels with the task rather than remaining trapped in one platform's session logs. The downstream party receives a consistent record, and the final evidence pack can join the complete governed journey.

A clear division of responsibility

The following matrix shows how the layers reinforce one another. The final column describes HDP's focused role as the evidence binding and Helixar 360's role as the control point.

The value is the join. Without HDP, each column can remain technically sound while the human request is reconstructed differently at every boundary. With HDP, every boundary writes into one signed record of the same request.

HDP v0.1 is focused by design

The published HDP draft-03, dated 6 October 2026, documents the v0.1 protocol developed by Helixar. It is currently an individual Internet-Draft, and HDP remains an open Helixar protocol regardless of the outcome of the IETF process.

Its design choices support predictable verification. The declared scope is fixed after issuance, protecting the human request from silent downstream mutation. A governed issuer signs the root and each recorded hop, giving every auditor one consistent trust anchor across heterogeneous agents. An optional recording depth bounds how much of a chain one record holds, and how much of an organisation's structure it exposes, while the agent at the last recorded hop remains accountable for anything delegated further. Expiry and session are kept as record metadata, so an auditor can see when a hop was recorded after the authorised period ended. Integrity verification runs in five steps (version, root signature, hop sequence, hop signatures, recorded depth) and needs nothing but the issuer's public key, so a record verifies the same way on the day it is written and years later.

Revision -03 removed the earlier live-acceptance checks after review on the W3C Credentials Community Group list. The reviewer's point was that a token relied on before an action becomes a second access control mechanism running beside the system's own, which is a well-known hazard. The token structure and signature payloads did not change. What changed is that the record is now read only at audit, and that is where its value lies.

Dynamic decisions belong in Helixar 360. If scope, ownership, risk, or approval changes, the platform can end the session, require reauthorisation, issue a superseding HDP record that links to the original, or deny the action under current policy. If a child agent needs a narrower operating boundary, Helixar 360 applies it at every action and records the decision. This separation keeps the HDP wire format compact and framework-independent while the control plane remains responsive to current enterprise state.

Helixar 360 establishes coverage operationally by placing enforcement on governed paths to models, tools, credentials, data, and egress. Each path decides under policy, appends the action to the HDP record, and emits independent evidence. The result is a closed loop: authority is decided, enforced, recorded, and independently verifiable.

The Helixar 360 implementation pattern

Consider an agent asking a deployment API to release a service version. The end-to-end pattern is:

1. Authenticate. Helixar 360 resolves the human, agent, and workload identities through the enterprise identity stack.
2. Validate access. The deployment credential or capability is checked for audience, lifetime, and resource permission.
3. Evaluate policy and behaviour. Helixar 360 compares the exact repository, environment, artefact digest, arguments, behavioural signals, and current state with the approved release mandate as enterprise policy holds it.
4. Enforce. The platform observes, alerts, requests approval, permits the bound operation, or blocks and contains the workload.
5. Record. Helixar 360, sitting outside the agent, appends the request, its reading of the task, and the outcome to the release's HDP record as a signed hop.
6. Prove. The request, HDP reference, policy version, human decision, enforcement response, and execution result enter the signed audit chain.

This pattern gives each established control its proper role and gives HDP a distinct one. HDP is the signed record that keeps the person's request attached to the work as it moves from a person to one agent, then another, then a tool. Helixar 360 is the system that continuously governs what that work is allowed to do.

Open protocol, durable architecture

Helixar published HDP openly because delegation provenance must be verifiable across organisational and vendor boundaries. The IETF process can improve interoperability and invite independent scrutiny, but Helixar's architecture does not depend on standards adoption. HDP is implemented as the provenance foundation around which Helixar 360 is built.

That work is pioneering a practical category for agentic systems: portable, human-rooted delegation provenance joined directly to runtime governance. Adjacent standards and technologies strengthen the ecosystem, and HDP gives them a common way to connect the authorising human to every action an agent took on their behalf.

The final article in this series, The Hugging Face Incident Through an Authority-Evidence Lens, applies this architecture to public incident reporting. It shows how HDP and Helixar 360 would turn an otherwise fragmented set of identities, credentials, actions, and logs into a governed control path with a single signed record behind it.