Auditability by design

Lens adapted to this topic: How design-first auditability supports accountability

The design-first view treats auditability as a foundational system property rather than a reporting add-on. It emphasizes capturing relevant events and decision context throughout the lifecycle, making records queryable and resistant to alteration, and aligning evidence with compliance and accountability needs. For AI agents, this means covering actions, data access, policy checks, responsibility, and evidence integrity. The approach does not necessarily require one separate audit log; auditability can be built into the system’s state and event model.

• Auditability is best treated as a design problem or architectural primitive, because retrofitting evidence collection after deployment can leave gaps and require changes across system components.
• Compliance-oriented audit evidence generally needs to show what happened in sequence, reconstruct relevant past states, and demonstrate that records were not altered after the fact.
• Auditable agents require more than output logging: useful evidence can include retrieved data, considered and executed tools, parameters, tool results, interpretations, and subsequent decisions.
• Agent auditability can be organized around action recoverability, lifecycle coverage, policy checkability, responsibility attribution, and evidence integrity.
• No single mechanism is sufficient for all audit needs; detection, enforcement, and recovery mechanisms address different temporal and intervention constraints.

Lens adapted to this topic: What audit records can and cannot establish

The critical view accepts the value of accountability records but argues that “auditable by design” can overstate what technical controls prove. A record may accurately preserve its own contents without proving that the original event set was complete, that an action was authorized, or that a stated reason caused the decision. Hashing, replay, signatures, external anchoring, and unwritable sinks can strengthen particular guarantees, but they do not turn testimony or a self-selected record into direct evidence of causation or completeness.

• A retrospective audit can document who acted, what they did, and what reasons they later gave, but it cannot by itself establish whether those stated reasons actually caused the decision.
• Integrity, completeness, and authorization are distinct claims: a hash, cursor, or replay mechanism may support one property without proving the others.
• Hash chaining shows consistency between records, but a party controlling the log may be able to rewrite records and recompute subsequent hashes unless the record is anchored independently.
• A conventional server-held audit trail may be vulnerable to administrator changes, compromised timestamps, deletion, or reconstruction from scratch; proposed mitigations include external anchoring and signatures.
• For agent systems, the audit artifact should be written or committed somewhere the agent cannot rewrite, ideally including intent or plans fixed before execution rather than authored afterward.