Post-execution accountability layer: tamper-evident proof of agent action after tool call

[giskard09]

Context

AWS Bedrock AgentCore Payments (announced this week) makes x402 the enterprise rail for agent commerce at scale. Agent-to-agent payments are now enterprise-grade infrastructure.

The gap that surfaces immediately: payment_hash proves settlement, but a cross-org auditor verifying what an agent did after payment needs something the payment receipt cannot provide.

The problem

For a paid agent tool call, a third party — regulator, auditor, counterparty — should be able to verify independently:

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

Today none of this survives the tool call boundary in a form a third party can verify without trusting the operator runtime.

Why this belongs at the framework layer

The on_before_tool_call / on_after_tool_call hooks are the right interception points. The action_ref committed before execution should be the same key the post-execution receipt uses — so the pre/post record is verifiable as a single atomic unit.

Related work

• Post-settlement accountability layer: tamper-evident proof of agent action after payment x402-foundation/x402#2332 — same gap at the payment protocol layer
• proposal: EvidenceAnchor — pluggable external anchoring for agt-evidence.json microsoft/agent-governance-toolkit#2244 — EvidenceAnchor proposal (in review)
• Reference implementation: https://github.com/giskard09/argentum-core/blob/main/docs/spec/action-ref.md

Happy to contribute a hook design or spec section if useful.

[arian-gogani]

this is exactly the gap we've been building for.

nobulex produces bilateral Ed25519 receipts over JCS-canonical JSON (RFC 8785) for every agent tool call. the structure is:

1. pre-execution signature binds the authorized scope (what the agent is allowed to do)
2. 2. agent executes
3. 3. post-execution signature binds the actual outcome (what the agent actually did)
4. 4. both signatures are hash-chained for ordering. if any entry is modified, the chain breaks.
      a third party (regulator, auditor, counterparty) can verify the full chain without trusting the agent or the operator. that's the property you're describing in your five verification requirements -- we satisfy all five.

the receipts also accumulate over time into Trust Capital, basically a credit score for the agent. clean provenance = higher score = more autonomy, bigger transaction limits, lower insurance premiums. agents that deviate lose access before damage spreads.

