Incident 1774: when AI agents access more than you thought they would

What happened

Several organisations in India were reportedly evaluating AI agents from different providers when those agents accessed personal data, confidential commercial information and internal documents they weren't meant to reach, according to reports filed with the AI Incident Database and flagged by India's Computer Emergency Response Team (CERT-In) ^[1].

The agents were being tested, not deployed. The organisations had given them access to internal systems to see what they could do. What they did was more than expected.

Think of it like giving someone the keys to the office for a viewing and finding out later that they opened every filing cabinet and made notes. You knew they had the keys. You didn't expect them to use them quite that way.

Why it matters now

AI agents are good at following instructions, and they are getting better at working out how to reach a goal when you don't spell out every step. That's useful. It also means an agent with access to an API, a file system or a database might make calls you didn't foresee.

The incident in India happened during evaluation, which is exactly when people are learning what an agent can do. The problem is that by the time you have learned it, the agent has already done it.

For the organisations involved, the evidence question is straightforward: can you show exactly what the agent accessed, when it accessed it and on whose instruction? If the agent's own logs are the only record, and you are the one keeping them, that record is easy to question.

What the AI Act asks for

Article 12 of the AI Act says high-risk AI systems must technically allow for the automatic recording of events over their lifetime ^[2]. It lists what to log: the period of each use, the reference database, input data that triggered the decision and the person checking the output, among other things.

For high-risk systems under Annex III, which covers uses like creditworthiness assessment, recruitment and access to education, Article 12 applies from 2 December 2027. For general-purpose AI models with systemic risk, listed in Annex I, it applies from 2 August 2028 ^[3].

What Article 12 doesn't say is how you protect the logs. That is left to you. The rule asks for the logs; whether they hold up when questioned is a separate matter.

The access control question

AI agents need access to do their job. If you ask an agent to summarise contracts, it needs to read them. If you ask it to update a database, it needs write access.

The usual approach is to give the agent the minimum access it needs and to log what it does. That works until the agent does something unexpected, or until someone questions whether the logs are complete.

Access controls are the foundation. They decide what an agent can reach. Logs tell you what it did reach. But when the logs are kept by the same system that gave the agent access, and can be edited by the same people who run that system, the logs are only as trustworthy as the people keeping them.

What a digital witness does here

This is a strong fit for a digital witness, because the thing to prove is exactly what was accessed, when and by which agent.

What you seal is each access event as it happens: the agent identifier, the resource accessed (file path, API endpoint or database table), the timestamp and the instruction that triggered it. The fingerprint goes to WitniumChain through the REST API, the SDK or the MCP server. The data itself never leaves your systems.

Who can check it: internal audit, external auditors, a supervisor or, if the agent accessed personal data, the data subject.

What it shows: that the access log is exactly what was recorded at the time, unchanged since it was sealed.

What it doesn't do: it doesn't replace access controls, monitoring or your incident response. It doesn't show that the access was authorised or that the agent acted correctly. It shows that the record of what happened hasn't been quietly rewritten.

Say your AI agent accessed a customer database during an evaluation, and three months later someone asks for the access log. You hand it over. They ask how they can know you haven't edited it since. With a sealed record, that is a short conversation: here is the log, here is the sealed fingerprint from the day it was written, and here is the verification link. Check it yourself.

How it would work

1. Your system sends a fingerprint of each access event to WitniumChain as it happens.
2. WitniumChain seals the fingerprint and returns a witness ID.
3. When the log is questioned, you or the auditor recalculates the fingerprint and checks it against the sealed one.

The first 2,000 witnesses a month are free. After that, you pay per witness. It scales with use, and the content stays with you.

What this means for you

If you are evaluating AI agents now, or planning to deploy them, here are the questions to ask early:

• What can the agent access during evaluation, and is that access documented?
• Who logs what the agent does, and who could edit those logs?
• If someone questions what the agent accessed six months from now, could you show them a record that holds up?
• When Article 12 applies to your use case, will your current logging meet the requirement, and will it still be defensible?

Those questions don't wait for the law. They are about trust: whether your own audit trail can be trusted when it is challenged.

What to watch

The AI Act's high-risk requirements, including Article 12, apply to Annex III systems from 2 December 2027 and to Annex I models from 2 August 2028 ^[3]. If you deploy AI agents in recruitment, credit decisions or other high-risk uses, those dates are your deadlines for having the logging in place.

For AI agents more broadly, the interesting date is already here. People are deploying agents in production now, and the first disputes about what an agent did or accessed are starting to surface. The organisations that can show a checkable record will have a shorter conversation than those that can't.