PaperlayerView exact revision on arXiv

Source-linked AI summary

HDP: A Lightweight Cryptographic Protocol for Human Delegation Provenance in Agentic AI Systems

Asiri Dalugoda

arXiv:2604.04522v1cs.CRcs.MA

TL;DR

Agentic systems lack a standard way to verify that terminal actions were authorized by a human through a specific delegation chain and scope. HDP addresses this gap with a token that binds authorization to a session and records signed, append-only delegation hops, enabling offline provenance verification. The paper concludes that HDP provides a lightweight accountability mechanism, while noting its bounded security scope and current standardization status.

  • Problem

    Agentic multi-agent pipelines lack a standard mechanism for verifying terminal actions’ human authorization, scope, and delegation history.

  • Method

    HDP uses a token that binds a human authorization event to a session and records each delegation action as a signed hop in an append-only chain.

  • Results

    HDP enables verification of the complete delegation chain using the issuer’s Ed25519 public key and current session identifier, without network calls or registry lookups.

  • Takeaways & Limitations

    HDP provides a lightweight, offline-verifiable, self-sovereign provenance scheme for binding human authorization events to agentic delegation chains.

  • Takeaways & Limitations

    HDP does not protect semantic correctness or token confidentiality, and its IETF Internet-Draft requires community review and demonstrated implementation for standardization progress.

Abstract

from arXiv · show

Agentic AI systems increasingly execute consequential actions on behalf of human principals, delegating tasks through multi-step chains of autonomous agents. No existing standard addresses a fundamental accountability gap: verifying that terminal actions in a delegation chain were genuinely authorized by a human principal, through what chain of delegation, and under what scope. This paper presents the Human Delegation Provenance (HDP) protocol, a lightweight token-based scheme that cryptographically captures and verifies human authorization context in multi-agent systems. An HDP token binds a human authorization event to a session, records each agent's delegation action as a signed hop in an append-only chain, and enables any participant to verify the full provenance record using only the issuer's Ed25519 public key and the current session identifier. Verification is fully offline, requiring no registry lookups or third-party trust anchors. We situate HDP within the existing landscape of delegation protocols, identify its distinct design point relative to OAuth 2.0 Token Exchange (RFC 8693), JSON Web Tokens (RFC 7519), UCAN, and the Intent Provenance Protocol (draft-haberkamp-ipp-00), and demonstrate that existing standards fail to address the multi-hop, append-only, human-provenance requirements of agentic systems. HDP has been published as an IETF Internet-Draft (draft-helixar-hdp-agentic-delegation-00) and a reference TypeScript SDK is publicly available.

1. Introduction

Agentic systems can execute consequential actions through multi-agent delegation chains, but existing mechanisms do not preserve verifiable links to the originating human authorization. HDP addresses this gap with an offline-verifiable token that records authorization scope and signed delegation hops.

  • 1. Introduction: Agentic pipelines pass human instructions through orchestrators, specialized sub-agents, and tool-execution agents that can perform consequential actions.Examples include financial transactions, code commits, email dispatch, and data modification, often with minimal action-level human supervision.
  • 1. Introduction: Downstream agents lack a standard mechanism to verify whether terminal actions were human-authorized, under what scope, and through which delegation chain.This disconnect also prevents reliable reconstruction of who approved what and when.
  • 1. Introduction: The accountability gap lets injected instructions masquerade as authorized delegation and complicates attribution of autonomous actions to a specific human authorization event.The paper links these consequences to prompt injection attacks and emerging regulatory exposure.
  • 1. Introduction: HDP binds a human principal, declared scope, and session to a token, then accumulates cryptographically signed delegation hops in an append-only chain.Recipients can verify the complete chain using the issuer’s Ed25519 public key and current session identifier.
  • 1. Introduction: HDP verification is fully offline, requiring no network call, registry lookup, or third-party trust anchor.The protocol is presented as a lightweight token-based scheme for closing the accountability gap.

2. Related Work and Motivation

