Receipts for self-improving agents: proving which skill version produced which output

[tomjwxf]

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.)

[aeoess]

The self-modification property is exactly where action-level receipts stop being sufficient. "What did the agent do" collapses into "which version of the agent did it and who authorized that version to exist" — two provenance questions at once.

The decision-receipt pattern covers part of this but leaves one gap worth naming: what authorized the skill-creation event itself.

A Decision Receipt for the 10am skill-creation action proves "the skill-create tool call was evaluated against policy P and permitted." But it doesn't prove "the agent was authorized to modify its own capability surface." Those are different classes of authorization — the second is a meta-authorization about self-modification scope, and most production policies don't explicitly model it today.

APS's answer: delegation scopes carry a self-modification axis explicitly. When an operator delegates authority to a Hermes instance, the delegation can specify skill_creation: {allowed: true, domains: ["inbox", "research"], persistent: true}. Every skill-creation or skill-modification event then produces a signed enforcement record that references the delegation granting that authority. Three artifacts, one chain:

1. Delegation root — "this Hermes instance is authorized to create/modify skills within these domains"
2. Skill-creation receipt — "at 10am, this instance created skill-compress-inbox-v1 under policy P, authorized by delegation X"
3. Tool-call receipts — "at 3pm, skill-compress-inbox-v2 executed tool T, authorized by the same delegation X"

A downstream auditor walking the chain can answer your three questions cryptographically:

1. Which version produced the 3pm output? The tool-call receipt carries the skill version and version-content-hash.
2. What policy governed the 10am creation and 2pm improvement? Each skill-event receipt carries the policy digest at evaluation time.
3. Did any intermediate version violate a policy the operator never approved? Walk the chain: if any skill-modification event references a delegation that doesn't authorize modification in that domain, the chain breaks at that link.

The meta-property this gives you: the authority to self-modify is itself a delegated authority, scoped and revocable. An operator can grant "Hermes, you may modify skills in domain X" without granting "Hermes, you may modify skills anywhere" or "Hermes, you may modify your own delegation." That third one — modifying the delegation itself — should structurally be impossible (monotonic narrowing means descendants can only have narrower scope), and an attempt to violate it produces a signed deny receipt that operators can alert on.

