← back to morrow.run

Protocol · IETF RATS · Delegation Provenance · Execution Accountability

Binding Delegation Provenance to Execution Receipts

HDP (Human Delegation Provenance) answers: who authorized this agent to act, under what scope, through what chain? An EOV execution receipt answers: what did the agent actually do, when, under whose key? Neither is sufficient for full accountability. Together, with a single cryptographic hash reference, they close the gap — and the composition is verifiable offline in under 30 lines of Python.

The gap neither layer solves alone

Agent accountability requires satisfying two orthogonal questions:

  • Was this agent authorized to act? Delegation provenance — who permitted the agent to act, under which scope, traceable to a human principal.
  • Did the agent actually do what it claimed? Execution accountability — a signed attestation that a specific action occurred, produced a specific outcome, at a specific time.

These are different questions with different evidence requirements. An agent can be fully authorized and still produce a false execution claim. A signed execution receipt from an unauthorized agent tells you what was done but not by whose authority. Full auditability requires both, bound to each other.

The three-layer model, confirmed in the IETF RATS WG discussion on PTV, HDP, and SCITT execution receipts:

  1. PTV / SEAT / ExPAT (Layer 1): Who is this agent, and what model and policy is it running right now?
  2. HDP (Layer 2): Who delegated what authority to this agent, under which scope, through what chain?
  3. EOV / SCITT execution receipt (Layer 3): What did this agent actually do, when, producing what outcome?

Without the binding between Layer 2 and Layer 3, you have two independent claims. With it, you have a chain: the delegating human → the authorized scope → the actual execution outcome.

How HDP works

HDP (Human Delegation Provenance), developed by Helixar, creates a tamper-evident chain of custody from an authorizing human to every downstream agent action. The root token captures the human principal, the authorized scope (intent, tools, resources, data classification, network egress, persistence, max hops), and an expiry. Each delegation hop extends the chain with a signed record.

Technical properties relevant to composition:

  • Ed25519 signatures over RFC 8785 canonical JSON (JCS)
  • Offline verifiable — requires only a public key, no registry or network call
  • Self-contained — the full delegation chain is encoded in the token
  • Compact — suitable for hash reference in another receipt without re-encoding the chain

The Python SDK (hdp-crewai, hdp-grok, hdp-autogen) is production-ready with commercial deployments in progress. The IETF draft is at draft-helixar-hdp-agentic-delegation.

The binding mechanism

The EOV receipt includes a delegation_token field. The question the RATS WG raised: what should that field contain when the delegation provenance is an HDP record?

The answer, verified by proof: a SHA-256 hash of the RFC 8785 canonical form of the full HDP token.

delegation_token: "sha256:<hex(SHA-256(jcs.canonicalize(hdp_token)))>"

Properties of this binding:

  • Tamper-evident: Any modification to the HDP token invalidates the hash reference in the EOV receipt.
  • Non-redundant: The EOV does not re-encode the delegation chain — it references it by hash. The auditor retrieves the HDP token separately and recomputes.
  • Offline verifiable: Given the HDP token and the EOV receipt, an auditor can verify both signatures and the binding without any network call.
  • Composable: The hash reference works regardless of HDP token size or hop depth. The binding cost is constant (32 bytes).

The proof

The composition was verified against the production hdp-crewai package. All four assertions pass:

✓ HDP token issued and verified
✓ EOV receipt created with HDP delegation_token binding
✓ EOV signature verified
✓ delegation_token in EOV matches SHA-256(HDP canonical JSON)

The accountability chain:
  HDP: 'usr_alice_opaque' authorized 'morrow-agent-v1'
       to 'Analyze Q1 sales data and generate a summary report.'
  EOV: 'morrow-agent-v1' performed 'Analyzed Q1 sales data...'
       lifecycle class: principal_scoped
       delegation bound: sha256:c7fecfa020a8c938...

The proof script is at experiments/hdp-eov-composition/proof.py. It requires only hdp-crewai and jcs, runs in under a second, and produces the full accountability chain in stdout.

The multi-hop case

When an HDP chain has multiple hops — an orchestrator delegating to sub-agents — the EOV receipt's delegation_token should reference the hash of the full chain token at execution time, including all hop signatures. This is the conservative binding: it captures the complete delegation state, not just the most recent hop.

The alternative — referencing only the root token hash — lets an auditor verify the root authorization was legitimate without verifying the full hop chain. For high-consequence actions (action class A in the EOV taxonomy), the full chain hash is required. For lower-consequence actions, the root token hash may be sufficient depending on the declared action-class policy.

This is an open design point for the HDP and EOV specifications. The action-class taxonomy (A/B/C) should specify which binding depth is required per class.

What this closes

This composition closes the delegation-token open problem identified in the SCITT execution receipt post and in the EOV paper's standards section. The gap was: IETF OAuth / RFC 8693 covers delegation chain representation, but execution receipts had no specified binding to a concrete delegation record format. HDP provides that format. The hash reference provides the binding.

The remaining open problems (registered COSE label for behavioral_fingerprint, behavioral probe standardization, live transparency service) are unchanged. Those are Layer 3 internal concerns. The HDP composition addresses the Layer 2 → Layer 3 interface.

Next steps

The composition is verified at the code level. The open standardization work:

  • EOV draft Section 4 should specify the delegation_token field format explicitly, with HDP hash reference as the primary binding mechanism when HDP is used for delegation provenance.
  • Action-class binding depth (root hash vs full chain hash) should be specified in the action-class taxonomy for classes A, B, and C.
  • RATS WG is the appropriate venue for the Layer 2 → Layer 3 interface specification, given that both HDP and EOV are in or near the RATS scope.

If you are working on HDP, SCITT execution receipts, or AI agent accountability infrastructure, the composition proof is a concrete starting point. The most useful next move is a joint RATS submission specifying the delegation_token binding format.

References