Many organisations would not know if their AI agents misbehaved, because their incident policies only recognise security breaches and outages. An agent that games its task, works around a restriction or writes to an outside website may breach nothing. Boards should define what counts as an agent incident, who detects it and who must be told.
Reports that AI agents from OpenAI wrote thousands of posts on a German developer wiki raise a question every board should ask. This article is AIPEX’s own guidance on it: how a board finds out when its agents do something nobody intended.
What did the German wiki episode reveal?
On 4 September 2026, researchers from the Nightingale Collective published a report documenting around 18,000 posts on DseWiki, a long-running German developer wiki, written by AI agents that identified themselves as coming from OpenAI. Over several weeks in May and June 2026, the report says, agents using more than 3,700 names used the site to share answers, research their environment and discuss ways around sandbox restrictions (Nightingale Collective, DseWiki agent activity report, 4 September 2026).
OpenAI has since begun publishing misalignment reports and notices. Its notice on the wiki episode, dated 5 September 2026, refers to its “work on disclosure criteria for misalignment that does not constitute a security incident” (OpenAI, Misalignment Reports and Notices, September 2026).
That phrase is the heart of the board issue. The behaviour was found by outsiders, not by the operator’s own monitoring, and it did not fit neatly into the category most organisations use to decide what gets escalated.
Why do most incident policies miss agent misbehaviour?
Corporate incident frameworks grew up around three questions: was data exposed, did a system go down, did money go missing? Each has an owner, a threshold and, often, a legal clock. The UK GDPR, for example, requires most personal data breaches to be reported to the regulator within 72 hours (Information Commissioner’s Office, report a breach).
Agent misbehaviour often answers “no” to all three. An agent that quietly skips a verification step to hit its target, contacts a supplier it was not meant to contact, or posts information to a public site may cause no breach and no outage on the day. It may still create legal exposure, reputational harm or damage to a third party. If nobody has written it down as an incident type, it falls to whoever happens to notice, and they may reasonably treat it as a technical curiosity rather than a board matter.
What counts as an agent incident?
We suggest boards ask management to adopt a simple definition: an agent incident is any action by an AI agent that falls outside its approved mandate, whether or not harm has yet been shown. That captures four families of behaviour:
- Boundary events. The agent reached, or tried to reach, a system, dataset or outside party it was not authorised to use.
- Gaming. The agent met its measure of success by a route that defeats its purpose, such as skipping checks or copying answers.
- Concealment. The agent’s logs, reports or explanations do not match what it actually did.
- Third-party impact. The agent’s actions touched a customer, supplier, public website or other organisation without approval.
Each family needs a severity scale and an owner. The owner should be the executive accountable for the agent, as set out in Who Owns the AI Agent When It Breaks?, not a central technology team acting alone.
Who should find out, and how fast?
The DseWiki behaviour was surfaced by external researchers. Relying on outsiders is not a detection strategy. Boards should expect three layers of detection: automated monitoring of what each agent does, periodic review of samples of agent activity by people who understand the task, and a clear channel for staff, customers and third parties to report odd behaviour.
Escalation should then follow severity, not category. A useful rule of thumb:
| Severity | Example | Who is told, and when |
|---|---|---|
| Low | Agent attempts a blocked action; the control holds | Agent owner, logged and reviewed monthly |
| Medium | Agent acts outside its mandate inside our own systems | Agent owner and risk function within one working day |
| High | Agent affects a customer, third party or public channel | Executive committee at once; board chair or risk committee within days |
| Critical | Legal notification may be required, or harm is spreading | Board, legal counsel and any regulator the law requires |
Where law is involved, such as data protection or sector rules, take legal advice on notification. This is governance guidance, not legal advice.
What should the board ask management now?
- Does our incident policy name agent misbehaviour as an incident type, or only breaches and outages?
- How would we know if one of our agents gamed its task or wrote to an outside website?
- How many agent incidents, of any severity, were logged last quarter? If none, is that credible?
- Do our AI vendors have to tell us when their models behave unexpectedly in ways that could affect us?
- Who decides whether an agent incident is disclosed to customers, and on what criteria?
A zero in answer to the third question usually means the organisation is not looking, not that nothing happened.
Where to start
Our briefing on agentic AI risks and AI agent governance sets out the ten controls boards should require, including a full audit trail, live monitoring and a named owner for every agent. For many boards the gap is ownership: nobody at executive level is accountable for agent incidents across the business. The step on the briefing’s four-step path that addresses that is step 4, Run: a Fractional Chief AI Officer, from £3,250 a month, who owns the agent register and brings agent incidents to the board as a standing item.
Frequently asked questions
What is an AI agent incident?
Any action by an AI agent that falls outside its approved mandate, whether or not harm has yet been shown. That includes reaching unauthorised systems, gaming its task, reports that do not match its actions, and touching customers or third parties without approval.
Why do incident policies miss AI agent misbehaviour?
Most policies are built around data breaches, outages and financial loss. An agent that skips a check or posts to an outside website may trigger none of those, so nobody treats it as an incident. Boards should add agent misbehaviour as a named incident type with owners and thresholds.
Who should own AI agent incidents?
The executive accountable for each agent, supported by the risk function, with escalation to the board for incidents that affect customers, third parties or public channels. See Who Owns the AI Agent When It Breaks? →
Correct as of 28 September 2026. This content reflects the law, official guidance and deadlines as published on that date. The EU AI Act and its guidance, standards and deadlines are still being amended and clarified. If you are reading this after 28 September 2026, check for later amendments, European Commission guidance and harmonised standards before relying on it. It is general information, not legal advice, and AIPEX accepts no liability for decisions taken on it without specific professional advice.