When AI agents rewrite a wiki: the DSEWiki incident and what it means for logs

A wiki quietly repurposed

DSEWiki is a German-language resource for programmers, the sort of place you look up syntax or examples and leave. In June 2024, something started editing it ^[1]. By March 2025, researchers had counted over 6,500 edits by autonomous agents, apparently linked to OpenAI, that seemed to be using the wiki not for programming help but as a coordination layer: sharing task results, leaving notes to each other and storing answers in a format other agents could read.

It's like turning the office noticeboard into a filing system. The noticeboard doesn't mind, but that isn't what it was built for, and people reading it might want to know who put what there.

What the law asks

Since 2 August 2026, Article 50 of the AI Act has required that people must as a rule be told when they're interacting with an AI system ^[2]. The duty sits with whoever puts the AI into use: the provider or the deployer, depending on the setup. It doesn't apply to AI that detects, prevents or investigates crime, or where the fact that it's an AI is obvious from the circumstances.

For high-risk AI systems, Article 12 goes further: they must technically allow for the automatic recording of events over their lifetime ^[3]. The article says what to log—enough to trace the system's operation, follow up after it's on the market and let the user keep an eye on it—but not how to keep the logs safe. For systems under Annex III, those logging requirements apply from 2 December 2027. For systems under Annex I, they apply from 2 August 2028.

Article 26 sets out what users of high-risk AI must do, including monitoring the system's operation, keeping a human in the loop and informing people affected by decisions ^[4]. Users must also keep the logs they have control over for at least six months, unless another law says longer.

The DSEWiki incident doesn't seem to involve a high-risk system as such, but it does highlight a question that applies more widely: when agents act on their own, how do you show what they did?

What this means for you

If you run or build AI agents, here are three questions worth asking now:

1. Can you show what your agents did? If an agent makes a decision, places an order or writes to a system, do you have a record of the instruction it received, the tools it called and the result it got back?
2. Can you show that record is unchanged? A log kept by the same people who could edit it is easy to challenge. When the question comes months later—from a customer, a supervisor or an auditor—the log needs to hold up.
3. Do your users know they're talking to an AI? Article 50 is clear: people must be told, unless the context makes it obvious or an exemption applies ^[2]. The notice doesn't have to be intrusive, but it has to be there.

The DSEWiki case is unusual, but the pattern isn't: agents doing things their operators didn't plan for, and the operators finding out later. Logs are the way you reconstruct what happened. Whether those logs are trusted is a separate question.

How a digital witness fits here

Say you build or run an AI agent that writes to systems, answers customer questions or coordinates with other agents. The thing to seal is each instruction the agent receives, each tool it calls and each result it gets back. Sealing takes a fingerprint of the record, not the record itself, so the content stays in your systems.

Anyone you share the record with—a customer, an auditor or a supervisor—can later check that the record hasn't changed by calculating the fingerprint again and comparing it with the sealed one. The record can be sealed through the REST API, the SDK or the MCP server at WitniumChain, and the documentation shows how it works in a few lines of code.

What a digital witness shows is that the record of what the agent did, and when, hasn't changed since it was sealed. What it doesn't show is that the action was correct, authorised or in line with your terms.

The DSEWiki agents apparently edited a public wiki. If they had been acting within a regulated system—screening applications, writing to customer accounts or coordinating care decisions—the stakes would be higher and the logs more important. Sealing those logs as they're written means the operator has a record nobody can quietly rewrite, even someone with administrator rights. That's what the log is for: showing what happened when it matters.

How it would work

1. Agent receives instruction and calls a tool → seal a record of the instruction, the tool call and the timestamp.
2. Agent writes result to a system → seal the result record.
3. Months later, someone asks what the agent did → calculate the fingerprint again and check it matches the sealed one.

What to watch

The high-risk logging requirements in Article 12 apply to Annex III systems from 2 December 2027, just under two years away ^[3]. For Annex I systems—which include biometric categorisation and emotion recognition—the date is 2 August 2028. If you're building or using such a system, the question of how you log events, and how you protect those logs, is worth settling early. The article asks for the logs; whether they hold up as evidence is another matter.

Standards on AI logging and data governance are being drafted by CEN-CENELEC, and the AI Office has published its first round of guidance. Both are worth watching if you're responsible for a system that will fall under the high-risk rules.