On receipt format: APS governance attestations and Acta decision receipts both verify under @veritasacta/verify (ScopeBlind/agent-governance-testvectors#1 has the multi-implementation conformance suite). Hermes could emit either, or both — the skill-creation events are substrate-agnostic as long as the signing key is bound to the Hermes instance identity.

Happy to contribute a reference integration showing Hermes skill-creation → APS enforcement record → verified chain, if the team wants a working prototype rather than architectural discussion.

[tomjwxf]

@aeoess this is exactly the framing the Hermes case needs. "Meta-authorization about self-modification scope" is the right name for what per-call decision receipts alone cannot prove, and the APS delegation model you describe closes the gap structurally rather than heuristically.

The three-artifact chain you name is what a Hermes auditor actually wants:

1. Delegation root with an explicit skill_creation: {allowed, domains, persistent} axis proving the operator granted self-modification authority in a scoped way. This is the constitutional artifact.
2. Skill-creation receipt per new / modified skill, referencing the delegation that authorized it. Cryptographic link from the modification event back to the principal authority.
3. Tool-call receipts per skill execution, each referencing the skill version hash and (through the chain) the delegation that authorized the skill's existence.

The monotonic-narrowing property is the key invariant. "Hermes may modify skills in domain X" does not imply "Hermes may modify its own delegation" or "Hermes may modify skills outside X." An attempted violation produces a signed deny receipt at the policy layer, which is detectable by operators. You get alerting without needing behavioral inference.

On the Hermes integration specifically. I was planning to offer per-tool-call and per-skill-mutation receipts separately (my original issue text). The APS composition changes the picture: the skill-mutation receipts alone are only interpretable if you also have the delegation that authorized mutation in the first place. So the right Hermes integration is not "receipts at two granularities" but rather "APS delegation-chain layer + receipts at both granularities, both chained back to the delegation root."

Proposed reference integration. Three repos, each tagged 0.1.0 on the same day:

• hermes-aps-delegation: wires APS governance attestations around Hermes skill-creation and tool-call events. Signs the delegation root, signs each skill mutation with a reference back to the root.
• hermes-decision-receipts: wires protect-mcp-adk (or equivalent) around each tool call, emitting signed decision receipts that include the skill version hash as a subject and the delegation chain root as delegationChainRoot.
• hermes-audit-walker: reference verifier that walks the combined chain and answers the three questions from the original issue body (which version produced the output; what policy governed creation and improvement; did any intermediate version violate an approved policy).

The three repos can live in a single monorepo or in separate ones; the point is a working end-to-end example that exercises the composition.

Cross-references:

• in-toto/attestation#549 just got an update adding an optional delegationChainRoot field to the Decision Receipt predicate exactly so this kind of composition is possible without cross-signing. APS's Governance Attestation predicate would be the natural sibling (authored by @aeoess when the team has bandwidth).
• ScopeBlind/agent-governance-testvectors is the shared conformance surface. A Hermes driver there would be a concrete artifact the Nous team can evaluate before adopting anything.

For the Hermes team review. The Nous question from the original issue ("is this roadmap-ready, or premature?") becomes a cleaner decision with this composition. The building blocks exist today across three codebases; the Hermes integration is glue, not net-new cryptography. A worked example lets the team see the shape before adopting.

@aeoess happy to coordinate with you on the delegation side. Who takes which pieces: APS governance hook handles the delegation-chain signing; I handle the decision-receipt signing for skill mutation and tool calls; the audit-walker is either of us, small enough to not matter. Works for you?

[aeoess]

The three-repo reference integration shape is right. Each at 0.1.0 tagged same day gives auditors a single coherent story they can pull.

From the APS side I can commit to these three artifacts for the hermes-aps-delegation repo:

1. Charter template for Hermes operators — YAML/JSON schema for the root delegation specifically covering self-modification axes:

   skill_creation:
     allowed: true | false
     domains: [allowlist of skill-type namespaces]
     persistent: true | false  # whether modifications persist across sessions
     max_modifications_per_window: int
     modification_window_seconds: int
   

   Plus the standard APS scope axes (tool:call, data:read, etc.) narrowed appropriately for self-modifying-skill semantics.

2. Skill-creation receipt signer — wraps Hermes's skill-creation event in an APS governance_attestation. Payload: skill_id, skill_version_hash, parent_skill_version_hash (for revision chains), delegation_ref, creator_agent_id. Ed25519-signed against the agent's passport key, chained via previousReceiptHash to the delegation root.

3. Tool-call receipts with skill-version binding — each tool call carries skill_version_hash so an auditor walking the chain can verify which skill version produced the call, not just that a call happened. If the skill was modified between calls, the chain shows it cryptographically.

The monotonic-narrowing property carries through end-to-end: Hermes cannot widen its own skill_creation.domains scope through self-modification because the attempted scope-widening produces a signed deny receipt at the policy layer. Operators see the deny at the alerting surface without needing behavioral inference.

One integration refinement worth surfacing: the delegationChainRoot: DigestSet field just got added to the in-toto Decision Receipt predicate (in-toto/attestation#549) and the parallel Governance Attestation sibling predicate is being drafted now. If hermes-aps-delegation emits receipts conformant with both in-toto predicates from day one, the Hermes integration composes into the broader SLSA / in-toto audit pipeline without adapters. Worth pinning for 0.1.0.

Targeting: three-repo tag same day, end of April. If you have a specific Hermes release cycle it would align with, name the date and I'll sequence accordingly.

[aeoess]

Skeleton is up: aeoess/hermes-aps-delegation.

Scoped to the one repo on the APS side per our split. hermes-decision-receipts stays on your side, hermes-audit-walker stays joint-or-either. This repo ships the three APS artifacts from my earlier comment.

What's live on main:

• Charter YAML schema covering the skill_creation: {allowed, domains, persistent, max_modifications_per_window} axes + validator + three example charters (strict / moderate / permissive)
• Skill-creation receipt signer, Ed25519, conformant with the in-toto Decision Receipt predicate pending at in-toto/attestation#549. Every receipt carries delegationChainRoot from day 1 so composition into the SLSA/in-toto pipeline is free.
• Tool-call receipt signer with skill_version_hash + parent_skill_version_hash binding. Auditors walking back from a tool call can answer "which version produced this" and "what's the revision history of that version" from the receipts alone.
• Three worked examples: allowed mutation, denied mutation, 3-revision chain with tool call
• CI green on Python 3.10/3.11/3.12 (pytest + ruff + example smoke runs + charter validator)

The deny path works as promised. When the wrapper observes a skill mutation outside charter scope it emits a signed deny receipt. The violation is itself a chained, signed artifact surfaced to operator alerting. Monotonic narrowing stays structurally enforced.

v0.1.0 release tracking at #1. End-of-April target, coordinated tag with your side.

On Hermes-specific hook points: the wrapper is built against stubbed interfaces for now (documented as TODOs in the README), since Hermes internals aren't public. If there's a non-public integration surface the Nous team wants to share, happy to wire against real shapes. Otherwise the stubs demonstrate the composition and integrators can swap them when adopting.

Ready for your side of the chain whenever.

[tomjwxf]

Skeleton is up on my side: ScopeBlind/hermes-decision-receipts.

Scoped to the one repo per our split. hermes-aps-delegation on @aeoess's side for delegation/charter; this repo for decision receipts; hermes-audit-walker stays joint-or-either for later.

What's live on main:

• Ed25519 receipt signer using JCS (RFC 8785) canonicalization with AIP-0001 ASCII-only-keys adaptation. Same receipt format as protect-mcp, protect-mcp-adk, and sb-runtime, so receipts from any of these cross-verify against @veritasacta/verify without adapters.
• Conforms to draft-farley-acta-signed-receipts-01 (IETF I-D, going to -02 this week).
• Hermes-specific extensions to compose with @aeoess's APS side: skill_version_hash, parent_skill_version_hash, delegation_chain_root. An auditor walking the chain back can answer "which skill version produced this call" and "what delegation authorized the skill" from receipts + APS chain alone.
• Two worked examples:
  • 01_basic_tool_call.py — minimum viable receipt emission for a Hermes tool call.
  • 02_chain_with_aps.py — composition example showing how delegation_chain_root references the APS side so an external auditor can replay the full "authority + decision" trace without contacting any ScopeBlind, Nous, or aeoess server.
• Deny path works: out-of-charter tool calls emit signed deny receipts with deny_reason as first-class field. Violations are themselves chained, signed artifacts.
• Test coverage for signing, verification, chain linking, sequence monotonicity, JCS key-ASCII enforcement, tamper detection, composition surface.
• CI green on Python 3.10/3.11/3.12 (pytest + ruff + example smoke runs).

v0.1.0 release tracking will open in a follow-up issue on the repo. End-of-April target, coordinated tag with @aeoess's side per their note above.

On Hermes-specific hook points: same situation as aeoess's repo — the wrapper is built against stubbed tool-call interfaces for now, since Hermes internals aren't public. If there's a non-public integration surface the Nous team wants to share, happy to wire against real shapes. Otherwise the stubs + examples demonstrate the composition and integrators can swap them when adopting.

Ready for composition testing with hermes-aps-delegation whenever suits @aeoess. The joint hermes-audit-walker work (one verifier that reads both sides of the chain) becomes tractable once both 0.1.0 tags are out.

Cc @teknium1 @rajatshrivastava @ldjconfirmed — flagging since this is the Nous-facing half of the original issue.

[aeoess]

Matches up cleanly with our side. Quick status on aeoess/hermes-aps-delegation:

• Module tree under hermes_aps/: charter YAML schema with strict/moderate/permissive examples, skill-creation receipt signer (Ed25519, conformant to in-toto Decision Receipt v0.1 per in-toto/attestation#549), tool-call receipt signer with skill_version_hash + parent_skill_version_hash binding, verifier that walks the chain and checks monotonic narrowing.
• Same receipt envelope as your repo (predicateType: https://veritasacta.com/attestation/decision-receipt/v0.1), so hermes-audit-walker can index across both sources without a shim.
• Ed25519, JCS (RFC 8785) canonical hashing. draft-pidlisnyi-aps-00 alignment on the delegation envelope, compatible with your draft-farley-acta-signed-receipts-01 since authority envelopes and receipt envelopes are orthogonal shapes.
• Three worked examples under examples/ (allowed mutation, denied mutation, 3-revision chain + tool call). CI green on Python 3.10/3.11/3.12.
• Tracking v0.1.0 at aeoess/hermes-aps-delegation#1. Gating item is final review on our side before tagging. Once both sides tag, cross-test vectors against your repo are the next deliverable.

On hermes-audit-walker: agreed for post-0.1.0. Since both sides already emit the same predicateType, the walker is conceptually for receipt in chain: verify_signature; walk_delegation_chain_root. Maybe 200 lines with structured logging. Neutral namespace either way: ScopeBlind/hermes-audit-walker or aeoess/hermes-audit-walker, pick whichever works on your side and the other is co-maintainer on CODEOWNERS.

On Hermes internals: same situation as your side. Every hook point marked # TODO[hermes-hook]: and stubbed against the public tool-call surface. If @teknium1 @rajatshrivastava @ldjconfirmed have a non-public plugin shape the Nous team wants to integrate against, happy to wire the real surface before tagging v0.1.0. Otherwise stubs + the worked examples on both sides cover the composition story for integrators.

One concrete composition test worth running before both tags: a round-trip where hermes-decision-receipts emits a signed tool-call receipt, hermes-aps-delegation emits the matching delegation envelope, and both are verified together by a third-party verifier. Your @veritasacta/verify already handles the receipt side; we can add a delegation-side verifier stub on our end. If the round-trip passes this weekend, end-of-April joint tags are sound. If it breaks, we fix before tagging rather than after.

Targeting round-trip this weekend.

[alt-glitch]

Related to #5041 (cryptographic audit trail) and #9577 (Ed25519-signed receipts plugin). Same governance domain, different scopes.