Ahead · 2026-10-10 · 5 min read
AI agents need receipts: who asked them to act, and what did they do
As AI agents start to book, buy and send on someone's behalf, organisations need a record of what the agent did and on whose instruction.
What changes when AI acts
An AI that answers questions is one thing. An AI that books a flight, changes an order, sends an email or transfers money is another. When an agent acts instead of advising, someone has to know what it did, when and on whose instruction.
The record matters for three reasons. First, mistakes happen, and someone has to put them right. Second, if a customer says they never asked the agent to cancel their subscription, the organisation needs to show what happened. Third, as agents become more capable, the question of who authorised what will matter in law as well as in practice.
The difficulty is that an agent's actions often leave little trace. A tool call might update a database, send a message or make an API request, and if the only record is the agent's own log, questions come later about whether that log is complete and unchanged.
What a useful agent record contains
A complete record has four parts. The first is the instruction: what the user asked the agent to do, in their own words. The second is the tool call: which function the agent invoked, with which parameters. The third is the result: what the tool returned. The fourth is the time.
Together, those parts answer the questions that tend to come up when something goes wrong. Did the user ask for this? What exactly did the agent do? What was the outcome? When did it happen?
Some agents already keep such records. The Model Context Protocol, for example, logs every tool call [1]. The question is whether that log can be relied on weeks or months later, when someone challenges what the agent did.
Where the AI Act's logging duties may apply
Article 12 of the AI Act says high-risk AI systems must technically allow for the automatic recording of events over their lifetime [2]. That duty applies to systems listed in Annex III from 2 December 2027, and to systems listed in Annex I from 2 August 2028 [3].
Not every AI agent is high-risk. An agent that helps someone draft an email or search a knowledge base doesn't fall under the high-risk categories. An agent used to assess job applicants, grant credit or decide insurance claims might, depending on how it's used.
Article 12 says what to log. It doesn't say the logs must be tamper-proof, immutable or independently verifiable. Those are good practices, not legal requirements under that article.
Article 26 sets out duties for those who use high-risk AI. Among other things, users must monitor the system's operation and, where the AI is used to make decisions about people, inform those people [4]. An agent that acts on behalf of a user doesn't remove the user's duty to oversee what it does.
How tools such as MCP make agent actions visible
The Model Context Protocol is one way to make an agent's actions visible. MCP defines how an agent asks for tools and how a server provides them. Every call goes through the protocol, so it can be logged [1].
Other approaches exist. Some agent frameworks write each action to a structured log. Others send events to an audit stream. The method matters less than the outcome: a record that can be checked later.
The record itself can be kept anywhere the organisation chooses. A database, a file, a dedicated audit service. What matters is that the record exists, covers the actions that matter and can be shown to be unchanged when it's needed.
Making the record provable
Here, the thing to seal is each action as it happens: the instruction, the tool call, the result and the time. Sealing takes a fingerprint of that record, not the data itself, so the record never leaves the organisation's systems. Anyone the organisation shares the record with can later check that it's exactly what was written at the time.
Say an agent changes a customer's delivery address. The customer later says nobody asked it to. With a sealed record, the organisation can show the instruction the customer gave, the tool the agent called and the result it got back, and the customer or an ombudsman can check that the record hasn't changed since it was sealed.
A digital witness shows that the record existed at a certain time and hasn't been altered. It doesn't authorise the action, doesn't make it correct and doesn't settle whether the organisation is liable for what the agent did. It answers one question: is this the record that was written on the day?
The witness is created through WitniumChain, using the REST API, the SDK or the MCP server. The content stays with the organisation. To check, anyone calculates the fingerprint again and compares it with the sealed one. The first 2,000 witnesses a month are free. Technical details are in the documentation.
How it would work
- The agent acts: it calls a tool, gets a result and writes a record.
- The system seals the record: it sends a fingerprint to WitniumChain and gets a witness ID back.
- Later, anyone with the record can check it: calculate the fingerprint and compare it with the sealed one.
What this means for you
Before giving an agent the ability to act, ask these questions.
What will it be allowed to do? Be specific. Sending emails, changing orders and transferring money are different levels of risk.
What will you log? At minimum, the instruction, the tool call and the result. Without that, you're trusting the agent to explain itself later.
Who can check the log? If only the team that runs the agent can read it, it's less convincing when something is disputed.
What happens if the agent acts wrongly? Does it notify someone, reverse the action or wait for a human to notice? The answer shapes the rest.
Is this a high-risk AI system under the AI Act? If it is, Article 12's logging duty applies from the dates above. If it isn't, logging is still a good idea, for a simpler reason: one day someone will ask what the agent did.
What to watch
From 2 December 2027, high-risk AI systems under Annex III must allow for automatic logging under Article 12 of the AI Act. From 2 August 2028, the same applies to systems under Annex I. Whether a given agent falls under those annexes depends on what it does and how it's used.
The AI Act doesn't require the logs to be sealed. It requires them to exist and to be kept. Sealing them is a way to show later that they haven't changed, which matters when someone challenges what the agent did.
Sources
- [1]Model Context Protocol specification, Anthropic, 2024
- [2]Article 12 of Regulation (EU) 2024/1689 (AI Act), European Commission AI Act Service Desk, 2024
- [3]Timeline for implementation of the EU AI Act, European Commission AI Act Service Desk, 2024
- [4]Article 26 of Regulation (EU) 2024/1689 (AI Act), EUR-Lex, 2024