HDP - cryptographic chain-of-custody for multi-agent delegation #7485
Replies: 4 comments 6 replies
-
|
The delegation-chain integrity problem is real and measurable. We run a test suite that specifically targets multi-agent delegation — injecting rogue instructions mid-chain, forging orchestrator messages, and testing whether downstream agents can distinguish legitimate delegations from spoofed ones. Short answer: without something like what you're describing, they can't. A few observations from testing that might be useful: What breaks without provenance: Our "confused deputy" tests inject adversarial instructions into a sub-agent's context that mimic orchestrator-style messages. In every framework we've tested (AutoGen, CrewAI, LangGraph), the sub-agent follows the injected instruction. There's no cryptographic or structural way to verify "this instruction actually came from my orchestrator." HDP's signed delegation chain would close this. The timestamp question: Your Verification cost: One thing to consider for AutoGen specifically — verification needs to be cheap enough that it doesn't become a bottleneck in high-throughput group chats. Have you benchmarked Ed25519 verification overhead per message in a typical AutoGen Our test findings are in |
Beta Was this translation helpful? Give feedback.
-
|
the confused deputy results don’t surprise me but they’re good to have documented. the core problem is that every framework today treats the conversation history as implicitly trusted. once a message is in the context window it looks identical whether it came from a legitimate orchestrator or an injected instruction. HDP’s signed chain is designed to break that assumption i.e a downstream agent can reject any instruction that doesn’t carry a valid chain signature traceable to the original issuer’s key. worth noting that v0.1 uses the issuer’s key for all hop signatures rather than per-agent keys, so what you’re verifying is chain integrity from the root, not that a specific upstream agent produced a specific hop. per-agent key binding is planned for v0.2. would be very interested in running HDP against your harness,will look at agent-security-harness and follow up. on Ed25519 overhead, under 100 microseconds per verification call on standard hardware, which i think is negligible per message even in high-throughput GroupChat. the cost doesn’t compound dangerously as agent count grows because verification is per-message not per-agent-per-round. |
Beta Was this translation helpful? Give feedback.
-
|
Here is the research article published https://www.academia.edu/165390033 |
Beta Was this translation helpful? Give feedback.
-
|
the Ed25519 chain approach makes sense for the core problem - current autogen setups have no way to distinguish a legitimate orchestrator message from a spoofed one once it's in the conversation history. everything looks like plaintext to the agents downstream. a few questions on autogen-specific dynamics: dynamic agent spawning - autogen can spawn agents at runtime based on task requirements. how does HDP handle the case where the spawning decision itself happens mid-chain? the human authorized "do X" but the orchestrator decides that X requires creating a new specialized agent. does that spawn operation get a derived token from the parent scope, or does it require a new human authorization? nested conversation termination - autogen's GroupChatManager can terminate and restart sub-conversations. if a sub-agent chain completes and a new one starts as part of the same task, does HDP treat that as a continuation (same session ID) or a new delegation that needs fresh authorization? scope declaration format - what does a scope string look like in practice? if an agent is authorized to "retrieve and summarize documents", does HDP validate that a file deletion call is out of scope, or is scope just informational metadata in the token? the IETF draft angle is interesting - standardized provenance tokens would make cross-framework delegation (autogen calling a crewai sub-agent) auditable in a way that nothing currently handles. that's probably the most underrated use case here. |
Beta Was this translation helpful? Give feedback.
-
|
three good questions, let me take them in order and sorry it will be long. dynamic agent spawning : this is a v0.1 edge case worth being direct about. the current answer is: the spawning agent records the spawn decision as a hop in the existing chain (action_summary describes the intent to spawn), and the spawned agent inherits the token. so the spawn operates under the parent scope. if the spawned agent needs capabilities outside the original scope, that triggers re-authorization, a new token with parent_token_id pointing to the original. the design principle is that scope can narrow as you go down the chain but can’t expand without a new human authorization event. we’re planning to make derived token semantics explicit in v0.2. nested conversation termination : same session ID if it’s genuinely the same task continuing. GroupChatManager restarting a sub-conversation to retry or replan is a continuation, not a new delegation. the session_id is the binding, not the conversation turn. a genuinely new task that happens to follow the previous one in the same session should get a new token. boundary is intentionally application-defined because the right answer depends on context, if I remember correctly I've documented this as an open question in the IETF draft. scope declaration format : scope is metadata in v0.1, not enforced by the protocol. HDP records what the human authorized, it doesn’t validate that agent actions stay within it. that’s an application-layer responsibility. the design rationale is deliberate, we didn’t want to build a capability enforcement system into a provenance protocol. Two different problems. what HDP gives you is an evidence trail, if an agent takes an action outside declared scope, you can prove it post-hoc. runtime enforcement systems like CaMeL or MI9 can use the HDP token as audit input and do the semantic validation themselves. your cross-framework point is the one i’d push hardest. an AutoGen orchestrator calling a CrewAI sub-agent today produces zero auditable record of that delegation. standardized provenance tokens make that chain verifiable regardless of which framework is on each end. that’s probably the strongest argument for getting this to IETF standard rather than leaving it as a framework-specific solution. SDK is at @helixar_ai/hdp on npm if you want to prototype against it. happy to work through integration specifics here. Thank you |
Beta Was this translation helpful? Give feedback.
-
|
the v0.1 chain-from-root vs per-agent-key distinction is a useful clarification - chain integrity from the root gives you tamper detection, but you can't attribute a specific hop to a specific agent without per-agent keys. that tradeoff makes sense for v0.1 where you want the base protocol simple. the scope narrowing principle is the right default - scope can narrow as delegation goes deeper but expanding requires new root authorization. that's the right way to prevent the confused deputy case where a sub-agent ends up with more authority than the human intended. Ed25519 sub-100 microseconds per verification is negligible per message. would be curious whether overhead compounds in deeply nested chains with many hops but guessing not significantly - linear per verification call means even a 10-hop chain is still well under a millisecond total. will look at the npm SDK. the cross-framework case (autogen orchestrator -> crewai sub-agent) is the one worth building around first imo - that's where the audit gap is most obvious right now. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback. You're right on the v0.1 tradeoffs:
Ed25519 verification stays well under 100µs per hop. All operations are non-blocking. We've added HDP middleware for AutoGen (Python + TypeScript):
PR: Helixar-AI/HDP#9 This enables verifiable provenance for AutoGen → CrewAI handoffs. Feedback welcome, especially on scope policy and cross-framework flows. |
Beta Was this translation helpful? Give feedback.
-
|
This connects to the broader trust-boundary testing gap we've been working on. We just published a detailed breakdown of what fails across multi-agent frameworks when you test delegation chains adversarially: https://dev.to/mspro3210/agent-systems-are-failing-at-trust-boundaries-we-ran-332-tests-to-prove-it-5cod The short version: delegation handoffs are where trust assumptions break down. In default configurations across AutoGen, CrewAI, and LangGraph, context leaks across agent boundaries during delegation. The HDP approach of Ed25519-signed delegation tokens addresses the provenance side, but the behavioral side (does the downstream agent actually respect scope constraints?) still needs adversarial testing. The harness we discussed in #7432 now covers 332 tests across 24 modules, including delegation chain depth attacks and scope escalation. Happy to run the D004 module against an HDP-wrapped delegation flow if you want to see how the cryptographic chain holds up under adversarial conditions. |
Beta Was this translation helpful? Give feedback.
-
|
Appreciate the breakdown and the link to the harness @msaleme, your tests, the excellent dev.to write-up on delegation handoffs and AutoGen’s conversation-based attack surface are valuable work for the whole ecosystem. You’re spot on about the core split: true security is a property of the deployment, not just the framework. HDP is deliberately focused on the cryptographic provenance layer delivering a verifiable, human-rooted delegation chain while behavioral enforcement and runtime anomaly detection live at the application/platform layer. • What HDP provides: The root token cryptographically binds authorized_tools, authorized_resources, data_classification, max_hops, and other constraints using Ed25519 signatures over RFC 8785 canonical JSON. Each hop signs the cumulative prior chain state, making any tampering, reordering, insertion, or gap immediately detectable. Verification is fully offline with zero network calls. • What stays at the deployment layer: In v0.1, scope is carried as signed metadata. HDP proves who authorized what at each hop, but actual in-lane checks (tool usage, scope drift, context leakage across handoffs) are handled by middleware or a full behavioral security platform. We are actively developing a dedicated hdp-autogen middleware (following the same pattern as our CrewAI and Grok/xAI integrations). It will hook into agent lifecycles, GroupChatManager flows, dynamic spawning, and nested conversations treating speaker turns as hops and supporting explicit re-auth via parent_token_id when max_hops is reached or scope needs to expand. I’m genuinely interested in running D004 and the relevant delegation modules against an HDP-instrumented AutoGen flow once the middleware is ready. The cryptographic chain is framework-agnostic and straightforward to instrument. If you’re open to it, we’d love to collaborate on testing, this would give concrete, public data on where provenance holds strong and where behavioral monitoring still needs to catch anomalies. Repo & SDK: https://github.com/Helixar-AI/HDP Happy to contribute relevant attack patterns back to the harness as well. |
Beta Was this translation helpful? Give feedback.
-
|
Cryptographic chain-of-custody for delegation is a great direction. I've been building something that complements this — proof-of-behavior for the actions within each delegation step. The chain-of-custody tells you who delegated to whom. Proof-of-behavior tells you what each agent did with that delegation. Together: who had authority + what they did with it + cryptographic evidence for both. The implementation: agents declare behavioral constraints, every action gets evaluated before execution, and decisions go into a SHA-256 hash chain. Each entry links to the previous — tamper with one and the chain breaks. For AutoGen multi-agent workflows, this could work per-agent: each agent in the pipeline gets its own behavioral covenant and its own hash-chained log. At the end of the workflow, you have the delegation chain (HDP) and the behavioral evidence for each step (proof-of-behavior). Open-source: github.com/arian-gogani/nobulex |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Autogen Community 👋,
been hitting a consistent gap when building multi-agent pipelines, when a task delegates across multiple agents, there's no standard way to verify that downstream actions were actually authorized by the originating human. a compromised tool or rogue sub-agent mid-chain can inject instructions that look identical to legitimate orchestrator messages. no forensic trail, no way to know where the chain broke.
built HDP (Human Delegation Provenance) to address this. every delegation hop is Ed25519 signed and encoded in a self-contained token. verification is fully offline, no registry, no network call, just a public key and a session ID. if the chain breaks, you know exactly where and at which hop.
what's shipped:
@helixar_ai/hdp, npm)configure(crew)calldraft-helixar-hdp-agentic-delegation-00(RATS WG)design decision worth flagging: HDP is a provenance layer, not enforcement. it records that a human authorized an action with a declared scope and traces the chain. what you do with a violation is up to the application.
AutoGen's architecture is exactly the kind of multi-agent system this was designed for and I'd genuinely value feedback from people building complex pipelines here on whether the model holds up, particularly around dynamic agent spawning and nested task delegation.
github: https://github.com/Helixar-AI/HDP
Beta Was this translation helpful? Give feedback.
All reactions