Enterprise-Grade Security & Governance

30 — Non-Repudiation Logs

Create attributable, tamper-evident records of agent decisions and actions while recognizing that evidence strength depends on identity, keys, and independent custody.

Concept overview

Non-repudiation logging aims to provide strong evidence of who requested, authorized, and executed an action. Ordinary application logs help debugging but can be modified by the same administrator who operates the application. Stronger evidence combines authenticated identities, canonical event records, integrity protection, reliable timestamps, and controlled retention.

Hash chaining alone is insufficient if an attacker can rewrite the chain and its anchor. Sign records or batches with protected keys and anchor integrity evidence outside the writer's control. These mechanisms support accountability; whether evidence establishes legal non-repudiation depends on the wider process and jurisdiction.

Why it matters in production

Proof of concept

A prototype should record operation identities and actual tool outcomes. Avoid confusing a model's stated intention with an executed business action.

Production

Production separates audit events from debug logs, protects signing keys, and records policy and approval versions. Audit failure behavior should match the consequence of the protected action.

Enterprise scale

At scale, use durable ingestion, independent retention, key rotation, and verification jobs. Minimize sensitive payloads while retaining enough references to reconstruct decisions under authorized investigation.

Architecture components

Audit event producer

Emits canonical records for requests, approvals, policy decisions, and actual effects.

Identity binding

Connects human, workload, and delegated identities to each event.

Integrity service

Signs records or batches and links them to externally retained integrity anchors.

Protected archive

Stores audit evidence under restricted administration and defined retention rules.

Verification process

Checks signatures, ordering, missing events, and key-validity history.

The architecture, mapped

Attributable action evidence with independent custody — Independent anchors and protected keys make retrospective tampering more detectable than ordinary writable logs.

flowchart LR
 A["Authorized tool action"] --> E["Canonical audit event"]
 I["Actor and approval identity"] --> E
 E --> S["Protected signing service"]
 S --> W["Restricted audit archive"]
 S --> X["Independent integrity anchor"]
 W --> V["Verification job"]
 X --> V
 V --> R["Evidence review"]

Runtime flow

1
Identify action
Assign a stable operation identifier before the consequential request is executed.
2
Capture authority
Record authenticated actors, approval evidence, policy version, and exact action parameters or protected hashes.
3
Record outcome
Capture the authoritative result, including uncertain or rejected outcomes.
4
Protect integrity
Canonicalize events, sign them with protected keys, and publish independent anchors.
5
Retain evidence
Store records and referenced artifacts under appropriate access and retention controls.
6
Verify continuously
Check integrity and sequence gaps, then investigate anomalies with documented custody.

Recording agent-assisted settlement instructions

Financial services · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

An operations team uses an assistant to prepare settlement instructions that authorized staff review before release.

The problem

Debug logs show conversations but do not reliably connect the final instruction to its approver and actual downstream acceptance.

Agent requirement

The assistant must produce an attributable record of proposal, approval, execution, and reconciliation.

Architecture

Canonical audit events bind each operation to user and workload identities, with signed batches retained in a separately controlled archive.

Runtime

A reviewer approves a versioned instruction; the execution gateway records the approved parameter hash and the receiving system's identifier.
A verification process checks batch signatures and missing sequence entries independently of the agent runtime.

Failure scenario

If the audit service cannot durably accept evidence for a protected action, the gateway follows the defined hold policy rather than silently dropping records.

Operational impact

Measure evidence completeness, verification failures, ingestion delay, and time to reconstruct an operation. Cryptographic integrity does not establish that the original business decision was correct.

Architecture tradeoffs

Decision	Benefit	Cost
Signed audit records	Later modification becomes detectable under the key trust model.	Key custody and rotation require operational discipline.
Independent retention	Application administrators have less ability to alter evidence.	Cross-system availability and retention costs increase.
Minimal payloads	Sensitive data exposure is reduced.	Investigations may need separately retained referenced artifacts.

Failure scenarios & recovery

A signing key is compromised

Detect: Key monitoring or verification investigation identifies suspect usage.

Recover: Revoke the key, preserve affected evidence, and establish the trusted time boundary.

Events disappear before archival

Detect: Sequence checks show gaps between action records and retained batches.

Recover: Reconcile from operation ledgers and investigate ingestion loss.

Common architecture mistakes

Calling a mutable database table immutable

Enforce separate custody and test administrative tampering.

Logging only model intentions

Record actual authorization and downstream outcomes.

Assuming hashes establish actor identity

Bind events to authenticated principals and protected signing keys.

When to choose this pattern

Choose it when

Consequential actions require attributable evidence.
Investigators must reconstruct approvals and execution outcomes.
Independent integrity verification is operationally supported.

Avoid it when

Ordinary debugging telemetry is the only requirement.
No trustworthy identity or key custody exists.
The design promises legal conclusions from hashes alone.

Architecture checklist

Define canonical audit event schemas.
Bind user, workload, and approval identities.
Record actual operation outcomes.
Protect and rotate signing keys.
Retain independent integrity anchors.
Test gap detection and evidence reconstruction.