pith. machine review for the scientific record. sign in

arxiv: 2604.04522 · v1 · submitted 2026-04-06 · 💻 cs.CR · cs.MA

Recognition: no theorem link

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

Asiri Dalugoda

Pith reviewed 2026-05-10 19:59 UTC · model grok-4.3

classification 💻 cs.CR cs.MA
keywords human delegation provenancecryptographic protocolagentic AIappend-only chainEd25519offline verificationdelegation tokensaccountability
0
0 comments X

The pith

HDP binds human authorization to AI agent sessions via an Ed25519-signed append-only chain that any party can verify offline.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents the Human Delegation Provenance protocol to close the accountability gap in agentic AI systems where autonomous agents delegate tasks in multi-step chains. An HDP token starts with a human authorization event tied to a session identifier and records every subsequent delegation as a cryptographically signed hop in a growing chain. Any participant can check the entire provenance record using only the issuer's public key and the session identifier, with no registry lookups or external trust anchors required. This matters for systems in which terminal actions carry real-world consequences, because it supplies a concrete way to confirm both the human origin and the exact path of delegation.

Core claim

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.

What carries the argument

The HDP token: a signed append-only sequence that begins with a human authorization event and accumulates each delegation hop as a verifiable Ed25519 signature linked by the session identifier.

If this is right

  • Multi-agent systems can now produce auditable records of human authorization without relying on centralized registries.
  • Terminal actions executed by agents can be traced back to a specific human principal and delegation path using only public information.
  • The protocol distinguishes itself from OAuth token exchange and JWT by enforcing an append-only human-origin chain that survives multiple hops.
  • Offline verification removes the need for live network access or third-party services during provenance checks.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If adopted, liability questions in AI-driven decisions could shift from ambiguous delegation to concrete cryptographic records.
  • The design may extend naturally to constrained environments such as edge devices where connectivity is limited.
  • Integration with existing identity systems could allow the initial human authorization to be issued from familiar authentication flows.

Load-bearing premise

The initial human authorization event is captured correctly and securely, and every agent in the chain follows the protocol rules without forgery or collusion.

What would settle it

A concrete example in which a forged delegation hop is accepted as valid when verification is performed with only the issuer's Ed25519 public key and the session identifier, or a valid chain that fails verification under the same conditions.

Figures

Figures reproduced from arXiv: 2604.04522 by Asiri Dalugoda.

Figure 1
Figure 1. Figure 1: HDP token top-level structure. 4.2.1 Header The header carries a UUID v4 token identifier (token_id), Unix millisecond timestamps for issuance (issued_at) and expiry (expires_at, default 24 hours), a session identifier (session_id) established out-of-band between issuer and agent framework before token issuance, a version string mirroring the top-level hdp field, and an optional parent_token_id for re-auth… view at source ↗
read the original abstract

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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper presents the Human Delegation Provenance (HDP) protocol, a lightweight token-based cryptographic scheme for agentic AI 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 offline verification of the full provenance record using only the issuer's Ed25519 public key and the current session identifier. The work situates HDP relative to OAuth 2.0 Token Exchange, JWT, UCAN, and IPP, claiming these standards fail to address multi-hop human-provenance requirements, and notes its publication as an IETF Internet-Draft with a publicly available TypeScript SDK.

Significance. If the protocol's security properties hold, it could address a relevant accountability gap in multi-agent AI delegation by providing registry-free, offline-verifiable human provenance using standard primitives. The emphasis on append-only signed chains and minimal verification requirements is a clear design choice suited to distributed agentic systems. The IETF draft status and open reference SDK are concrete strengths that facilitate adoption and external validation.

major comments (2)
  1. [Protocol Design section] The central claims of secure binding, append-only integrity, and fully offline verification rest on the protocol description, but the manuscript provides no formal security model, threat analysis, or proofs (e.g., for unforgeability of the chain or resistance to replay/collusion attacks).
  2. [Related Work / Positioning section] The demonstration that OAuth 2.0, JWT, UCAN, and IPP fail to meet the multi-hop human-provenance requirements is presented descriptively without a systematic comparison, table, or analysis of why their mechanisms cannot be extended.
minor comments (2)
  1. [Abstract] The abstract is information-dense; separating the protocol mechanics from the comparison claims would improve readability.
  2. [Protocol Description] Include explicit pseudocode or data-structure definitions for token construction, signing, and verification to support reproducibility.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback. We address each major comment below and will incorporate revisions to strengthen the manuscript.

