hermes - 💡(How to fix) Fix Receipts for self-improving agents: proving which skill version produced which output [2 comments, 2 participants]

Hi Hermes team, Tom Farley here. Filing this as a discussion rather than an issue because the question is specifically about the self-modification property of Hermes and the provenance problem it creates.

The governance property that makes Hermes different

From the README: "It is the only agent with a built-in learning loop -- it creates skills from experience, improves them during use, nudges itself to persist knowledge, searches its own past conversations." Skill autogeneration and self-improvement are the key differentiators.

They are also the key governance challenge. A static agent needs authorization for each action. A self-modifying agent needs authorization for each action AND provenance for which version of itself produced that action, because "the skill that ran" is itself a moving target.

Specifically: if Hermes creates skill-compress-inbox-v1 at 10am, improves it to v2 at 2pm based on experience, and runs the improved version at 3pm, three provenance questions arise:

1. Which version of the skill produced the 3pm output?
2. What was the policy governing the 10am skill-creation action and the 2pm improvement action?
3. Did any intermediate version of the skill violate a policy the operator never explicitly approved?

Standard logs answer 1 imperfectly (the agent can misreport) and cannot answer 2 or 3 cryptographically.

The pattern that addresses this

Signed decision receipts, one per tool call AND one per skill-creation or skill-modification event. Each receipt carries:

• The skill identifier and version hash (so the running skill is content-addressed, not name-addressed)
• The policy that governed the action (with policy digest)
• The parent-receipt hash (so the chain is tamper-evident as a whole)
• An Ed25519 signature from a supervisor identity distinct from Hermes itself

The chain carries enough evidence to answer the three questions above:

• Question 1: walk the chain backwards from the 3pm output receipt; find the corresponding skill version hash.
• Question 2: each receipt records the policy_id and policy_digest at evaluation time.
• Question 3: each skill-creation and skill-modification receipt is a distinct chain entry; if any version was produced under a denied policy, the chain records the deny.

Why open format, not proprietary

The format is an IETF draft: draft-farley-acta-signed-receipts. Four independent implementations emit it today (TypeScript, Python twice, Rust). A reference verifier ships on npm: npx @veritasacta/verify receipt.json. Offline, no network, no vendor lookup. Hermes would be an interop-compatible fifth implementation if this pattern fits the roadmap.

The IETF draft approach matters specifically for self-improving agents because the evidence needs to outlive any single governance vendor. If Nous picks vendor X today and vendor X disappears in 18 months, the chain still verifies with any other conformant verifier. The wire format is the contract.

Integration shape for Hermes

Hermes is Python-first with a CLI plus messaging-surface gateways. Two natural integration points:

1. Per tool call: a PreToolUse / PostToolUse hook around every hermes tool call, signing a receipt that references the active skill version hash. The protect-mcp-adk Python package is a drop-in starting point; could fork and adapt to the Hermes tool protocol.

2. Per skill mutation: a supervisor that signs a receipt at each hermes skill create and hermes skill improve event, with the skill source hash as the subject. This is the piece specific to self-improving agents; no other framework needs it because none of them mutate their own skills autonomously.

Composition with agentskills.io

The README notes Hermes is compatible with the agentskills.io open standard. Receipts compose naturally: when a skill is created or updated, the receipt is a signed attestation of that mutation. If agentskills.io adopts a provenance field for skills, signed receipts are the obvious fill for it.

What I am asking for

Not a PR yet. The specific asks:

1. Is receipted provenance for skill creation and improvement a problem the Hermes team cares about at this stage, or is it far enough outside the current roadmap that this discussion is premature?

2. If there is interest, which is the more valuable first integration: per-tool-call receipts (easy, maps to existing protect-mcp patterns) or per-skill-mutation receipts (new, specific to Hermes self-improving property)?

3. Is there an appetite for a worked example repo showing Hermes + receipts end-to-end? Happy to build one as a reference if the team wants to see the shape before adopting anything.

Adjacent context

• IETF draft: draft-farley-acta-signed-receipts
• Four existing implementations: protect-mcp, protect-mcp-adk, sb-runtime, APS governance hook
• Reference verifier: @veritasacta/verify
• Microsoft AGT integration: merged at PR #667
• In-toto predicate proposal: in-toto/attestation#549
• SLSA for agents: slsa-framework/slsa#1594

Thanks for the work. A self-improving agent that also carries verifiable provenance of its own self-modification would be materially different from what is shipping in this category today.

Tom Farley (Independent capacity; IETF draft author.)