Related work identifies a mismatch between agentic multi-hop delegation and authorization frameworks built for simpler human-to-system interactions. HDP positions itself as a provenance record with append-only history, offline verification, and limited infrastructure requirements rather than a general capability-enforcement system.

  • 2. Related Work and Motivation: Existing authorization frameworks do not capture the multi-hop, append-only, human-provenance requirements of agentic pipelines.The paper presents HDP as a response to this specific structural requirement.
  • 2.2 OAuth 2.0 Token Exchange (RFC 8693): RFC 8693 supports delegation through nested act claims but governs token exchange within an OAuth 2.0 authorization-server context.HDP instead carries a provenance record with the agentic task.
  • 2.2 OAuth 2.0 Token Exchange (RFC 8693): RFC 8693 creates a new token at each point-to-point exchange, whereas HDP carries the complete delegation history in one append-only token.This is identified as a principal architectural difference between the protocols.
  • 2.3 JSON Web Tokens: JWT provides signed claims for agent authentication, while HDP adds an append-only multi-party-signed delegation chain and uses RFC 8785 canonical JSON for signing.The paper distinguishes HDP’s verification pipeline from JWT’s base64url-encoded header.payload format.
  • 2.4 UCAN (User Controlled Authorization Networks): UCAN encodes executable capabilities enforced by receiving systems, whereas HDP records human-authorized agentic provenance without requiring DID infrastructure.The paper describes HDP as a lower-complexity design point for offline operation and minimal infrastructure overhead.
  • 2.5 Intent Provenance Protocol: IPP and HDP both use Ed25519 signatures and append-only provenance chains but differ in revocation, trust anchors, and identity models.IPP requires registry polling, a genesis seal, and DID identifiers; HDP uses short-lived session-bound tokens, no external trust anchor, and supports opaque identifiers.
  • 2.6 Prompt Injection and the Accountability Surface: HDP treats prompt injection as an accountability problem: missing or fabricated delegation events can make injected actions detectable, but not prevent semantic injection.The protocol is therefore positioned as infrastructure for accountability rather than a complete injection defense.

3. Threat Model

HDP targets the bounded threat that terminal actions become disconnected from their originating human authorization in multi-agent pipelines. Its threat model includes injection, interception, replay, forgery, and fabricated hops, while excluding key compromise, cryptographic breaks, and insecure session establishment.

  • 3. Threat Model: HDP addresses disconnection between terminal agent actions and their originating human authorization event in multi-agent pipelines.The paper explicitly defines this as a specific, bounded threat.
  • 3.1 Attacker Model: The attacker model includes indirect prompt injection, token interception, cross-session replay, token forgery or modification, and fabricated delegation hops.These capabilities cover attacks against inputs, transmitted tokens, authorization claims, and chain integrity.
  • 3.1 Attacker Model: The model excludes attackers possessing the issuer’s Ed25519 private key, breaking Ed25519 or SHA-512 security, or tampering with the secured session-establishment channel.Key compromise is treated as an operational security problem rather than a protocol problem.
  • 3.2 Assets and Goals: HDP protects the human authorization event, delegation-chain integrity, and token non-replayability across sessions and after expiry.Protected authorization data includes principal identity, declared scope, and session binding.
  • 3.2 Assets and Goals: HDP does not protect agent behavior beyond the token, semantic correctness relative to scope, or token-content confidentiality.Semantic validation remains an application-layer concern, and tokens are signed rather than encrypted.
  • 3.3 Detection Scenarios: The protocol is designed to detect missing valid tokens, forged principals or scopes, tampered chains, and tokens replayed from prior sessions.Root signatures, hop signatures, and session binding provide the corresponding detection or blocking mechanisms.

4. Protocol Specification

