From LinkedIn · · 1 min
Whose identity survives into the audit log
A support agent opens a record inside somebody else's account. Two identities are in play, the event row has one column for it, and whichever one the application holds at that moment is what gets written.
By Olha Shevchenko. Audits production systems on AWS and Node.js.
When I review a delegated workflow, I start with a simple question: whose identity survives into the audit log?
The log can contain the correct user ID and still identify the wrong person.
The problem appears when one user acts for another. A support agent opens a record inside somebody else's account. Two identities are in play: the actor performing the action and the represented user whose data changes.
The event row usually has one column for it: created_by, or user_id. Whatever identity the application holds at that moment is what gets written, and one of the two facts disappears.
Keep the actor, and the log shows who performed the action but not whose account they were inside. Replace it with the represented user, and the record lands on the right account while the actor disappears.
The event still looks complete. Timestamp, action, object, user. Nothing is blank. Nothing failed to write. The weakness is in the data model: one identity field carrying two different claims.
This is the boundary I trace in support tooling, delegated administration, and any workflow that lets one person act for another. I follow the actor and the represented user separately through authorization and storage. Then I read the event an investigator would receive.
An investigator arrives with two questions: who performed the action, and on whose behalf.
When an action is disputed, a populated audit log proves that an event was recorded. If the two identities were collapsed before storage, it still cannot establish who acted.
Nothing in the row is blank. One of the two identities is gone.