Signed evidence for agent-led actions: what an audit record needs

Logs help operators debug a system. They are often distributed across services, mutable through retention pipelines, and difficult to hand to another party. Authorization evidence needs a stable schema and a clear chain from what the user approved to what the platform proposed and how the authorization ended.

The goal is not to record every internal detail. It is to preserve the minimum material facts needed to reproduce the decision, detect later modification, and connect external execution to the approved authority.

A useful evidence object starts with the mandate and appends events rather than rewriting history. Each event should carry a stable identity, organization scope, timestamp, event type, and the relevant normalized payload or digest.

Signing evidence is useful only if another system can verify the exact bytes and resolve the correct public key. The format needs deterministic serialization or an explicitly protected payload, a versioned schema identifier, a key identifier, an allowed algorithm, and published verification keys.

Key rotation must preserve historical verification. Removing an old public key when the signer rotates can make retained evidence unverifiable. Compromise response also needs a documented way to distinguish keys and validity periods without pretending that a signature proves the underlying business event occurred.

A valid signature proves that the holder of the corresponding private key protected the evidence payload and that the payload has not changed undetected. It does not prove that every upstream assertion was true, that the downstream action succeeded, or that a transaction complied with every applicable rule.

Source-label external assertions and keep the authorization service's own observations distinct. For example, an external booking reference can be recorded as customer-supplied data while the authorization decision and lifecycle transition are service-produced facts.

Evidence should omit card data, bank credentials, provider secrets, free-form personal data, and any fields that are not required for authorization. Prefer platform-scoped subject references and typed action attributes over names or raw conversation transcripts.

Define retention in the customer agreement and threat model. The right period depends on support, dispute, security, and legal needs. Whatever the period, test that evidence remains independently verifiable after application changes, key rotation, and archival.