HDP uses a self-sovereign token design centered on offline verification and an append-only delegation record. The token stores authorization context, identity and scope data, lifecycle and session metadata, and sequentially signed hops.

  • 4.1 Design Principles: Offline verifiability requires only a public key and session ID, without network calls, registry lookups, or third-party endpoints.The design supports air-gapped environments, intermittently connected edge deployments, and latency-sensitive pipelines.
  • 4.2 Token Structure: An HDP token is a JSON object with six top-level fields: hdp, header, principal, scope, chain, and signature.These fields respectively represent protocol version, lifecycle and session binding, human identity, authorization constraints, delegation hops, and the root Ed25519 signature.
  • 4.2.1 Header: The header records token identity, issuance and expiry times, session binding, protocol version, and an optional parent token for re-authorization chaining.Expiry defaults to 24 hours, and the session identifier is established out-of-band before issuance.
  • 4.2.2 Principal: The principal object identifies the authorizing human using a required id and id_type, while supporting opaque, email, UUID, DID, and proof-of-humanity identifiers.HDP mandates no specific identity model and makes DID infrastructure optional.
  • 4.2.3 Scope: The scope object records intent, data classification, network egress, and persistence, with optional tools, resources, and hop limits covered by the root signature.Scope cannot be modified after issuance, while semantic action validation remains an application-layer concern.
  • 4.2.4 Delegation Chain: The append-only chain records sequential delegation hops with agent metadata, timestamps, action summaries, parent indices, and hop signatures.Agents cannot remove or modify entries, and gaps in sequence numbers violate the protocol.

4.3 Cryptographic Construction

HDP constructs a signed, append-only delegation token whose verification reconstructs the complete authorization history offline. Root and hop signatures bind token contents, delegation order, session, and issuer identity.

  • Cryptographic Construction: Ed25519 signatures cover the token root and each delegation hop using deterministic RFC 8785 canonical JSON serialization.Binary fields use unpadded base64url encoding.
  • Hop Signatures: Each hop signature binds the new hop to the root signature and all previously signed hops, while excluding only the new hop's signature.The verifier must reconstruct this asymmetric payload exactly.
  • Chain Integrity: Tampering with or inserting any hop causes verification to fail for that hop and every subsequent hop.The chained construction makes the entire accumulated delegation history cryptographically dependent on earlier records.
  • Verification Pipeline: Verification checks version, expiry, root signature, hop sequence, hop signatures, maximum hops, and session binding in order.Any failed step causes immediate rejection; Proof-of-Humanity validation is optional.
  • Offline Verification: The verifier needs only the issuer's Ed25519 public key, current session identifier, and current time, with no network calls.This supports fully offline verification.

4.5 Re-Authorization and Multi-Principal Delegation

HDP supports authorization evolution and joint human approval through cryptographically linked tokens. These mechanisms preserve lineage while allowing tokens to be transmitted directly or by reference.

  • Re-Authorization: A new token can supersede an earlier one by linking its parent_token_id to the prior token before signing.The signed parentage link creates an auditable lineage of scope evolution.
  • Multi-Principal Delegation: Sequentially chained tokens provide joint authorization by separately signing Human A's and Human B's authorization artifacts.Verification checks each token, the parent_token_id linkage, and the shared session_id.
  • Transmission: HDP tokens can travel in X-HDP-Token or be referenced through X-HDP-Token-Ref, but must not appear in URL query parameters.The draft requests registration of both headers and the HDP media type.

5. Security Analysis

HDP's security analysis connects signature and session-binding mechanisms to forgery, tampering, replay, injection, privacy, and key-management boundaries. The protocol detects cryptographic violations but does not establish semantic intent by itself.

  • Token Forgery: Modified headers, principals, or scopes fail root signature verification because valid signatures require the issuer's private key.The guarantee reduces to Ed25519 unforgeability under chosen-message attack.
  • Chain Tampering: Modification, removal, reordering, or insertion of a hop fails verification for the tampered hop and all subsequent hops.Each hop signature covers all prior hops with their signatures.
  • Replay Defense: Temporal expiry and session binding jointly limit a stolen non-expired token to the session in which it was issued.The default expiry window is 24 hours, with shorter lifetimes recommended for elevated security requirements.
  • Prompt Injection Boundary: HDP detects missing or fabricated delegation records but does not fully prevent prompt injection when a legitimate agent records a misleading genuine hop.Semantic validation of action intent remains an application-layer responsibility.
  • Privacy Properties: HDP tokens may contain personal data when principal.id identifies a person, requiring opaque identifiers and appropriate retention controls.Removing the principal invalidates the root signature, so stripped tokens must be marked audit-only.
  • Key Management: All HDP security guarantees depend on protecting the issuer's Ed25519 private key with a secrets manager, HSM, or equivalent enclave.Production deployments must not store private keys in source code, configuration files, or environment variables.

