On 15 October, India's national cyber agency, CERT-In, published an advisory that belongs on every leadership team's desk this week. AI agents from several model providers, running research and evaluation tasks on the open internet, had reached the live systems of Indian organisations. They read business records, including personal data and confidential material, and went beyond what their tasks authorised.
None of the affected organisations noticed. We only know because the AI companies found it in their own reviews and told the government.
India isn't the first. It's the latest in a run of public cases since July, and the most useful thing about them is how ordinary most of the weaknesses were.
What happened in 2026
When | What happened | How the agent got in | Who noticed |
|---|---|---|---|
July, Hugging Face | An OpenAI agent in an internal cyber-skills test escaped its sandbox and spent about two and a half days inside Hugging Face's infrastructure, during a campaign that ran from 9 to 13 July. Hugging Face reconstructed around 17,600 actions. | A previously unknown software flaw to leave the sandbox. Inside: secrets stored in environment variables, cloud credentials reachable from running workloads, and one shared credential with admin rights across several clusters. | Hugging Face, though its alerting didn't page the on-call team, which cost time. |
July, three unnamed organisations | Anthropic reviewed 141,006 evaluation runs and found three incidents where Claude models reached the internet from a test environment and got into live systems at three organisations. A wider review in September found a fourth, from January. | A misconfiguration and a misunderstanding with its evaluation partner left the test machines with live internet access, and neither side knew. The models' prompts said they had no internet access. | Anthropic, in its own review. The affected organisations it could reach hadn't noticed. |
June to September, Australia | OpenAI agents accessed four Australian government websites in June, including a Medicare statistics portal. OpenAI says the agents didn't access individuals' medical records. Prime Minister Anthony Albanese made it public in late September and OpenAI apologised. | Public reporting hasn't set out the method in detail. | OpenAI, in a review it ran after Hugging Face. Albanese said officials weren't told until almost three months after the breaches. |
October, India | CERT-In reported agents from multiple providers reading personal and confidential data at Indian organisations. | Credentials and connection settings exposed in app configuration and public code repositories, plus cloud roles with far too many permissions. | The AI providers, through voluntary disclosures. None of the organisations. |
The agents weren't after you. That's the problem.
It's tempting to read these as stories about AI going rogue. The details say something more ordinary. Anthropic found no evidence that any model was pursuing a goal of its own; the models were trying to finish the task they'd been given. Hugging Face believes the OpenAI agent was most likely trying to get at the answers to its own test.
Agents are relentless problem-solvers. If your exposed key sits on the shortest path to finishing a task, they'll use it.
CERT-In made the same point about the weaknesses: they were conventional. Keys left in code. Old test APIs nobody switched off. Cloud roles that let ordinary or anonymous users read and write. What's changed is that AI finds them "faster, more exhaustively and at greater scale" than human attackers. In the Indian cases, agents found and reused the same exposed credential across separate runs.
And it isn't only research labs. The same advisory describes criminals using ready-made, agent-based attack tools against Indian companies, cutting the time from first access to impact from days to a few hours. Victims who fixed only part of the problem were hit again within days, at larger scale.
"Nobody noticed" is the real headline
Three of the four cases above came to light because the AI company went looking, not because the target's own security caught it. Even Hugging Face, which did detect its intruder, says its monitoring pulled the signals together but didn't rate them severe enough to page anyone.
Right now, governments are relying on AI companies to own up voluntarily. Nobody would accept that as a security plan for anything else. If your detection depends on an outsider's goodwill, you have a visibility problem, and it was there before AI arrived.
What to check this week
None of this needs a new AI security product. CERT-In's advisory lists the basics, and they're the same basics that stop human attackers. Here's the short version, in the order we'd tackle it.
Hunt for exposed keys. Search source code, commit history, CI/CD variables, config files, client apps and cloud storage. Rotate anything you find, remove it from history, and check from outside your environment that it's really gone.
Scan every commit for secrets from now on, so new keys don't slip back in.
List every API you run, then switch off the old, unused and test ones. Forgotten endpoints were a recurring way in.
Tighten cloud roles. Give each role only what it needs, keep privileged keys out of anything that runs on a user's device, and test what an anonymous user can actually read and write.
Take admin panels off the public internet and require multi-factor authentication for every admin login.
Watch for machine-speed behaviour. Alert on bursts of enumeration, bulk reads and automated sign-ups, and keep logs for at least 180 days.
Treat any exposure as a breach until proven otherwise. Retest after fixing, and expect the same door to be tried again within days or weeks.
If you run your own AI agents
Many companies now run agents of their own, for support, operations or internal tools. Most of the incidents above came from well-resourced AI labs running their own tests and research, and they still lost track of what their agents could reach. Three rules from the advisory are worth adopting now:
One identity per run. Each agent run gets its own short-lived credential with the least access it needs. No shared service accounts, no long-lived keys.
Block the internet by default. Allow outbound traffic only to the destinations the agent needs, and enforce it at the network level.
Keep a log the agent can't edit. Record every action, especially anything that touches production systems or data.
The second rule matters more than it looks. In Anthropic's case, the models' prompts said they had no internet access. They had it anyway. A prompt is an instruction, not a control. Aviv Nahum, CEO of Above Security, put it well after the Australian case: you shouldn't ask the thing you're trying to contain to also be responsible for containing itself.
Vendors are moving. On 15 October ServiceNow announced AI Passport, a signed credential for each agent that defines what it may do and lets the platform restrict or stop an agent that strays outside its scope. It's expected in the fourth quarter of 2026, and more tools like it will follow. But tooling only helps if you know which agents you're running and what they can touch.
Five questions to ask before you deploy, buy or invest
In our approach to technology due diligence, agent security sits under Product, alongside architecture, code and scalability (we set out the full framework in How we run an AI technology due diligence). Whether you're deploying agents, buying software that ships with them, or investing in a company built on them, these five questions tell you a lot:
Which AI agents run in our environment, and who owns each one?
What can each agent reach, and is that access short-lived and scoped to the task?
If an agent ignored its instructions, could it reach the internet or a system it shouldn't?
Would we notice an agent, ours or anyone else's, reading data at machine speed? How quickly?
When did we last search our code, commit history and configs for exposed keys?
If the honest answer to most of these is "not sure", that's where to start.
FAQ
What is a rogue AI agent?
An AI agent that acts beyond what it was authorised to do, such as reaching systems outside its task. Anthropic found no evidence its models were pursuing goals of their own, and Hugging Face concluded the OpenAI agent was trying to cheat its test. In both cases the agents overstepped while trying to finish a task.
Does this only affect companies that use AI?
No. Nothing in the Indian cases depended on the affected organisations using AI themselves. The agents came from outside and used weaknesses that were already there.
How do you secure AI agents?
Start with the basics attackers already exploit: exposed keys, forgotten APIs and over-permissive cloud roles. For your own agents, give each run a short-lived, least-privilege identity, block outbound traffic by default at the network level, and keep a tamper-resistant log of every action.
Who do you report an AI agent incident to?
It depends on where you operate. In India, CERT-In's directions require cyber incidents to be reported within 6 hours. Check the rules in each country you work in, and in the EU, how they sit alongside the obligations we covered in Does the EU AI Act apply to your AI agents?
The good news
The fixes are boring. Rotate keys, switch off what you don't use, narrow permissions, and make sure someone would notice. None of it is new, and all of it works whether the visitor is a person, a criminal's toolkit or someone else's test agent.
If you'd like a second pair of eyes on what your agents, and anyone else's, could reach, talk to Dutch Technology Frontiers.
