Records of permission use must be auditable

What it is

After a ticket is issued, it must still be possible to answer: which task, which object, which verb, who approved, what the result was. Auditable permission use is not an ops debug log. It is a record that can walk the causal chain of a permission, after the fact, object by object. Miss a link and you cannot replay a cross, whether it was blocked or not.

“It is probably in the system log” is not auditable. The standard is that a person who does not write code can find that row by object.

Why it happens

A permission’s life crosses three beats: grant, call, result. Products often pop a window only at grant, keep no object-level record at call, and scatter results across external systems. At replay people see “an account was connected on that date,” not “at 15:03 a read ticket was used to write another folder.” Without that chain, least privilege and intercept cannot be verified, and duty has nowhere to land.

Audit is for people to read: the fields are task, object, verb, ticket, approver, result, time. A debug stack is not for people to read. Retention follows when accountability might arise, not whether disk is cheap — that is a neighbouring traceability question; here the demand is that the fields exist.

Studying it

Run one grant, one in-scope call, one out-of-scope attempt (blocked or not). Ask someone unfamiliar with the system to answer from the audit UI alone: who approved, what was touched, was there a cross. Dependent variables: accuracy, time to find a row, whether an engineer is needed. Independent variables: whether records are object-level, whether they include the approver, whether the UI is searchable by object.

Being able to answer is what makes it auditable. An engineer grepping it out does not count.

Where it stops holding

A local-draft agent that cannot cross a world boundary has a weaker audit need, but a grant record is still worth keeping in case scope later grows. If intercept itself produces no human-readable ledger, audit is empty — blocks must be booked too. Accountability tracing also wants input and decision basis, wider than the permission ledger; this entry covers only the permission stretch.

Applying it

• Every use of every ticket writes an object-level row: task, object, verb, approver, result (done / rejected / failed). Offer search by object and by task; do not leave this layer only in infrastructure logs.
• Grant and call must join. Grant without call, or call that cannot be joined to a ticket, is a broken chain.
• Check: take the engineers away, give operations an object name, ask “what was this ticket used to do.” If they cannot find it, or must rummage servers, audit does not exist. Then force a rejected cross and see whether the ledger has “rejected” — if not, even a real intercept cannot be proved.

Related

• Same group: L4.06.1 Permissions must be granted by task scope, not all at once · L4.06.2 Out-of-bound acts must be blocked, not reported after the fact
• Nearby: L4.15 Accountability and Traceability · L4.07 Pre-action Confirmation · L4.13 Agent Failure Reporting and Escalation
• Search terms: audit trail · permission logging · agent accountability