HDP: The Binding Layer for AI Agent Governance

The Human Delegation Provenance Protocol (HDP) is Helixar's foundational protocol for verifiable authority in agentic systems. It creates a portable, signed chain from the authorising human or organisational principal to the agents acting under that mandate. Each downstream control can verify where the authority originated, which scope was approved, how it travelled through the agent chain, and whether the token remains valid for the current session.

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 these layers to the human mandate so they operate from one consistent authority context rather than a collection of disconnected credentials and logs.

Helixar 360 operationalises that binding. It manages policy, evaluates agent behaviour at the moment of action, applies graduated enforcement, routes designated actions for human approval, contains risky workloads, and produces a tamper-evident evidence trail. HDP answers where the authority came from and how it reached the current agent. Helixar 360 decides what to do with that authority 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 that contract into a protocol.

An HDP token carries the principal, declared intent, authorised tools and resources, data classification, egress and persistence conditions, validity period, session, maximum delegation depth, and the recorded hop chain. The root scope is fixed after issuance, so a downstream agent cannot silently rewrite the human mandate. Ed25519 signatures and hash-linked hops make alteration visible and allow the recorded chain to be verified offline.

The protocol creates a stable authority 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. HDP binds the request to the authority under which the workload is acting. Helixar 360 evaluates all three against policy and observed behaviour before the governed action proceeds.

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. HDP adds a consistent human-mandate chain that can survive multiple token exchanges, resource servers, model providers, and agent frameworks. The OAuth token can remain short-lived and audience-specific while HDP carries the task-level authority context that every Helixar 360 policy decision can verify.

Sender-constrained mechanisms such as DPoP strengthen the presenter binding of access tokens. HDP complements that assurance by binding the authenticated presenter to the approved task, delegation path, session, and scope. Together they answer both whether the caller controls the credential and whether the requested action belongs to the mandate.

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 chain becomes operationally valuable when Helixar 360 can resolve it to the authenticated person, workload, team, and policy domain. HDP then preserves why that actor is operating, who delegated to it, and which human-approved boundary governs its actions.

Across organisations, the same separation is useful. Federation establishes which identities and issuers a receiving domain trusts. HDP presents the signed authority lineage. The resource owner and Helixar 360 policy decide whether that lineage is acceptable for the requested 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.

HDP focuses on the accountable human origin and the recorded path of agent delegation. A deployment can therefore use capabilities for resource-specific rights and HDP for the common mandate lineage that follows the work across resources. Helixar 360 joins them at the action boundary: the capability must allow the operation, the HDP chain must bind it to approved authority, and enterprise policy must accept the exact behaviour in current context.

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 authority chain that policy, enforcement, and audit controls can share.

Helixar 360 turns HDP evidence into control

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

Its policy-management layer versions the enterprise rules that interpret HDP scope, including 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, HDP chain, exact operation, arguments, session, current policy, and behavioural context. The response is graduated according to risk and organisational choice:

1. Observe the action and attribute it to the verified authority chain.
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.

This is the architectural distinction that makes HDP powerful. The protocol provides portable cryptographic binding. 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 mandate and delegation path that governed them.

Each governed event can carry the HDP token or 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 verified authority under which Helixar permitted, challenged, or stopped it.

HDP also provides portability. When an agent crosses provider or framework boundaries, the authority chain travels with the task rather than remaining trapped in one platform's session logs. The downstream verifier 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 HDP column describes its focused role as the common authority binding used by Helixar 360.

The value is the join. Without HDP, each column can remain technically sound while the human mandate is reconstructed differently at every boundary. With HDP, Helixar 360 can apply one authority model across providers, agents, tools, and evidence systems.

HDP v0.1 is focused by design

The published HDP draft-01 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. Root scope is fixed after issuance, protecting the human mandate from silent downstream mutation. A governed issuer signs the root and each recorded hop, giving verifiers one consistent trust anchor across heterogeneous agents. Maximum-hop limits bound delegation depth. Expiry and session binding keep authority time-limited. The seven-step verification pipeline checks version, structure, signature, temporal validity, session state, chain integrity, and delegation depth offline.

Dynamic decisions belong in Helixar 360. If scope, ownership, risk, or approval changes, the platform can invalidate the session, require reauthorisation, issue a new HDP root, 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 validates the HDP chain before acting and emits independent evidence afterwards. The result is a closed control loop: authority is signed, carried, evaluated, enforced, and evidenced.

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. Bind authority. HDP connects the approved release mandate to the current agent, session, delegation chain, tools, resources, and validity window.
3. Validate access. The deployment credential or capability is checked for audience, lifetime, and resource permission.
4. Evaluate policy and behaviour. Helixar 360 compares the exact repository, environment, artefact digest, arguments, behavioural signals, and current state with the HDP-bound mandate and enterprise rules.
5. Enforce. The platform observes, alerts, requests approval, permits the bound operation, or blocks and contains the workload.
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 decisive one. HDP is the cryptographic binding that stops authority from dissolving as work moves from a person to one agent, then another, then a tool. Helixar 360 is the system that continuously governs that bound chain.

Open protocol, durable architecture

Helixar published HDP openly because agent authority 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 authority 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 the action an agent is about to take.

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 single governed authority chain.