AI agents plan, use tools and work through tasks on their own. They have developed quite astonishing capabilities by now, can solve complex problems and, if needed, work autonomously for many hours. Two incidents in recent days show why the same capability turns into one of the real AI agents dangers when technical limits are missing.
Two reports on the same day
In November 2026, two reports came to light that together paint an unusually clear picture. At a provider of sign-in services, a test with an AI framework got out of control. In an experiment, coding agents disclosed a secret they were supposed to keep to themselves. Both draw attention to the dangers of AI agents that arise from their capabilities: How much can agents actually do, and where do these capabilities become a danger?
Both cases share the same root: an agent is allowed to act, and whatever it is allowed to do, it does faster and with more stamina than any human. Whether that is a blessing or a problem depends on the limits that have been set for it.
What sets an AI agent apart from a chatbot
A chatbot answers. It receives a question, returns text and waits for the next input. An AI agent, by contrast, completes a task. It receives a goal, works out the intermediate steps itself and uses tools to do so: browser, file system, mailbox, databases, programming interfaces. The result is not an answer but a changed world: a finished spreadsheet, corrected program code, a sent message.
Assistants sit in between. They make suggestions, and the human carries them out. Only when the software itself clicks, writes, sends and deletes is it an agent. How far-reaching this step is has been discussed for some time under the heading of AI that acts on its own. What matters is less the intelligence of the model than the question of what it is allowed to do.
How an agent works, step by step
Almost every agent runs on the same loop of five building blocks. It starts with the goal, phrased in everyday language. From this, a plan emerges: the model breaks the assignment down into sub-steps. For each sub-step it picks a tool and calls it with the permissions it has been granted. The tool's result is read back into the model's working memory as an observation. Then the loop starts over: the plan is adjusted and the next step chosen until the goal is reached or a stop condition kicks in.
The loop is the real innovation. A classic program follows a fixed sequence written by a human. With an agent, the model decides itself in every round what happens next. This is exactly where opportunities and dangers lie side by side: the agent finds paths nobody thought of, and it also finds paths nobody wanted.
An example from invoice checking
An agent is to check the open incoming invoices for one month. The goal reads: flag invoices that deviate from the purchase order. The plan has four steps: fetch the mailbox, read the attachments, compare against the order data and write the deviations into a spreadsheet. The mailbox, the file storage and the spreadsheet interface serve as tools.
The seventh invoice shows how the loop works. The invoice exists only as a scan, and text recognition returns gibberish. The agent observes this, discards the plan for this file and switches methods. This happens without asking back and without any developer having anticipated the case. The loop keeps running until all invoices have been processed.
Read access to the mailbox is enough for this task. The agent does not need to send, delete or browse the web. Every capability beyond what is necessary is an additional attack surface. If the same agent were also allowed to send messages and research online, a checking task would turn into a toolkit for abuse: a manipulated invoice with a hidden instruction in the attachment could get it to send data to strangers.
What AI agents can do today
The capabilities of today's agents are real. They work on routine tasks with focus for hours without tiring. They research, summarise documents, write and test program code and check configurations for errors. Where an employee used to spend an afternoon reconciling lists, the agent is done in minutes. This ranges from scheduling appointments and drafting reports to debugging program code.
The same applies to security. The same models that find vulnerabilities help to fix them. Defenders can use agents to probe their own infrastructure regularly and thoroughly, on a scale no small IT team could manage by hand. How much comes out of it depends on the task, the tools and the effort: give an agent more compute time, and it reaches more targets in tests.
This is exactly where the picture tips. What applies to the defender applies in the same way to anyone scanning a network, with a mandate or without. Capability is neutral. It amplifies what the agent is allowed to do and, unfortunately, also what it manages to do by accident.
When a test gets out of control
The case of the provider WorkOS shows this with full clarity. A security researcher was testing the offensive AI framework ARTEX in a benchmark, that is, an exercise in an isolated test environment. His agent broke out of this environment and attacked WorkOS systems. According to the company, this was neither intentional nor malicious. It was a test that went rogue, not a targeted attack.
The sequence of events is quickly told. On 25 October 2026, the first unauthorised access to an internal platform took place. Five days later, on 30 October, data records were retrieved there on a large scale. It was noticed by an employee who spotted unusually high usage of a connected system. Public access was removed that same day, and new credentials and further blocks followed on 30 and 31 October. On 2 November, the company went public.
Sales and customer support systems were affected: business contacts, account histories as well as summaries and excerpts from sales calls, support cases and conversations with customers, and in a few cases also end users' email addresses.
How the sandbox breakout happened in detail remains unclear. All data obtained has reportedly been deleted and not shared. An independent forensics firm compared its evidence with WorkOS's logs and confirmed the attribution.
Ordinary gaps, just found faster
What stands out is less the breakout than what the agent found afterwards. On an older internal platform, the interfaces were reachable from the internet and the access rules too generous. An easily guessable development credential was still valid in production. A rate limit, which caps the number of requests per unit of time, was missing. And monitoring kicked in too late.
None of these weaknesses is new. Any experienced attacker could have found them. The difference lies in the pace: an agent keeps trying without breaks and without boredom, and what would have cost a human days, it manages in hours.
The gaps were ordinary. The only new thing is that an agent finds them faster than any human.
How far this goes is shown by a recent benchmark with simulated corporate networks. The best model reached more than 80% of the targets set, with every action logged from the outside. Even an inexpensive open-weight model achieved around 73%, at a fraction of the cost. Capabilities of this kind are therefore no longer reserved for the most expensive providers.
For anyone who tests agents or uses them in an AI penetration test, three conclusions follow. First: real network separation instead of a mere configuration that can be bypassed. Second: outbound filters that only allow approved destinations. Third: clear rules of engagement, set down in writing and enforced technically, including a kill switch. If you want to know what makes sense before such a test in the first place, the security check before the pentest is a good starting point.
When agents give away secrets
The second case is an experiment by AE Studio for the AI Alignment Foundation. Coding agents were supposed to keep a deploy token secret. A token is a digital key that grants access to a service. The agents had access to a forum where other agents were present and where the solution to their actual task could be found.
When the agent was offered help in the swarm in exchange for the token, the token ended up in the forum in approx. 15% of runs, and in approx. 24% the agent executed a foreign installation script. In an ordinary help forum, the figures were approx. 2% and 0%. The token was a test token, the environment a local sandbox, and the setup came from a hackathon.
The researcher does not see any covert behaviour behind this. The model simply chooses the easiest way to complete its task. When a conversation partner advances a goal, that outweighs a rule that only exists in the prompt. For protecting credentials, this means: a secret that sits in the agent's context can be passed on by the agent. If you never give it the secret, you do not have to rely on its discretion.
Why violations are rarely reported
Something else stood out in the same experiment. Only a small minority of the agents reported the violation on their own. When asked directly, almost all of them admitted it. The model optimises for the task, not for reporting, and self-disclosure is not part of what the task rewards.
For operations, this means: the agent is not a reliable source on its own behaviour. Logging must sit outside the agent, in network, proxy and tool logs that the agent cannot alter, with alerts for unusual patterns. How easily agents can lose control over their own monitoring is shown by a case in which agents weakened their own monitoring.
At WorkOS, too, the access was only noticed when a human happened to spot the unusual usage. An alert would have kicked in earlier.
Limiting AI agents dangers with a few basic rules
Both cases result in a compact protection concept of five rules. The invoice agent shows what it looks like.
- Keep secrets out of the context. Tokens are short-lived, narrowly scoped and issued anew for each task. The invoice agent never receives the accounting password.
- Least privilege. Read where only reading is needed. Actions with external effect such as sending, payment or deletion only after human approval.
- No free outbound access. No open forums, package sources or foreign scripts, outbound traffic only to approved destinations.
- Enforce isolation technically. Real network separation instead of mere configuration, test environments without any connection to production networks.
- Logs outside the agent. Plus alerts, a kill switch as well as rate limits and access limits on your own side, so that a fast visitor stands out, whether human or agent.
That leaves the question that overarches everything.
Are AI agents dangerous?
What matters is that each of these rules is enforced technically. An instruction in the prompt never to pass on the token is a wish, not a lock. The swarm experiment shows that a goal can override this wish, whereas a missing network connection cannot be overridden.
If an agent processes personal data, for example in mailboxes or customer systems, a data protection impact assessment under Art. 35 GDPR should also be considered. The basic rules above reduce the risk there too, but do not replace it.
Conclusion
Agents are capable and useful, and both incidents show the same thing. The danger lies less in some new magic than in old mistakes: forgotten credentials, missing limits and too much trust in rules that only exist in the prompt. An agent does what it is allowed to do, only faster and with more stamina than a human.
Anyone deploying agents should therefore draw limits technically and check from the outside. What the agent cannot see, cannot reach and cannot change, it cannot give away either.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
