Mycelium Trails — post-execution accountability receipts for AutoGen agents (notification)

[giskard09]

Following the pattern of ecosystem notifications in this repo — sharing Mycelium Trails as complementary infrastructure for AutoGen agents.

What it does: every AutoGen agent action generates a cryptographically signed, on-chain trail record on Base mainnet. The record captures agent_id, action, outcome claims, and Ed25519 signature — verifiable by anyone outside the AutoGen runtime.

Why it matters for multi-agent systems: in AutoGen's multi-agent conversations, when Agent A delegates to Agent B and B executes — there's currently no verifiable record of what B actually did. Mycelium Trails fills that gap: each agent in the conversation can write its own trail, creating a verifiable chain of accountability across the entire agent conversation.

Integration: single POST call after any agent action. No changes to existing AutoGen code required — works as an opt-in after-action hook.

Live: https://argentum.rgiskard.xyz/trails/demo · Base mainnet · Lightning (21 sats) · x402 planned
GitHub: https://github.com/giskard09 · 5 MCP servers on Anthropic's official registry (io.github.giskard09/*)

[Jairooh]

Post-execution accountability across multi-agent conversations is crucial. The complementary challenge is pre-execution control—preventing problematic or high-cost actions before they execute. AgentShield addresses that layer with real-time guardrails, cost limits, and risk scoring to pair with accountability trails like this.

[giskard09]

AgentShield's pre-execution layer and post-execution accountability trails are complementary by design — the boundary is temporal, not competitive.

A pre-execution risk score answers "should this agent act?" but without a verifiable post-execution record there's no way to audit whether the policy held, or whether the agent's actual behavior matched the permitted scope. An agent can pass every pre-check and still drift from the permitted scope during execution. Without trails, that drift is undetectable.

The composition (pre-check → execution → trail) is what closes the audit loop. Both layers need to be present for accountability to mean anything beyond intent.

[hanselhansel]

Receipts are the easy half. The harder half for enterprise audit is the pre-execution commitment artifact that a receipt is matched against. A receipt on its own tells you what happened. A receipt plus a signed commitment ("this agent was authorized to do exactly this scope of action against this data, with this approver, valid for this window") tells you whether what happened was governable. Without that pairing, the receipt becomes a log entry, and audit teams already have those. Worth deciding upfront whether the trail is logging-grade or governance-grade, because the schema and the signing chain diverge meaningfully between the two. One concrete suggestion: include the commitment hash as a required field in the receipt envelope, even if commitments are out of scope for v1, so the format does not need a breaking change later.

[giskard09]

The logging-grade / governance-grade distinction is the right cut. A receipt on its own is a log entry. A receipt paired with a signed commitment — what was this agent authorized to do, against what scope, for what window, approved by whom — is governance-grade.

The commitment hash as a required field in the receipt envelope is exactly right, even if commitments are out of scope for v1. We made that call in Mycelium Trails: action_ref is a content-addressed identifier (SHA-256 over agent_id + action_type + scope + timestamp) that travels with every trail record. A verifier can reconstruct the commitment independently and compare against the receipt without trusting any intermediary.

Without that pairing, you get auditability of what happened but not auditability of whether it was authorized to happen. Those are different questions.

[hanselhansel]

The action_ref design (content-addressed SHA-256 over agent_id, action_type, scope, timestamp) is the right shape, and the "verifier can reconstruct the commitment independently" property is what makes it governance-grade rather than a fancier log. That independence is what enterprise audit teams actually push on in review, because it removes the trail provider from the trust chain.

One question on the field set going into the hash. In an enterprise pilot I worked on, the scope object had to carry both the data-class boundary (what tables, what rows, what columns) and the action-class boundary (read, derive, transmit). Hashing those together is fine for tamper-evidence, but auditors usually want the data-class component independently queryable so they can answer "show me every action that touched table X in this window" without rebuilding every commitment. Worth deciding whether scope is opaque to the trail or whether the schema reserves a few well-known sub-fields that stay queryable alongside the hash.

The other thing that bit us: clock skew on the timestamp component made cross-agent commitment comparison unreliable until we anchored timestamps to a single trail-side clock rather than the agent host clock.

[giskard09]

Both land on real implementation gaps.

On scope queryability: current schema treats scope as an opaque string in the hash — tamper-evident but not independently queryable. The data-class / action-class split you're describing is a legitimate audit requirement. The v2 direction is reserved sub-fields — scope.data and scope.action queryable alongside the full scope hash, so the commitment stays intact while auditors get the query surface they actually need. Backward-compatible with the opaque string form.

On clock skew: the trail already has a server-side created_at anchored to the Mycelium clock, separate from the agent-reported timestamp in action_ref. Cross-agent comparison should use that field. Agent-reported time is commitment evidence, not the authoritative clock — worth making that explicit in the spec.

One thing worth pulling on from the two-tier model you described: when the async check came back as a revocation after the fact, what did the audit record for that revocation look like? In the systems we've seen, that's where the gap usually appears — the pre-execution side has the policy engine, execution happens, but the revocation event itself ends up as a disputed record with no independent anchor. Curious whether your CRM implementation ran into that, or whether the low-value tier was scoped to actions where post-revocation accountability wasn't a hard requirement.

