Who wrote the record

Someone disputes an action on their account. The audit log has their name next to it.

I want to know how that name got there.

One way attribution can go wrong: a failed identity lookup falls back to a default user. The investigator receives that default as the recorded actor.

Even with separate columns for who acted and whose account they acted on, something still has to supply those identities.

The application chooses which identity goes into the audit row. Chooses is generous. Sometimes it just writes whatever the request context has lying around.

If the application can change the identity before writing the event, a mistake in that code can reach the audit log too.

Krisztian Robert Horvath brought up Linux audit logs in the comments under the LinkedIn version of the previous post. In a Linux session where loginuid is set at entry, child processes inherit that audit identity. Changing the effective user does not automatically change it. The application starts with an already assigned identity.

An unset loginuid can be written without privilege, changing one that is already set requires CAP_AUDIT_CONTROL, and only immutability closes the ability to reassign it. Assignment and permission to replace it are separate questions.

The question I follow up with in the code is who assigned the identity in the record, and whether the code performing the action could have chosen a different one.

A default user is a name the record had before anyone acted.

Krisztian Robert Horvath raised the Linux audit schema in the comments under the LinkedIn version of the previous post. The loginuid comparison came out of that exchange.