What to Log When an Agent Reads Something It Should Not Have

An AI agent pulled a record it should not have touched. Maybe a salary line, a medical note, a customer file from a team it does not serve. The first question anyone asks is simple and it is usually the one you cannot answer: who saw what, and when?

If an agent reads something it should not have, the minimum you need on record is the identity of the agent, the human it was acting for, the exact records touched, the timestamp, the permission that allowed it, and where the content went afterwards. Anything less and you are guessing during the week when guessing costs the most.

Why the log matters more than the mistake

Access mistakes are treated as notifiable events under several data protection regimes. Rules differ by country and by sector, so check the ones that apply to you rather than assuming. What is broadly consistent is that regulators care less about the fact of the error and more about whether you can describe it accurately and quickly. Firms holding client work carry a second layer on top of that, because an agent touching client files runs into confidentiality duties as well as data protection ones.

A vague answer looks like a bigger problem than it is. "An agent may have accessed some HR records around the end of March" reads as a serious lapse. "At 14:12 on 27 March, agent instance 4 acting for a named manager read three leave records for two employees, none of which left the system" reads as a contained incident with a clear boundary.

The difference between those two sentences is logging you set up months earlier.

The six fields worth arguing about

Most systems log something. Few log the things that matter when someone is asking hard questions. These are the fields to insist on.

• Which agent instance. Not the product name. The specific run, with an identifier you can trace back to a task.
• Which human. An agent acts on someone's behalf. The person who triggered the run, or the standing rule that did, belongs in the same line.
• Which records. Record identifiers, not a category. "Read employee data" is useless. "Read records 1182, 1183" is answerable.
• When, to the second. Duration too, if the read was a bulk operation.
• Which permission allowed it. The role, group or scope that let the read succeed. This is the field that tells you whether the mistake was a bug or a bad grant.
• Where the content went. Was it summarised into a draft, quoted in a message, stored in a task, or discarded unused? This is the field almost nobody logs, and the one that determines how far the exposure spread.

Where it went is the hard part

The read itself is contained. What follows usually is not.

An agent that read a leave record and then wrote a project update mentioning why someone is away has moved sensitive content into a place with a different audience, which is the same chain of events as an agent reading a personnel file and then summarising it. The read log tells you the record was touched. Only an output trail tells you the content is now sitting in a board comment that forty people can see.

This is an argument for keeping agent work on the same set of records as the rest of the business rather than in a separate tool that talks to everything by API. SicherOne puts project management, HR and AI agents on one set of records, which means the trail from a read to an output stays inside one system instead of being reconstructed from three. It also means a human approves the output before it ships, so there is a checkpoint between a bad read and a published consequence.

Keep the log where the agent cannot reach it

An audit record that the agent can edit is not an audit record. Write access to the log should sit outside anything the agent can act on, and outside the reach of the person who configured the agent. Where those records are allowed to sit at all is one of the things that shifts when you weigh self hosted models against vendor hosted ones.

The same applies to retention. Set a retention period for access logs that is longer than the window in which a complaint might arrive, and decide it before you need it. If your log rolls over every thirty days, an issue raised in month three is unanswerable.

Have the alert fire on the pattern, not the record

Alerting on every access to sensitive data produces noise that everyone learns to dismiss. Alert on patterns instead: an agent reading a record type it has never read before, an agent reading records outside the team it usually serves, a volume spike against its own baseline.

Those three catch most genuine problems and stay quiet the rest of the time, which is the only way an alert survives contact with a busy team.

What to do in the first hour

When it happens, work in this order. Freeze the agent's access rather than deleting the run, because the run is evidence. Pull the six fields above into one short written summary. Trace the outputs and remove or restrict any that carry the content. Then decide, with whoever handles your legal and compliance work, whether the incident meets a notification threshold in your jurisdiction.

The order matters. Teams that start with the notification question first often spend a day arguing about severity before anyone has established the facts. Establish the facts first. The rest is easier when the answer to "who saw what, and when" already fits in a paragraph.