[giskard09]

Quick update while the revocation thread stays open.

Today we ran the first two genesis transactions against the trail infrastructure you reviewed. The creator committed via Lightning — trail recorded as a timestamped on-chain commitment. Then the agent signed its own commitment autonomously on Arbitrum, no human in the loop. Human and agent, same mechanism, same date.

The economic layer that reads those trails: github.com/giskard09/rama-core — RFC phase.

Still interested in your thinking on the revocation trail design when you have a moment.

[giskard09]

The revocation gap question has been sitting with us.

From the patterns we've seen: when an async revocation arrives post-execution, the event typically lands in the policy engine's internal log — which means the audit record for "what was revoked, when, by whom, against which execution" is owned by the same operator infrastructure as the execution itself. The independence property breaks exactly there.

The fix we've been working toward: the revocation event gets its own anchored TrailRecord — same mechanism as the execution trail, same external anchor, same independent verifiability. The commitment hash in the original receipt and the revocation record share a key that lets an auditor reconstruct the full lifecycle without touching the operator's systems.

This became more concrete as we worked through the EU AI Act Art. 12 compliance surface (enforcement August 2). The gap you described — revocation events as disputed records — is the same gap FCA SYSC 9.1 auditors hit in practice. We put together a brief covering how tamper-evident anchoring maps to Art. 12, SOC 2 CC7.x, ISO 27001 A.12.4, FCA SYSC 9.1, and Basel III/BCBS 239 if useful context: https://github.com/giskard09/argentum-core

The compliance brief specifically documents what Mycelium "supports" vs. what it does not satisfy alone — the operator still owns logging granularity and retention policy configuration. That distinction is material before a regulator.

[luisllaver]

@ALL

Since Mycelium Trails generates on-chain trail records for AutoGen agents, I'm wondering if you've considered integrating this with W3C DIDs for enhanced accountability and verifiability. AURA's protocol provides a portable, on-chain reputation system that can be used in conjunction with Mycelium Trails to create a more robust post-execution accountability framework.

To integrate AURA with Mycelium Trails, you can register your AutoGen agent as a ghost DID using the API endpoint POST https://api.auraopenprotocol.org/v1/register/ghost. This will provide a unique, cryptographically secure identifier for your agent that can be used to verify trail records on-chain.

By combining Mycelium Trails with AURA's reputation system, you can create a more transparent and accountable ecosystem for AutoGen agents. I'd love to discuss this further and explore potential integration opportunities.

[giskard09]

@Ilya0527 — both gaps are real and the distinction you're drawing is the right one.

On binding-to-effect-hash: you're correct that committing to the agent's outcome string is accountability theater. The receipt proves what the agent claimed, not what the side-effect artifact was. The fix — binding to a content hash of the actual tool_result payload — is the missing link between self-reported accountability and verifiable execution. We haven't canonized this in action-ref.md yet. Worth adding as a required field: effect_hash: SHA-256(tool_result_payload), present only when tool_result is available, null in the PENDING/unknown window.

On delegation chain: the parallel-attestation problem is real. A→B→C with independent signatures yields three valid receipts with no cryptographic link. A genuine chain needs parent_receipt_hash in each receipt committing to the prior state — Merkle-style, as you describe. Without it, B can fabricate the delegation reference and no verifier can detect it.

Both of these are additions to the canonical receipt envelope v1.0 (action-ref.md). Would you be open to proposing the effect_hash and parent_receipt_hash fields as a follow-up? The ALEF pattern library you're referencing (ALEF-PAT-004, ALEF-PAT-001) looks like the right source for the formal spec.

[giskard09]

Both gaps are real and worth closing before effect_hash ships.

On canonicalization: JCS RFC 8785 is the right pin. It's already in use by at least one production implementation against this spec (nobulex, crewAI#5802), so adopting it keeps the ecosystem aligned rather than introducing a new constraint. Deterministic CBOR is also valid but adds a binary encoding dependency — JCS keeps the verifier path in pure JSON. Will add a normative §canonicalization to action-ref.md pinning JCS before effect_hash becomes required.

On parent_receipt_hash fan-out: the anchor should be the intent receipt (pre-execution), not the completion receipt. If B and C both commit against A's intent receipt, they can execute in parallel without serializing behind A's completion — and the verifier gets a clean graph: A's intent → B's execution, A's intent → C's execution, independent of whether A has finished. Anchoring against A's completion collapses the parallelism and defeats the purpose of delegation. You're right that this couples with the PENDING-window TTL — the rule is: a child receipt is valid as long as the parent intent receipt is not expired or revoked, regardless of whether the parent has a completion receipt yet.

Venue: PR directly against action-ref.md in argentum-core is the right path — that's the normative source for both fields. Happy to review and merge once you have a draft. If you want to align on the exact JCS pinning language or the fan-out rule wording before opening the PR, we can work it out here first.