HDP - cryptographic chain-of-custody for AI agent delegation

[Siri (asiridalugoda)]

something that's been bugging me for a while building multi-agent systems , when a task passes through 3-4 agents before hitting a tool call, how do you actually know the final action was authorized by the human who started the chain? right now you mostly don't. a compromised tool or rogue sub-agent can inject instructions mid-chain and there's no forensic trail. you find out something went wrong after the fact.

this feels especially uncomfortable in enterprise deployments where there are real compliance and audit requirements. "the agent did it" isn't going to fly as an answer.

so we built HDP (Human Delegation Provenance) : every delegation hop gets Ed25519 signed and packed into a self-contained token. you can verify the full chain offline at any point with just a public key and a session ID. no central registry, no network call. if the chain breaks you know exactly where.

what's shipped so far:

• TypeScript core SDK (@helixar_ai/hdp, npm)
• CrewAI middleware - one configure(crew) call
• Grok/xAI integration - native tool schemas
• MCP middleware (@helixar_ai/hdp-mcp, npm)
• IETF draft live: draft-helixar-hdp-agentic-delegation-00 (RATS WG)

one thing worth being upfront about, HDP is a provenance layer, not enforcement. it tells you what was authorized and traces the chain. what you do when a violation shows up is up to your application. maps pretty naturally onto SK's plugin and filter architecture.

also posted this in AutoGen discussions, curious whether the problem resonates differently across communities.

would genuinely love to hear from people building SK pipelines, especially around process automation or anything with real accountability requirements. does the model hold up for what you're building?

github: https://github.com/Helixar-AI/HDP

[0xddneto (0xddneto)]

HDP and AIPOU look complementary rather than competing.

The clean split I see:

• HDP: delegation / authority chain, especially who authorized which downstream agent/action;
• Semantic Kernel filters/plugins: enforcement point where the app can allow, deny, escalate, or log;
• AIPOU: post-work receipt for the human/agent task, with nonce/replay protection, local hashes instead of raw prompts/outputs, provider/model/client metadata, and collector signature;
• optional claim/reward: later validator-approved path for the human operator, separate from HDP and SK enforcement.

AIPOU does not detect hidden AI use and does not trustlessly prove useful work today. It gives a portable signed artifact that can link to delegation facts, traces, and policy decisions without absorbing their trust models.

Docs:

• https://github.com/0xddneto/AI-Proof-of-Us/blob/main/docs/external-evidence-links.md
• https://github.com/0xddneto/AI-Proof-of-Us/tree/main/examples/lifecycle-adapter

For SK, I would expect workReceiptId and validation status to attach naturally through filters or function invocation metadata, while HDP remains the chain-of-authority proof.

[AlgoVoi (Christopher Hopley) (chopmob-cloud)]

The problem you describe, that "a compromised tool or rogue sub-agent can inject instructions mid-chain and there's no forensic trail," is the right framing for why provenance matters in multi-agent delegation. Ed25519 signing at each hop and using RFC 8785 canonicalisation for the token format are strong foundations. The design choice to have hop signatures cover cumulative chain state (rather than only the immediate hop) is worth highlighting, because it means a tampered prior hop invalidates every downstream signature, which gives an auditor chain integrity detection, though not on its own proof that the original authority was current or unrevoked.

Where this kind of scheme tends to break in practice is cross-implementation consistency. Two SDKs that both implement RFC 8785 can still diverge on edge cases: Unicode property names above the Basic Multilingual Plane sort differently under native UTF-8 ordering versus the UTF-16 code-unit ordering that RFC 8785 section 3.2.3 requires, and number serialisation has its own corner cases. The way to close that gap is conformance vectors: a shared test suite where the same logical delegation record (including adversarial field names, reordered keys, altered prior hops, and a tampered chain) must produce identical accept/reject results across every SDK. That is more useful than a per-SDK unit test, because it proves that TypeScript and any future Python or Rust implementation reject the same tampered inputs rather than merely showing that each can verify its own tokens.

The separation between provenance and enforcement maps well onto Semantic Kernel's filter architecture, where a filter can inspect a verified chain before invoking a function and record the decision either way. For enterprise deployments, though, there is a distinction between "cryptographically valid" and "still trusted under today's incident-response policy," especially after a suspected key compromise before affected tokens expire. If you target SK's function invocation filters, would the integration surface the token's key identifier, scope decision, and any denial or escalation result together, so an operator can reproduce the trust decision at audit time rather than only confirming the signature was mathematically correct?