Logs are not evidence

Picture a Tuesday afternoon at a mid-sized bank. An AI agent that helps the FX desk books a EUR/USD trade for 2.5 million. It had the access it needed, the call went through, and nothing broke. Nobody thinks about it again.

Three months later, an examiner asks one question about that trade. Who allowed it?

The team opens the logs, and the logs are honest about what they know:

2026-07-14T14:02:17Z svc-fx-agent POST /tools/fx.trade
  pair=EUR/USD notional=2500000 status=200 latency=184ms

That’s it. That’s everything the log knows.

It doesn’t say which person the agent was working for. svc-fx-agent acts for the whole desk. It doesn’t say whether anyone approved the trade. Maybe a desk head typed “ok, go ahead” in a chat thread that afternoon, but nothing ties that message to this call rather than the one before it. And there’s a harder question the examiner may not say out loud: how do you know the log shows what really happened?

A log is a diary, not a witness

Logs were built for engineers. They exist so someone can find out why a service crashed at 3 a.m. The system that did the work writes them, they live where the same team can reach them, and they last as long as nobody deletes them. For debugging, that’s perfect. For proving something to an outsider, it’s a weak place to stand.

Think about who can change a log. Anyone with admin access to the log store or the database can. Some teams chain their log lines with hashes, which helps, but an admin who rewrites one line can recompute every hash after it. The chain still looks flawless. A vendor’s audit dashboard doesn’t solve this either. It moves the trust from your admins to the vendor’s.

None of this assumes anyone is dishonest. Almost nobody edits logs. The trouble is that you can’t show they didn’t, and that’s the bar evidence has to clear. Evidence is what’s left standing after someone asks, “How do you know?”

The agent is not the person

Every agent action involves three parties, and a typical log sees only one of them.

• The agentThe software that made the call. In our story, agent:pricer-7.
• The person it acted forAlice, the trader whose request the agent was carrying out.
• The person who allowed itBob, the desk head who said yes.

A service account squashes all three into svc-fx-agent. That matters because responsibility belongs to people. “The agent did it” is no more an answer for a regulator than “the spreadsheet did it.” An agent has no authority of its own. It borrows authority from a person, and the record has to show whose.

Keeping the three apart also prevents a quiet failure: the person who asked for an action approving it themselves. If the record knows Alice asked and Bob approved, a rule can insist they’re different people. If both show up as svc-fx-agent, nobody can tell.

Agents widen the gap

With people, we built workarounds over decades. A trader logs in under their own name. Payment systems enforce a second pair of eyes. A sign-off happens inside the system that runs the action, so the “yes” and the action sit side by side.

Agents quietly undo those habits. One service identity acts for many people. Approvals drift into chat and email. The agent acts in seconds, so human review tends to happen afterwards, if it happens at all. Meanwhile, rules like the EU AI Act, with its articles on record-keeping and human oversight, and DORA, with its logging and incident evidence, assume you can reconstruct who did what and who was in charge. A log line from svc-fx-agent can’t do that.

What evidence needs

If a log is a diary, evidence is closer to a notarized record. In practice, that comes down to five properties:

• It's written before the action.If the record can't be written, the action doesn't happen. No record, no trade.
• It names the person behind the agent.Not just the service account, but the human the agent was acting for.
• The approval is part of the record.A named person signed for this exact call, with these arguments, rather than a thumbs-up for "something like it."
• It's sealed where the database can't reach.Signed with a key the database doesn't hold, stored where it can't be overwritten. Rewritten history stops matching, even if every hash is recomputed.
• An outsider can check it without asking you.An auditor runs a tool on their own laptop and gets a yes or a no.

Ask your setup three questions

You don’t need our product to apply this. Whatever you run today, ask it:

• Can it tell me which person an agent acted for on a given call?
• Can it show who approved that call, and prove the approval belongs to that call and not another?
• If an admin rewrote last month, would anyone notice?

If any answer is “we’d have to trust the logs,” then you have logs. You don’t have evidence yet.

Back to Tuesday

This is the problem we built Pyloros to solve. Every agent call passes through it. Calls that need a person wait for one. The record is written first and sealed by a signed checkpoint, every 30 seconds by default, in write-once storage. Our verifier, pyloros-verify, runs offline and fails loudly if anything changed, and it tells you where.

With a record like that, the answer to the examiner fits in a few lines:

agent

agent:pricer-7

acting for

user:alice

call

fx.trade · EUR/USD · 2,500,000

policy

v41 · notional ≥ 1,000,000 needs a desk head

approved by

user:bob · fx-desk-heads · 14:01:52Z

sealed

checkpoint #25

verify

OK · exit 0

And the examiner doesn’t have to take your word for it.