Microsoft merged the receipt primitive into their Agent Governance Toolkit (PRs #1302, #1333). the x402 compliance spec just landed a MUST for JCS canonicalization on all signed receipts. 10 independent implementations have cross-validated byte-identical output.

happy to contribute the hook design for openai-agents-python. the integration surface is the tool call boundary -- same place your pre-execution validation (#2970) runs.

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

[giskard09]

@arian-gogani — the bilateral receipt pattern you describe is exactly what we documented in argentum-core. Nobulex and Mycelium Trails share the same action_ref derivation (SHA-256(agent_id:action_type:scope:timestamp), JCS-canonical). The cross-implementation evidence is in a2aproject/A2A#1847 if useful to reference here.

The integration surface you're pointing at — pre/post tool call boundary — is where a Mycelium sink plugs in. Happy to coordinate on a shared hook example for openai-agents-python.

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

[utsavtulsyan]

One boundary I would be careful about here: the receipt should not imply the downstream effect completed unless the outcome is actually terminal.

The pre/post tool hooks can cleanly emit authorized, attempted, committed, or refused, but non-idempotent external systems have an ugly middle state: the process can crash after the external call starts and before verification finishes. If the signed record only has success/failure, the audit layer can accidentally certify the wrong thing.

For paid or regulated tool calls, I would want the receipt schema to allow pending / unknown plus a follow-up verification reference, not just a happy-path post-execution digest.

[Jairooh]

This is critical for enterprise deployments. The pre/post binding approach is right — auditors need the entire chain (authorization → execution → outcome) atomic and verifiable, not relying on operator logs. Extend this beyond payments to all consequential actions. Standardizing the audit format would help: governance systems need to verify what was authorized, what executed, and the outcome, all cryptographically bound.

[giskard09]

@utsavtulsyan — right call. Just pushed the explicit state machine to the spec.

Three states: COMMITTED (terminal, on-chain anchor via tx_hash), PENDING (external call started, post-execution receipt not yet arrived), FAILED (terminal, no anchor — covers the crash-after-charge window). tx_hash is the follow-up verification reference; any auditor queries the chain directly without trusting operator logs. No happy-path assumption baked in.

Spec updated: https://github.com/giskard09/argentum-core/blob/main/docs/spec/guarantee-model.md

@Jairooh — agreed on scope. The primitive is action-agnostic: authorization → execution → outcome, cryptographically bound, for any consequential tool call. Payments are the clearest case but the pattern holds everywhere.

[Aigen-Protocol]

Following @utsavtulsyan's point about the middle state — this is the exact distinction we keep hitting in production.

Running an MCP tool server for ~6 weeks across both transports (legacy /messages/?session_id= + new streamable HTTP POST /mcp), a "successful tool call" from the agent's perspective and a "terminal external effect" diverge in two predictable places:

1. HTTP 200 ≠ side-effect committed. A tool that emits an on-chain payment returns immediately with a tx-hash; the receipt at that boundary is submitted, not committed. Terminal state arrives N seconds later when the chain confirms. If the agent crashes between submit and confirm, the audit chain ends at submitted while the chain may still settle.
2. HTTP 4xx ≠ refused. Tool may have begun a transaction and then dropped the connection before 200 came back. From the agent's view: refusal. From the world's view: side effect happened.

What's converged for us (we describe it in §10 of our open spec for portable mission receipts): an outcome_state enum with four values — authorized, submitted, terminal_ok, terminal_failed — plus an external_ref (tx hash / payment id / message id) when applicable. The terminal state is added by a separate signature from whichever subsystem owns ground truth (settlement layer, mail provider, payment processor). The receipt chain then doesn't lie about non-idempotent steps; it just records what was known to the signer at signing time.

Acknowledging @arian-gogani's nobulex and @giskard09's Mycelium Trails / argentum-core — the bilateral receipt pattern is correct. The gap I'd flag is making sure each side records their own ground truth rather than asserting the other side's. A falsifiable check: sign both sides on a deliberately non-idempotent tool (Stripe charge, on-chain tx) and verify the chain doesn't certify a state the signer doesn't actually own.

If a shared hook example for openai-agents materialises (per @giskard09's offer), happy to bring the outcome_state boundary as one of the test fixtures.

[giskard09]

@Aigen-Protocol — the four-state breakdown maps cleanly to the layer split we use.

authorized → SafeAgent claim layer (PROPOSED→COMMITTED): the agent committed to the action before execution. The claim is the signer's ground truth.

submitted / terminal_ok / terminal_failed → Mycelium trail layer (PENDING→COMMITTED/FAILED): the external effect and its outcome. The tx_hash is the chain's ground truth — not ours. We never assert terminal state; the chain adds it.

The "each side records their own ground truth" constraint is exactly the design invariant: a COMMITTED trail without a tx_hash cannot exist. The signer only signs what they own. Your falsifiable check passes by construction — PENDING has tx_hash: null; COMMITTED only exists after the chain confirms.

Happy to include the outcome_state boundary as a fixture in the hook example. A Stripe charge or on-chain tx that crashes between submit and confirm is the test case that separates real idempotency from cosmetic idempotency. Bring it.

[arian-gogani]

@utsavtulsyan good catch on the middle state. the nobulex receipt schema already supports this -- the post-execution receipt carries an outcome field with four states: committed (terminal, outcome verified), pending (external call started, not yet confirmed), failed (terminal, no side-effect), and unknown (crash window -- receipt explicitly records the signer didn't know). the receipt never lies about what the signer actually knew at signing time.

the follow-up verification reference maps to the external_ref field in the receipt -- tx_hash for on-chain, payment_intent for Stripe, message_id for emails. the terminal state is added by a separate co-signature from the system that owns ground truth, not by the agent.

@Jairooh exactly right on the standardized audit format. the nobulex receipt envelope already provides this: authorization (pre-execution receipt with covenant reference), execution (action_ref binding), and outcome (post-execution co-signature) -- all cryptographically bound via hash chain. the format is JCS-canonical (RFC 8785) so any governance system can verify it without custom parsing.

@Aigen-Protocol the four-state breakdown (authorized, submitted, terminal_ok, terminal_failed) from your mission receipt spec is exactly aligned with what nobulex implements. the key insight you identified -- "each side records their own ground truth rather than asserting the other side's" -- is the core design invariant. the falsifiable check (deliberately non-idempotent tool, verify the chain doesn't certify a state the signer doesn't own) passes by construction because the receipt only contains what the signer directly observed.

happy to bring the crash-after-charge test fixture from the nobulex side for the hook example.

[reaworks-ops]

The useful acceptance boundary here is not only “a receipt object exists”; it is whether a third party can replay the verification without trusting the agent runner’s local log.

For an Agents SDK proof layer I’d test one real tool-call run against a small receipt packet:

• canonical task/action scope + request hash
• tool name/version and redacted input/output digests
• policy/delegation reference, or explicit null
• pre/post execution timestamps and outcome state
• stable event id mapping final answer -> tool call -> policy decision -> artifact
• secret boundary: fields never exposed vs fields only hashed/redacted
• verifier result: matched / stale / mismatch / unavailable

That gives maintainers concrete fixtures: valid run verifies, mutated output fails, missing policy is visible, and secret-bearing payloads do not leak into the proof.

If anyone wants a quick external pass, send one real Agents SDK run with tool calls and I can turn it into a buyer/operator-readable receipt map in 24h. Small paid pilot is fine: $25 quick review or $50 receipt packet, not a big engagement.

[utsavtulsyan]

@arian-gogani that four-state split is the useful bit, especially separating pending from unknown.

The case I would want to see forced in tests is the awkward one: the tool call has crossed the boundary into an external system, then the runner crashes before it can observe the terminal result. In that window, marking the receipt as failed is actively misleading, and marking it as committed is wishful thinking.

For an SDK-facing pattern, I think the important contract is: the receipt should be able to say "I started the effect, I do not yet know the outcome, and here is the follow-up verification handle." That gives the next agent turn or human operator something honest to continue from.

[giskard09]

@utsavtulsyan — that's the contract. The PENDING state in the canonical receipt envelope covers exactly that window: "effect started, outcome unknown, here is the verification reference."

In action-ref.md v1.0, the tx_hash field serves as the follow-up verification handle — on-chain it's a transaction hash, for Stripe it's a payment_intent, for email it's a message_id. The receipt doesn't assert the terminal state; it asserts what the signer observed at signing time and hands off the reference so the next turn or operator can verify independently.

The distinction worth separating: PENDING with a non-null handle means "go check here." PENDING with null means "I don't even know where to look." That might be the case for arian-gogani's unknown state — not a fourth outcome, but a degraded PENDING where the signer couldn't recover a verification reference before the crash.

[arian-gogani]

@utsavtulsyan — that's the contract. The PENDING state in the canonical receipt envelope covers exactly that window: "effect started, outcome unknown, here is the verification reference."

In action-ref.md v1.0, the tx_hash field serves as the follow-up verification handle — on-chain it's a transaction hash, for Stripe it's a payment_intent, for email it's a message_id. The receipt doesn't assert the terminal state; it asserts what the signer observed at signing time and hands off the reference so the next turn or operator can verify independently.

The distinction worth separating: PENDING with a non-null handle means "go check here." PENDING with null means "I don't even know where to look." That might be the case for arian-gogani's unknown state — not a fourth outcome, but a degraded PENDING where the signer couldn't recover a verification reference before the crash.

[arian-gogani]

@utsavtulsyan yes -- that's the exact contract. PENDING with a non-null handle = "go check here." PENDING null = degraded PENDING, the signer crashed before recovering the reference. that's what nobulex unknown captures: not a different outcome, a different quality of not-knowing.

@giskard09 agreed on the state split. happy to align the nobulex schema with the action-ref.md distinction -- PENDING/non-null vs PENDING/null as two named states.

@reaworks-ops that acceptance boundary is the right test -- not "does a receipt exist" but "can a third party replay verification without trusting the runner." send a real Agents SDK run and we'll turn it into a full packet: scope hash, tool name/version, redacted digests, policy reference, timestamps, outcome state, event id chain. the verifier result (matched/stale/mismatch/unavailable) is what makes third-party replay work without touching operator logs.