Signed Action Receipts: Tamper-Evident Audit for Agent Actions

When agents execute actions with real-world consequences, the hardest operational problems are not model quality. They are disputes, investigations, and proving what happened.

Teams discover quickly that "we have logs" is not the same as "we can prove it."

The pain: logs are not a trust artifact

Traditional logs fail under agent workloads because they are:

1) Fragmented across systems

A single agent action often spans:

• the agent runtime
• an orchestrator
• multiple tool APIs
• vendor platforms (telephony, payments, SaaS)
• downstream partners

Each system has its own:

• identifiers
• timestamps
• retention policies
• sampling behavior
• redaction and privacy rules

Reconstructing a single narrative becomes a forensic exercise.

2) Ambiguous in attribution

If the same API key or service account is reused:

• logs identify the integration, not the executor
• multiple agents look identical
• "on behalf of" context is lost
• it is unclear which human principal is responsible

In disputes, this is fatal. You cannot confidently answer who authorized or initiated the action.

3) Weak under replay and duplication

Agents frequently rely on retries. Distributed systems rely on at-least-once delivery. Together, they produce:

• duplicate tool calls
• non-idempotent actions executed twice
• partial failures where the rail executed but the agent thinks it failed
• inconsistent state across systems

Logs can show events, but they often cannot establish:

• whether an action was the first attempt or a replay
• whether the action was intentionally repeated
• which attempt actually produced the side effect

4) Not integrity-preserving

In many organizations, logs are:

• mutable by administrators
• rewritten during incident response
• truncated by retention
• filtered by cost constraints

Even if nobody is malicious, the integrity of logs is disputable, especially across organizational boundaries.

The external pressure: partners and regulators

As agents expand into commerce, finance, and communication channels, audit pressure increases:

• partners demand evidence in a standardized form
• compliance teams need consistent records
• dispute resolution requires "who, what, when, under what authority"

Logs are not designed for third-party verification. They are designed for internal debugging.

The operational reality: incident response becomes guesswork

When something goes wrong, teams need to answer quickly:

• What action occurred, exactly?
• Under what authority was it executed?
• What context was present?
• Was there a user involved, or was it autonomous?
• Was this consistent with expected behavior, or anomalous?

Without a compact, consistent, integrity-preserving record, incident response degrades into:

• manually correlating traces and timestamps
• arguing about which source of truth is correct
• accepting uncertainty because evidence cannot be trusted

Conclusion

The pain is not that logs do not exist. The pain is that logs do not function as proof:

• they are fragmented
• they are ambiguous in attribution
• they are weak under replay and retries
• their integrity is disputable
• they are not easily verifiable by third parties

As agents move into higher-stakes actions, auditability stops being an internal engineering concern. It becomes a prerequisite for participation in the ecosystem.