Browser-based AI agents log as users, *breaking enterprise audit trails*

The problem with borrowed credentials

When you hand your car keys to a valet, you trust them to park it. But if they speed through a red light on the way, the camera flash is aimed at your number plate, not theirs. Browser-based AI agents work the same way. They borrow a user's credentials, open a session that looks like the user's and act on their behalf. Every click, every edit and every approval goes into the log under the user's name.

For years, organisations have relied on logs to answer basic questions: who approved a payment, who accessed a file and who changed a record. When an AI agent does it, the log says the user did it, and nobody looking at the log later can tell the difference.

It gets worse when something goes wrong. Say a regulator asks which decisions were made by people and which by AI. Say a lawyer in an e-discovery process wants to know who acted on a client's instruction. Say an auditor needs to reconstruct an incident. If the logs don't separate human actions from agent actions, those questions become unanswerable without interrogating every user individually.

Why compliance teams care

Compliance and audit work starts with logs. They are the record of what happened, who did it and when. Legal holds, regulatory audits, incident investigations and internal reviews all depend on being able to trace an action back to the person or system responsible for it.

When agents log as users, that chain breaks. A payment approval that looks like it came from the finance director might have been made by an agent following a rule the director never saw. An access event that looks like it came from an employee might have been an agent fetching data for a query. The log itself is not tampered with—it is simply wrong from the start.

That matters under rules like DORA, which asks financial firms to log ICT events and protect those logs against tampering, deletion and unauthorised access ^[1]. But if the log says the wrong actor performed an action, protecting it does not help. The same problem shows up under the AI Act, which requires high-risk systems to log events for traceability ^[2]. If an agent's actions are logged under a user's name, the traceability fails.

What the rules say

The AI Act's Article 12 asks high-risk AI systems to allow for the automatic recording of events over their lifetime, for traceability and post-market monitoring ^[2]. It says what to log. It does not say how to attribute the action, but if the actor is wrong, the log is not much use.

Articles 19 and 26 add that providers and deployers must keep the logs they have control over for at least six months, unless another law requires longer ^[3]. That matters here because an organisation running browser agents often has control over both the application logs and the agent's own logs, but if the two do not agree on who did what, neither one is reliable.

DORA's technical standard on ICT risk management is more direct: logs must be protected against tampering, deletion and unauthorised access ^[1]. It also asks for logging to detect failures in the logging itself. If an agent's actions are logged under a user's identity, and nobody notices, that is a logging failure the standard is trying to prevent.

In the United States, the SEC's rules on books and records require broker-dealers to preserve electronic communications in a way that allows them to be produced in a regulatory examination ^[4]. If an agent acts on a customer's instruction and the log says a human employee did it, that record does not meet the requirement.

How misattribution happens

Browser agents operate inside a user's session. The user logs in, the agent takes over and every action the agent performs flows through the user's authenticated session. From the application's point of view, the user is still the actor. The session token says so, the access logs say so and the audit trail says so.

Some agents leave breadcrumbs in HTTP headers or user-agent strings, but those are easy to overlook, not standardised and often stripped by proxies. Even when they are preserved, they do not change the fact that the application logged the user as the actor.

The result is a split record. The agent's own logs might show what it did and why, but the application logs show the user as the actor. Reconciling the two after the fact requires correlating timestamps, session IDs and actions across systems that were not designed to work together. In an investigation, that is time nobody has.

What this means for you

If your organisation runs browser-based AI agents, ask these questions now:

• Do your application logs distinguish between actions taken by a user and actions taken by an agent using the user's credentials?
• Can you reconstruct which decisions were made by people and which by AI, six months after the fact?
• If a regulator or a lawyer asks for records of human approvals, can you filter out agent actions without manual review?
• Do your e-discovery procedures account for agent actions logged under user identities?
• Have you tested whether your logging meets DORA's requirements when agents are involved?

If the answer to any of those is no, the problem is not theoretical. It will show up the day someone asks.

The witness question

A digital witness can show that a log entry existed at a given time and has not changed since it was sealed. Here, the thing to seal is each log entry as it is written, with the actor field intact. That proves the log said what it says now. It does not fix the problem if the log says the wrong thing.

What the witness cannot do is correct attribution. If an agent acts under a user's credentials and the application logs the user, sealing that log entry preserves the error. The log is provably unchanged, but it is still wrong.

The real fix is to log agents as agents. That means either giving agents their own credentials or recording a clear flag in the log entry that marks it as an agent action. Some systems support service accounts or API keys for this. Others do not, and for those, the organisation needs a way to correlate application logs with the agent's own logs.

If your system cannot log agents separately, the next best thing is a second log, written by the agent itself, that records what it did, when and on whose instruction. That log can be sealed as it is written, using WitniumChain through the REST API, the SDK or the MCP server, so that nobody can later claim it was written to match a story. The first 2,000 witnesses a month are free. Read the docs.

Anyone you share the log with can check that it matches the sealed fingerprint, which shows it has not been edited since it was written. The application logs still say the user did it, but at least you have a second record that says the agent did it, and both records are checkable.

What to watch

High-risk AI systems under Annex III must meet the logging requirement from 2 December 2027, and systems under Annex I from 2 August 2028 ^[2]. DORA's logging requirements for financial firms have applied since 17 January 2025 ^[1].

The European Commission's AI Office has not yet published detailed guidance on how to attribute agent actions in logs, but the principle is clear: logs must support traceability. If an agent's actions are logged under a user's identity, traceability fails.

In the meantime, the safest approach is to log agents as agents, and to seal those logs as they are written, so that the record cannot be quietly rewritten when someone asks a hard question.