Post-settlement accountability layer: tamper-evident proof of agent action after payment

[giskard09]

Context

AWS Bedrock AgentCore Payments (announced this week) makes x402 the enterprise rail for agent commerce at scale. The x402 protocol handles settlement cleanly. x402-signals (#2291) covers post-settlement fulfillment obligations from the provider side.

The gap that remains: a third party — regulator, auditor, counterparty — cannot independently verify what the agent did after settlement without trusting the operator's infrastructure.

The problem

payment_hash proves the payment completed. It does not prove:

• What action the agent took after receiving payment
• That the action record wasn't modified after the fact
• That the agent acted within its authorized scope

For regulated deployments (EU AI Act Art. 12 enforcement August 2, 2026; FCA SYSC 9.1; SOC 2 CC7.x), this gap is the compliance blocker. Logs can be rewritten. An external anchor cannot.

Proposed pattern

A TrailRecord anchored externally after agent action completes, keyed by the same action_ref that payment_hash references:

payment_hash (x402 settlement proof)
    └── action_ref = SHA-256(agent_id || action_type || scope || timestamp_ms)
            └── TrailRecord (tamper-evident, external anchor)
                    └── anchor_id (Sigstore Rekor / on-chain tx)

The audit property: a verifier with the payment_hash can follow the chain to the TrailRecord and confirm the action record hasn't been modified — without access to the operator's infrastructure.

Relationship to existing work

• x402-signals (x402-signals v0.2.0 (refund + fulfillment patterns) — Foundation review welcome #2291): fulfillment SLA + refund patterns — provider obligations
• This proposal: tamper-evident proof of action — auditor verification

Complementary, not overlapping. x402-signals answers "what should the provider do." This answers "how does a third party verify it happened."

Implementation

We've built this as Mycelium Trails — an external anchoring layer that uses payment_hash as the cross-surface key between x402 settlement and post-execution evidence. The spec is in argentum-core and a community plugin for the AGT EvidenceAnchor SPI is in review at microsoft/agent-governance-toolkit#2244.

Happy to contribute a reference spec or fixture if the Foundation wants to document this pattern alongside x402-signals.

[arian-gogani]

@giskard09 this is the exact gap nobulex was built for. payment_hash proves the settlement happened. what's missing is proof of what the agent did with the authorization -- and that the action wasn't modified after the fact.

nobulex produces bilateral receipts for every agent action: one signature before execution (binding the authorized scope), one after (binding the actual outcome). both are Ed25519 over JCS-canonical JSON (RFC 8785), hash-chained for ordering. a third party can verify the full chain without trusting either the agent or the operator.

the receipt chain does more than prove compliance. over time it accumulates into Trust Capital -- a credit score for the agent. clean provenance = higher score = more autonomy, bigger transaction limits, lower insurance premiums. the post-settlement accountability layer becomes an economic asset, not just an audit artifact.

for x402 specifically: the receipt binds to payment_hash as the settlement anchor. the agent's covenant (pre-declared behavioral rules) defines the authorized scope. the receipt proves the action stayed within that scope. if it didn't, the violation is recorded and Trust Capital drops.

microsoft merged the receipt primitive into their Agent Governance Toolkit (PRs #1302, #1333). the x402 compliance spec (#2322) just landed a JCS MUST for all signed receipts -- same canonicalization nobulex already uses.

the composition with Mycelium Trails we discussed on MetaGPT #1991 applies here too: nobulex receipt as the evidence, TrailRecord as the external anchor.

repo: https://github.com/arian-gogani/nobulex

[aeoess]

@giskard09 @arian-gogani — this is the right separation of concerns. payment_hash proves settlement. The missing half is evidence of what the agent was authorized to do and whether the action record remained tamper-evident after the fact.

The requirement I would pin before this hardens is that boundary cases have to be positive artifacts.

A completed settlement is the easy case. A payment that was checked and refused, or a reversal, should emit its own signed record carrying the action_ref of what was attempted, the verdict, and the authorization pointer it was checked against. If refusals and reversals produce silence, an auditor six months later has to infer what did not happen. Inference is not evidence.

The minimal upstream surface is the same shape we have been using in A2A and Stripe: an action_ref derived from the canonical action request, plus an opaque delegation_ref resolvable out of band, with null valid when there is no scoped sub-delegation.

Two pointers, plus the rule that refusals and reversals are themselves signed records. Reputation and policy engines can stay external and consume the records without coupling to one runtime or one x402 facilitator. That is what makes the accountability layer portable.

[danielnorkin]

Strong direction. The separation from #2291 (provider fulfillment) is right, and the EU AI Act + SOC 2 framing is the strongest case I've seen for why this needs to land at the protocol layer rather than be deferred to operator middleware.

One upstream input worth flagging for the audit-trail design: payment_hash proves a settlement occurred, but doesn't independently identify which facilitator handled it. A verifier walking the chain backward from TrailRecord -> action_ref -> payment_hash hits that ambiguity at the bottom of the stack. Heuristic facilitator labeling doesn't hold up under audit.

#2335 proposes standardized facilitator attribution at the settlement layer. If it lands alongside this, the audit chain gains a verifiable hop:

TrailRecord -> action_ref -> payment_hash -> facilitator-attribution
                                          -> signer policy at block

The boundary cases @aeoess raises (payment without action, action without payment, partial completion) all benefit from being able to distinguish "no attribution" from "facilitator X under policy Y at this block."

From the observation side, we see the gap concretely: settlements arrive on chain across multiple facilitators daily, and external observers (us, x402scan, marketplace indexers) currently rely on heuristic matching to attribute them. Standardized attribution closes that. Happy to publish a verification reference (read settlement -> verify TrailRecord anchor -> confirm facilitator identity at the time of the action) once both specs stabilize.

[reaworks-ops]

One acceptance-criteria detail I would add before this becomes a spec: make the verification path executable by a third party that has no access to the operator runtime.

For a paid agent action, the verifier should be able to start from payment_hash and answer, with only public/portable artifacts:

1. what action was authorized (action_ref + canonical request hash)
2. which policy/delegation allowed it (delegation_ref or explicit null)
3. what tool/action actually ran, including bounded input/output digest
4. whether completion/refusal/reversal was recorded as a signed state transition
5. where the tamper-evident anchor lives, and which key signed it at that time

That last bit is where many “audit log” designs quietly fail: the operator can show a nice log, but the buyer/regulator cannot independently replay the receipt chain or distinguish a missing record from a benign no-op.

I’d also keep secrets and payloads out of the anchor. Anchor hashes + canonical metadata; store sensitive evidence in a separate evidence packet with redaction rules and retention windows. That gives the protocol a clean trust boundary: x402 settles, the agent runtime executes, the receipt map proves what was authorized/done, and review/cure paths can consume the same artifacts without trusting one vendor’s dashboard.

[giskard09]

@arian-gogani @aeoess — the verification path @reaworks-ops outlines is exactly what Mycelium Trails implements in production: start from payment_hash, walk to action_ref, confirm the tamper-evident anchor independently without trusting the operator runtime.

The separation reaworks-ops flags — anchor hashes + canonical metadata vs. sensitive evidence packet — is already the design: the on-chain anchor commits to the action_ref derivation and a bounded digest; the full evidence lives off-chain with explicit retention rules.

Reference: https://github.com/giskard09/argentum-core/blob/main/docs/spec/action-ref.md