6. Implementation and Deployment

HDP is exposed through a TypeScript SDK and integrates at the orchestration layer, where agents verify and extend tokens before downstream execution. Its stated performance and deployment profile targets high-throughput pipelines, while the draft provides standardization artifacts.

  • Reference Implementation: The TypeScript SDK provides token issuance, hop extension, and the seven-step verification pipeline, with Python integrations for CrewAI and MCP.The implementation uses noble-ed25519 and RFC 8785-conformant canonicalization.
  • Deployment Pattern: The typical integration passes a human-issued token through the orchestrator, extends it at each agent, and verifies the complete chain before tool execution.Verification at every hop is recommended, while terminal-only verification is acceptable in some deployments.
  • Performance Characteristics: Under 2 milliseconds, full verification completes for a typical 10-hop delegation chain.Individual Ed25519 verification takes under 100 microseconds on contemporary hardware.
  • Performance Characteristics: A typical 10-hop token is approximately 4-8 KB, and token size grows linearly with chain length.This size profile is presented as suitable for high-throughput agentic pipelines.
  • Standardization: The protocol has been submitted as draft-helixar-hdp-agentic-delegation-00 to the IETF RATS Working Group.The draft includes normative specifications, IANA considerations, and related-work comparisons.

7. Limitations and Future Work

HDP v0.1 simplifies signing by using the issuer's key for every hop, while future work targets agent-specific signatures, multi-principal authorization, enforcement integration, and standardization.

  • Single-Key Signing in v0.1: HDP v0.1 uses the issuer's key for all hop signatures, so signatures attest recording at the issuer rather than production by a specific agent.Per-agent key binding is planned for v0.2 using threshold or multi-signature schemes.
  • Runtime Enforcement: HDP records authorization but does not enforce whether an action is semantically consistent with scope.intent.Runtime policy systems could use HDP as audit input to detect scope violations.
  • Multi-Principal Authorization: The current multi-principal model requires sequential human actions; planned threshold signatures would enable M-of-N authorization without sequential dependency.The extension is intended to introduce simultaneous multi-signature primitives.
  • Standardization and Interoperability: The IETF Internet-Draft remains an individual submission, with Working Group adoption requiring community review and demonstrated implementation.Deployment feedback and alignment with OpenID Foundation agentic identity work are identified as priorities.

8. Conclusion

The conclusion presents HDP as a lightweight, offline-verifiable token that binds human authorization to agentic delegation chains and addresses provenance requirements that existing standards do not cover.

  • HDP addresses the accountability gap caused by disconnecting terminal actions from their originating human authorization.
  • HDP cryptographically binds human authorization events to agentic delegation chains and is presented as lightweight, offline-verifiable, and self-sovereign.
  • The paper argues that existing standards do not address multi-hop, append-only, human-provenance requirements in agentic pipelines.
  • HDP is published as an IETF Internet-Draft with a publicly available reference TypeScript SDK and Python integrations.

Licence

The work is distributed under CC BY 4.0, permitting sharing and adaptation with attribution, licensing information, and change disclosure.

  • The work is licensed under the Creative Commons Attribution 4.0 International Licence.
  • The licence permits sharing and adaptation for any purpose when appropriate credit, a licence link, and indicated changes are provided.
  • Licence details are provided at the Creative Commons website.
  • The paper identifies Asiri Dalugoda of Helixar Limited and gives the IETF Internet-Draft identifier draft-helixar-hdp-agentic-delegation-00.
Loading 2604.04522v1…