- The paper presents a lightweight cryptographic protocol that securely binds multi-hop agent actions to human authorization using offline verifiability.
- It introduces a detailed token structure with append-only delegation chains and Ed25519 signatures to counter token forgery, chain tampering, and replay attacks.
- The protocol integrates with existing AI orchestration systems without central trust anchors, reducing overhead and enhancing post-hoc auditability.
Human Delegation Provenance (HDP) Protocol in Agentic AI Systems
Motivation and Problem Statement
The proliferation of agentic AI systems executing multi-hop delegated tasks with real-world consequences has exposed a severe accountability deficit. Contemporary orchestration frameworks (e.g., LangChain, CrewAI, AutoGen, OpenAI Assistants API) facilitate automation in sensitive domains, where human authorization is diluted through layers of agents. Existing standards such as OAuth 2.0 (RFC 8693), JWT (RFC 7519), UCAN, and the Intent Provenance Protocol (IPP) provide varying support for delegation and capability management; however, none cryptographically bind terminal agent actions to originating human principals through verifiable, append-only delegation chains with offline verifiability requirements.
This lack of a robust, protocol-level linkage between human authorization and multi-hop agent actions impedes post-hoc auditability, enables sophisticated prompt injection vectors, and intensifies regulatory exposure as governance standards (EU AI Act, NIST AI RMF) mature. The HDP protocol directly targets this gap, establishing architectural guarantees for delegation provenance without the operational overhead of central trust anchors, registries, or runtime infrastructure dependencies.
Protocol Architecture
Design Principles and Threat Model
HDP adheres strictly to offline verifiability, self-sovereignty, tamper evidence, minimal implementation footprint, and privacy-by-design. The protocol is constructed to resist token forgery, delegation chain tampering, and session replay attacks under the assumption of uncompromised Ed25519 issuer keys and secure session establishment channels. The attacker is modeled as capable of prompt injection, payload interception, token replay, and token/chain forgery, but not as possessing cryptographic break capabilities.
Token Structure and Delegation Chain
The HDP token is a deterministic RFC 8785-canonicalized JSON object partitioned into:
- Protocol version metadata
- Header (token_id, issued_at, expires_at, session_id, parent_token_id)
- Principal (id, id_type, optional display_name/poh_credential)
- Scope (intent, authorized_tools, data_classification, network_egress, persistence, max_hops, etc.)
- Chain (append-only array of per-hop agent delegation events)
- Signature (Ed25519 signature over header/principal/scope/empty chain)
Each delegation hop contains sequence metadata, agent identification, timestamps, action summaries, and a hop_signature covering the full chain payload up to the current event (including root signature), creating a cryptographically linked provenance trail.
Cryptographic Binding and Verification
The root signature authenticates the human authorization context; each subsequent hop is Ed25519-signed over the signed chain so far. The verification process enforces protocol version/lifetime checks, root and hop signature verification, sequence and chain integrity, max_hops constraints, and session binding. No network dependency is introduced during verification; only the issuer's public key and session identifier are required.
HDP v0.1 designates the issuer's key for all signatures, simplifying key management and pipeline integration. Future versions aim to improve non-repudiation of specific agent identities via per-agent keys and threshold signature schemes.
Comparative Analysis with Existing Standards
OAuth 2.0 Token Exchange and JWT
While RFC 8693 and JWT-based schemes support delegated acting claims, their architectures mandate point-to-point token exchanges or do not encapsulate full multi-hop append-only chains. They further require persistent registry or authorization server availability, creating infrastructure binding antithetical to air-gapped, edge, or latency-sensitive AI deployments. Additionally, neither design intrinsically enforces human-to-terminal action provenance; JWT cannot encode an agentic task's full delegation history nor bind it to an originating human principal in a way that is cryptographically robust and append-only.
UCAN and Intent Provenance Protocol
UCAN implements a general-purpose capability system with chained JWT signatures but requires DIDs and does not target minimal provenance recording or offline operation. IPP is more closely aligned in cryptographic model but diverges by requiring central registry revocation checks, genesis seals anchored to protocol authors' public keys, and strict DID-based identities, all of which HDP omits to reduce deployment friction and eliminate external trust anchors.
Unique Positioning of HDP
HDP is exclusively provenance-focused: it does not enforce semantic scope compliance, does not require DID infrastructure, and imposes zero registry overhead. It facilitates integration within existing agent orchestration pipelines and can operate in contexts (e.g., air-gapped or edge deployments) where online revocation checking or trust anchor validation are infeasible.
Security Analysis
Rigorous evaluation of HDP under the stated threat model demonstrates its resistance to all targeted attacks contingent on Ed25519 security assumptions:
- Token Forgery: Detection via root signature, unforgeable without the issuer key.
- Chain Tampering: Immediate detection upon hop signature verification due to chaining.
- Replay Defense: Enforced by session_id and short-lived tokens; tokens are not transferrable inter-session or post-expiry.
- Prompt Injection: Provides cryptographically auditable evidence for unregistered or improperly delegated agent actions rather than active prevention.
- Privacy: Opaque principal identifiers mitigate excessive PII exposure; audit tokens can be structurally separated from enforcement tokens.
Nonetheless, HDP does not address the semantic validation of agent actions post-authorization—scope enforcement and behavioral attestation remain out-of-band responsibilities, motivating integration with runtime provenance-aware policy enforcement systems.
Implementation and Integration
A TypeScript SDK (@helixar_ai/hdp) and Python integrations offer immediate utility for agentic orchestration stacks. Integration requires only Ed25519 and JSON stack support, with protocol overheads negligible at high throughput (sub-2ms verification for 10-hop chains, with multilinear token size scaling). Deployment is facilitated via standard HTTP header-based transmission, with optional key publishing via conventional well-known URLs (no centralized registry required).
Limitations and Roadmap
The principal limitations reside in single-key signing (attesting only to issuance, not specific agent action authorship), sequential-only multi-principal delegation (no threshold group signing), and the lack of in-protocol semantic enforcement. Addressing these, HDP v0.2 intends to introduce per-agent key signing, threshold signatures for simultaneous multi-principal delegation, and first-class hooks for integrating external semantic validators. Advancement in the IETF standardization process is anticipated, contingent on real-world deployment feedback.
Conclusion
HDP establishes an efficient, minimal, self-sovereign protocol for cryptographically recording and verifying the provenance of human delegation in agentic AI systems. By bridging the accountability gap inherent in multi-hop autonomous pipelines, it provides actionable infrastructure for regulatory compliance, forensic audit, and operational assurance in high-assurance AI deployments. HDP's offline verifiability and structural independence from centralized trust anchors or registry dependencies distinguish it from contemporary delegation protocols. Future protocol evolution will address fine-grained identity attestation and achieve tighter semantic-policy integration.
