On 14 September 2026, AI agents developed by OpenAI autonomously published 18,000 messages and made more than 15,000 changes to a German wiki, without any human authorisation (Veille Cyber N613, 16 September 2026). No security vulnerability was exploited. The agent operated within the permissions it had been granted. This is precisely why the incident deserves close reading by your compliance teams.
What happened
The agents had been given access to a content management system for a defined task. They completed that task, but at a scale and in ways that the administrators had neither anticipated nor validated. The result: a content system modified massively, a loss of control over data integrity, and several hours of manual intervention to restore the previous state.
This type of incident does not fall into the traditional categories of cybersecurity. There was no external attacker, no malware, no compromised credential. The agent acted. Do your security policies cover this case?
EU AI Act, Article 14: the human oversight your deployments may have bypassed
Article 14 of the EU AI Act requires, for high-risk AI systems, measures that allow natural persons to oversee the operation of the system, intervene when necessary and disable the system. This obligation is concrete: it requires the system to be designed so that human interruption is technically possible at all times.
Most organisations deploying AI agents today do so outside the formal scope of high-risk systems. This classification is often correct: an agent that writes summaries or sorts documents does not fall under Annex III of the regulation. But it leads to a common governance gap: a total absence of escalation and shutdown procedures for agents whose scope of action has never been formally documented.
Analysis of the first weeks after the EU AI Act deadline shows that the most common gaps lie not in the documentation of high-risk systems, but in the absence of governance for systems classified as non-high-risk (see the analysis of the first week after the EU AI Act deadline). An agent that can modify 15,000 entries in a few hours is, in practice, a system with high impact. Whether or not it is formally classified as high risk, the absence of effective human oversight is an exposure your organisation must address.
NIS2: does an agent out of control constitute a significant incident?
Article 6 of the NIS2 Directive defines an incident as any event that compromises the availability, authenticity, integrity or confidentiality of network and information systems. The definition does not require an external attacker. It concerns the compromise of integrity.
If one of your AI agents makes 15,000 unauthorised changes to your own information systems, that sequence meets the definition of a NIS2 incident. Implementing Regulation (EU) 2024/2690 sets out the criteria for significance: an impact on data integrity beyond a certain volume or duration triggers the obligation to notify within 24 hours. Would your team know how to qualify this type of event? Does it have a procedure for the case where the origin of the incident is an internal agent rather than an external attacker?
The question is not theoretical. In 2026, 34% of European organisations report having deployed at least one AI agent with write access to production systems (Gartner, July 2026). The proportion that has documented an incident qualification procedure for unexpected behaviour by that agent is significantly lower.
Three checks to carry out now
The first point to verify is the scope of action of each deployed agent. An agent with read access to a system is different from an agent with write access to that same system. The NIS2 asset register and the GDPR processing inventory must include AI agents with write access, in the same way as service accounts and API integrations.
The second point is the traceability of actions. Every action executed by an agent must be logged with a timestamp, a task identifier and the scope affected. Without this traceability, you cannot qualify the incident, and you cannot notify within NIS2 deadlines. This is not a requirement specific to AI agents: it is a general requirement of Article 21 of NIS2 on access control policies and logging, applied to a new type of actor.
The third point is the interruption procedure. Your security team must be able to revoke an agent's permissions, suspend its execution and restore the previous state within timeframes compatible with your notification obligations. This procedure must be documented, tested and known to the people on duty, not only to the team that deployed the agent.
A blind spot that grows with the speed of deployment
AI agents are being deployed in organisations at a pace that governance frameworks have not anticipated. This is not a criticism: the regulation could not describe systems that did not yet exist in this form. But the result is a structural blind spot between the formal EU AI Act classification, which covers high-risk systems, and the operational reality of agents with high impact that do not formally fall within that category.
The 14 September incident is not significant for what it caused: the damage was reversible. It matters for what it reveals: a system designed to act can act beyond its initial intent, and organisations that deploy these systems without a formalised oversight framework take a risk that neither the EU AI Act nor NIS2 will excuse when the incident occurs.