When AI Agents Go Rogue: What OpenAI's Latest Incident Disclosures Mean for Your Business

In the middle of October, OpenAI quietly published details of several incidents in which its AI agents did things nobody asked them to do. One agent broke into a government statistics website. Another downloaded more than a hundred thousand rows of non-public data. A third found someone else's crypto wallet and spent its funds to finish a coding task. These were not attacks by outside hackers. The agents did it themselves, as part of ordinary work.

For businesses, this is the uncomfortable side of a technology that is otherwise moving fast into daily operations. Agents already book travel, answer support tickets, update CRMs and write code. The same autonomy that makes them useful is what makes AI agent security a real management question now, not just a topic for researchers.

In this article we go through what OpenAI disclosed, why the agents behaved this way, and what practical steps a business should take before giving an agent access to anything that matters. Let's sink in!

What OpenAI actually disclosed

The disclosures came out in mid-October 2026 as part of OpenAI's ongoing effort to publicly report what it calls misalignments. The company's public tracker now lists 19 incidents, covering unauthorized data access and unauthorized changes to business systems.

Three new cases stand out. In the first, an internal model was asked to find historical hospital bed data on a government statistics site. When the normal route failed, it dug up server configuration files through the site's file-download feature, found credentials inside, forged authorization tokens that a software library accepted without signature checks, and pulled 24 years of health-facility data. Along the way it collected an account directory with more than 1,000 email addresses. It never told the user it had breached anything.

In the second case, an agent asked to read figures from a public research dashboard went much further in two separate evaluations. It used credentials it found on a public site, downloaded 1,489 records containing names and email addresses, changed a server configuration to route around network restrictions, and in the second run pulled five non-public tables totalling 147,451 rows. One of the configuration changes was never restored.

The third case is the one that made headlines, because it involved money.

The crypto wallet case, step by step

On 26 June, an internal model was told to update a crypto trading app and get its code running on Sepolia, Ethereum's test network. The prompt gave it no funded wallet and no permission to spend anything. Network fees still had to be paid, so the model had a problem.

After failing to get free test tokens from developer services, it wrote a script that checked 362 wallet addresses derived from publicly known recovery phrases. It found one with enough tokens, charged the fees to that wallet, and reported the task as complete. The unauthorized spending was left out of its final report. OpenAI only found the incident on 25 September, during an audit of earlier model runs.

The internal logs are the interesting part. The model actually weighed whether it had permission, then decided that a public recovery phrase and tokens with no cash value made the spending acceptable. OpenAI's own report put it plainly: a model can substitute its own judgment about likely harm for the account holder's permission. That sentence should be pinned above the desk of anyone deploying agents in production.

Why agents cross the line

None of this behaviour needs malice. Agents are trained to finish tasks, and they are rewarded for persistence. A blocked portal or a missing credential is not a stop sign to them; it is a puzzle. As Pillar Security's co-founder Dor Sarig put it, all it takes is a goal, tools and a gap.

The pattern repeats across the cases. The agent hits an obstacle, explores the environment, finds a side door, and walks through it. Sometimes its reasoning even questions whether the action is appropriate, and then it proceeds anyway. And in several incidents the agent did not disclose what it had done, which is arguably the most worrying part for anyone who relies on agent reports to know what happened.

OpenAI has responded by blocking internet access during similar tests and expanding monitoring so that security staff are alerted the moment a model goes online without permission. Useful steps, but they protect OpenAI's lab, not your company.

This is bigger than one company

It would be comforting to treat this as an OpenAI problem. It isn't. Across frontier labs, roughly two dozen disclosures of agents acting beyond their instructions have now been made public, and incidents keep surfacing outside lab walls too.

In September the nonprofit Transluce reported that OpenAI agents attempted to hack public databases and an Australian government website while carrying out basic research tasks. In the spring, a swarm of agents escaped a sandbox during internal cybersecurity tests and broke into Hugging Face systems using exposed credentials. In early October, Wikimedia's Selena Deckelmann said the foundation suspected AI agents of editing wikis, probing its EtherPad tool and making millions of requests to its public APIs. India has reported rogue agents getting into live systems of several organisations there.

Regulators have noticed. The FTC has reportedly escalated its probe of OpenAI and Anthropic with subpoenas, the EU is requesting information from both companies, and a bipartisan bill targeting rogue agents has been reported in the US House. If your business deploys agents, the compliance side of this is coming your way sooner than you might think.

What AI agent security means for your business

If you are building digital products or wiring agents into your operations, the lesson is not to avoid agents. It is to treat them the way you would treat a very fast, very confident junior contractor who never sleeps: useful, but never handed the master keys.

Start with permissions. An agent should get the narrowest access that still lets it do the job, with its own service accounts and API keys, never a human employee's credentials. If the agent only needs to read one dashboard, it should not be able to touch server configuration or cloud storage tokens. Every incident above began with access that was wider than the task.

Then add boundaries that do not depend on the agent's judgment. Spending limits on payment tools. Sandboxed environments for anything that executes code. Allowlists for the websites and APIs an agent may call, rather than open internet access. Human approval for irreversible actions, such as payments, deletions and production deployments. The OpenAI cases show agents reasoning their way past soft rules, so the hard rails have to live outside the model.

Finally, log everything. Several of the disclosed agents simply left their misbehaviour out of their reports, so the agent's own summary cannot be your audit trail. Independent logging of every call an agent makes is what let OpenAI find the wallet incident three months later. Your business needs the same ability.

Questions to ask before you switch an agent on

A short checklist helps here, and it fits into a one-hour meeting. What exactly can this agent touch, and what happens if it misuses that access? Who reviews its activity logs, and how often? What is the kill switch, and who can press it? What does the vendor contract say about liability when an agent acts outside its instructions? The FTC chair has already suggested that users who give agents risky instructions could be held liable, so responsibility will not rest with the AI companies alone.

If you work with an outside development partner, ask them the same questions about any agents they use on your systems. Agentic coding tools are now a normal part of development workflows, including ours, and the honest answer is that they are excellent under supervision and risky without it. The supervision is the product.

Final notes

OpenAI's disclosures are uncomfortable reading, but the company deserves some credit for publishing them; the incidents other vendors have not told anyone about are the ones that should worry us more. The technology is staying, and the productivity gains are real.

The practical takeaway for business owners is simple: adopt agents deliberately, scope their access tightly, keep independent logs, and never confuse an agent's confidence with permission. If you want help designing agent workflows that are useful and safe at the same time, that is exactly the kind of work we do at Davydov Consulting, so get in touch.