read point-by-point responses
  1. Referee: [Protocol Design section] The central claims of secure binding, append-only integrity, and fully offline verification rest on the protocol description, but the manuscript provides no formal security model, threat analysis, or proofs (e.g., for unforgeability of the chain or resistance to replay/collusion attacks).

    Authors: We agree that the absence of an explicit threat model and security analysis is a limitation. The manuscript relies on the well-established properties of Ed25519 signatures and the append-only structure of the token chain for its security arguments, with verification described in terms of standard signature checks. To address this, the revised manuscript will include a dedicated section presenting a threat model and informal analysis covering unforgeability of the chain, replay resistance, and collusion scenarios. A full formal proof is beyond the scope of this protocol-focused paper but could be pursued separately. revision: yes

  2. Referee: [Related Work / Positioning section] The demonstration that OAuth 2.0, JWT, UCAN, and IPP fail to meet the multi-hop human-provenance requirements is presented descriptively without a systematic comparison, table, or analysis of why their mechanisms cannot be extended.

    Authors: The current positioning section identifies specific gaps in multi-hop human provenance support through descriptive comparison. We acknowledge that a tabular format and explicit discussion of extensibility would provide greater rigor. The revised manuscript will add a comparison table contrasting key features of OAuth 2.0 Token Exchange, JWT, UCAN, and IPP against HDP requirements, together with analysis explaining why incremental extensions would not satisfy the append-only, registry-free, and human-binding properties without substantial redesign. revision: yes

Circularity Check

0 steps flagged

No significant circularity in protocol design

full rationale

The paper is a design specification for the HDP protocol that relies on standard Ed25519 signatures to bind human authorizations and record delegation hops in an append-only chain. Verification uses only the issuer public key and session identifier with no fitted parameters, predictions, or equations that reduce to inputs by construction. References to OAuth, JWT, UCAN, and IPP are for comparative positioning only and do not serve as load-bearing justifications for the core mechanics. The IETF draft mention is a self-reference to the same work but is not used to prove uniqueness or derive results. The construction is internally consistent and self-contained against external cryptographic standards.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 1 invented entities

The central claim rests on standard cryptographic assumptions for signature security and the correctness of the token chaining mechanism; no data fitting or ad-hoc constants are introduced as this is a protocol design.

axioms (1)
  • standard math Ed25519 signatures provide unforgeability and integrity for each delegation hop under standard cryptographic assumptions.
    The protocol relies on Ed25519 for signing hops and verification, invoking its established security properties without additional proofs.
invented entities (1)
  • HDP token with human authorization binding and append-only signed hops no independent evidence
    purpose: To capture and enable verification of multi-hop human delegation provenance in agentic AI systems.
    This token format and chaining structure is the core new construct introduced by the paper.

pith-pipeline@v0.9.0 · 5553 in / 1564 out tokens · 60657 ms · 2026-05-10T19:59:22.396100+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Decision Evidence Maturity Model for Agentic AI: A Property-Level Method Specification

    cs.CY 2026-04 unverdicted novelty 4.0

    DEMM defines four executable evidence-sufficiency categories plus a conflicting category for agentic AI decisions and rolls per-property verdicts into a five-level maturity rubric.

Reference graph

Works this paper leans on

