Step 1 of 4
Define the audit record and scope
Decide what is auditable and what each record must answer.
Design the audit record. SCOPE: audit consequential actions - state mutations (writes, deletes), external effects (network calls, sends, spends), permission decisions, and security-relevant events (blocks, escalations); read-only trivia need not be audited (avoid drowning the trail). RECORD FIELDS: timestamp, actor (agent id + session), action (tool + operation), arguments (scrubbed, but specific - which file, which record), AUTHORITY (what permitted it: auto-allow tier, session grant, user approval with reference, or policy), triggering context (task id, the user request that led here, provenance/trust of any content involved), and OUTCOME (success/failure, effect summary). Define which fields are mandatory. The test: could an investigator answer who/what/when/why/outcome from one record plus its links?
Expected after this step
An audit record schema that captures authority and causation, not just action.
Should not happen
- ✕Logs that show the action but not who/why/what-authorized-it
- ✕Mutable logs an attacker (or the agent) could alter to hide actions
- ✕Audit records so verbose or so sparse they cannot answer real questions
- ✕No linkage between the action and the request/approval that caused it
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Logs that show the action but not who/why/what-authorized-it
- !Mutable logs an attacker (or the agent) could alter to hide actions
- !Audit records so verbose or so sparse they cannot answer real questions
- !No linkage between the action and the request/approval that caused it
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
Records show what happened but not why it was allowed. Add the authority and triggering-request fields - an audit trail that cannot explain why an action was permitted is useless in an incident.