30 extracted references · 12 canonical work pages · cited by 1 Pith paper · 2 internal anchors

  1. [1]

    Chase, H. et al. LangChain: Building applications with LLMs through composability. GitHub Repository. https://github.com/langchain-ai/langchain. 2022

  2. [2]

    Multi-agent orchestration framework

    CrewAI. Multi-agent orchestration framework. https://github.com/crewAIInc/crewAI. 2024

  3. [3]

    Wu, Q. et al. AutoGen: Enabling next-gen LLM applications via multi-agent conversation. arXiv:2308.08155. 2023

  4. [4]

    Greshake, K. et al. Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security. 2023

  5. [5]

    Prompt infection: Llm-to-llm prompt injection within multi-agent systems,

    Lee, D. and Ryoo, M. Prompt Infection: LLM-to-LLM prompt injection within multi-agent systems. arXiv:2410.07283. 2024

  6. [6]

    Regulation (EU) 2024/1689

    EU Artificial Intelligence Act. Regulation (EU) 2024/1689. Official Journal of the European Union. 2024

  7. [7]

    Artificial Intelligence Risk Management Framework (AI RMF 1.0)

    NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). National Institute of Standards and Technology. 2023

  8. [8]

    Identity Management for Agentic AI: The new frontier of authorization, authentication, and security for an AI agent world

    OpenID Foundation. Identity Management for Agentic AI: The new frontier of authorization, authentication, and security for an AI agent world. OpenID Foundation Whitepaper. 2025

  9. [9]

    The Looming Authorization Crisis: Why Traditional IAM Fails Agentic AI

    ISACA. The Looming Authorization Crisis: Why Traditional IAM Fails Agentic AI. ISACA Industry News. 2025

  10. [10]

    Agentic AI Security: A Guide to Strategies for AI Agent Security

    Strata Identity. Agentic AI Security: A Guide to Strategies for AI Agent Security. https://www.strata.io. 2026

  11. [11]

    OAuth 2.0 Token Exchange

    Jones, M., Nadalin, A., Campbell, B., Bradley, J., and Liu, C. OAuth 2.0 Token Exchange. RFC 8693. IETF. January 2020. DOI: 10.17487/RFC8693

  12. [12]

    JSON Web Token (JWT)

    Jones, M., Bradley, J., and Sakimura, N. JSON Web Token (JWT). RFC 7519. IETF. May 2015. DOI: 10.17487/RFC7519

  13. [13]

    A survey of agentic AI and cybersecurity: Challenges, opportunities and use- case prototypes,

    Goswami, A. Agentic JWT: Binding agent actions to authenticated intent. In: Survey of Agentic AI and Cybersecurity. arXiv:2601.05293. 2026

  14. [14]

    User Controlled Authorization Network (UCAN) Specification v1.0

    UCAN Working Group. User Controlled Authorization Network (UCAN) Specification v1.0. https://github.com/ucan-wg/spec. 2024

  15. [15]

    Intent Provenance Protocol (IPP)

    Haberkamp, M. Intent Provenance Protocol (IPP). Internet-Draft draft-haberkamp-ipp-00. IETF. 2024

  16. [16]

    Ferrag, M.A. et al. From Prompt Injections to Protocol Exploits: Threats in LLM-Powered AI Agents Workflows. arXiv:2506.23260. 2025

  17. [17]

    Casper, S. et al. The 2025 AI Agent Index: Documenting Technical and Safety Features of Deployed Agentic AI Systems. arXiv:2602.17753. 2026

  18. [18]

    Agent Identity Protocol: Invocation-Bound Capability To- kens for Delegation Chains,

    Prakash, S. Authorization Provenance in Agentic AI Systems. arXiv:2603.24775. 2026

  19. [19]

    Decentralized Identifiers (DIDs) v1.0

    Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele, O., and Allen, C. Decentralized Identifiers (DIDs) v1.0. W3C Recommendation. July 2022

  20. [20]

    and Liusvaara, I

    Josefsson, S. and Liusvaara, I. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032. IETF. January 2017. DOI: 10.17487/RFC8032

  21. [21]

    JSON Canonicalization Scheme (JCS)

    Rundgren, A., Jordan, B., and Erdtman, S. JSON Canonicalization Scheme (JCS). RFC 8785. IETF. June

  22. [22]

    DOI: 10.17487/RFC8785

  23. [23]

    The Base16, Base32, and Base64 Data Encodings

    Josefsson, S. The Base16, Base32, and Base64 Data Encodings. RFC 4648. IETF. October 2006. DOI: 10.17487/RFC4648

  24. [24]

    and Lange, T

    Bernstein, D.J. and Lange, T. SafeCurves: Choosing safe curves for elliptic-curve cryptography. https://safecurves.cr.yp.to. 2014

  25. [25]

    Bernstein, D.J. et al. Ed25519: High-speed high-security signatures. Journal of Cryptographic Engineering 2(2). 2012

  26. [26]

    MI9 – agent intelligence protocol: Runtime governance for agentic AI systems,

    MI9 Project. Agent Intelligence Protocol: Runtime Governance for Agentic AI Systems. arXiv:2508.03858. 2025

  27. [27]

    Debenedetti, E. et al. CaMeL: Defeating Prompt Injections by Design. arXiv preprint. 2025

  28. [28]

    Key words for use in RFCs to Indicate Requirement Levels

    Bradner, S. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119. IETF. March 1997

  29. [29]

    HDP TypeScript Reference Implementation (@helixar_ai/hdp)

    Helixar Limited. HDP TypeScript Reference Implementation (@helixar_ai/hdp). npm. https://www.npmjs.com/package/@helixar_ai/hdp. 2026

  30. [30]

    Human Delegation Provenance Protocol (HDP) v0.1 Specification

    Helixar Limited. Human Delegation Provenance Protocol (HDP) v0.1 Specification. https://helixar.ai/labs/hdp. 2026. Licence Copyright © 2026 Asiri Dalugoda, Helixar Limited. This work is licensed under the Creative Commons Attribution 4.0 International Licence (CC BY 4.0). You are free to share and adapt this material for any purpose, provided appropriate ...