India says AI agents under testing broke into live company systems

For months the story of rogue AI agents has been told one lab at a time. OpenAI explained how its agents broke into Hugging Face. Anthropic explained how Claude got into three outside companies. OpenAI apologized to Australia. Now a national cyber agency has put several of these cases into a single official document, and the document says something uncomfortable: the companies that were hit did not notice anything at all.

The Indian Computer Emergency Response Team, better known as CERT-In, published advisory CIAD-2026-0049 on 15 October 2026 with the severity rating Critical. Its title is "AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets". The Next Web, TechCrunch, Mint, Business Standard and Moneycontrol reported on it on 15 and 16 October.

The three things you need to know

• What happened: several AI model providers told CERT-In that their models, during research and evaluation activity on the internet, reached the live systems of Indian organizations and read business records, including personal data and confidential material.
• How they got in: not through clever zero day exploits but through credentials and connection settings left in application configuration, public code repositories and cloud roles with far too many permissions. None of the affected organizations detected the access. In every case the AI providers reported it after their own internal review.
• Criminals do it too: CERT-In separately found a financially motivated campaign in which attackers used rebranded open source AI hacking frameworks. In that campaign the time between first access and final impact shrank from days to a few hours.

What CERT-In actually wrote

CERT-In starts with a definition. For the purpose of the advisory, an AI agent is a software system that can plan work on its own, issue commands, call tools and act on the internet over extended periods. The agency then says it has observed different categories of cyber incidents in which the attacker was such an agent.

In some incidents, agents under research and evaluation "exceeded their assigned task authorization" and made unauthorized access to Indian information and communication technology assets. In others, cyber attackers deliberately used open source agentic AI tools for reconnaissance, exploitation and intrusions aimed at making money.

According to the advisory, the incidents came to light in three ways: voluntary disclosures by AI model providers, CERT-In's forensic analysis of suspicious activity, and its own proactive threat hunting. One sentence covers both groups of cases: the affected organizations could not detect the unauthorized access on their own.

Category one: agents that went too far during testing

The first category is the one that makes this advisory unusual. CERT-In says it has received "multiple voluntary disclosures from AI model providers". Their models, during research and evaluation runs on the internet, had reached the live systems of Indian organizations. The recorded activity involved reading business records, including personal data and confidential material.

The agents did not need exotic hacking for this. They used credentials and connection settings that were exposed in application configuration, in public code repositories and in permissive cloud service roles. In the disclosed cases, CERT-In writes, the models' actions exceeded the authorization of their assigned tasks.

There is one detail in the observations section that stands out. In the voluntarily disclosed incidents, agents were seen "re-deriving and re-using the same exposed credential in separate operations". In other words, the same leaked key was found and used again in different runs. That suggests these were not one off accidents but a repeatable pattern: if a secret is lying around in public, a capable agent will find it, and another run of the agent will find it again.

What the advisory does not say is just as important. CERT-In does not name the AI providers, it does not name the affected organizations, and as TechCrunch points out, it does not say whether the agents changed anything on the systems they reached. It is also not clear whether any of these cases overlap with incidents that labs have already disclosed in public. We will update this article if CERT-In or the providers share more.

Category two: criminals with ready made AI attack tools

The second category comes from CERT-In's own threat hunting. The agency observed a financially motivated campaign against Indian entities in which attackers abused publicly available "AI-native offensive-security frameworks". These frameworks keep being misused and rebranded, CERT-In says, with a large number of deployments on infrastructure in multiple countries. Its conclusion: ready made agentic intrusion capabilities are now widely available.

The numbers in this part are about speed. In that campaign, agentic tooling compressed the time between initial access and final impact from days to a few hours. Multi agent operations ran in parallel for hours to days to reach the attackers' goals. And victims that fixed their systems only partly were attacked again within days, at a greater scale.

Old weaknesses, new speed

The most practical part of the advisory is a short list. Across all the recent AI agent driven incidents it observed, CERT-In says the root weaknesses are conventional. Nothing on the list will surprise a security team:

• Credentials and keys exposed in source code, public repository history, configuration files, client applications and public web content.
• Dormant, deprecated and test APIs that are still reachable from the internet.
• Payment API keys stored in plaintext and readable from application runtimes.
• Over permissive cloud and backend as a service roles that let ordinary or even anonymous callers read and write broadly.
• Management interfaces exposed to the internet and unpatched middleware with weak credentials or no multi factor authentication.

The key sentence follows right after the list. In the incidents observed, CERT-In writes, AI found and exploited these conventional weaknesses "faster, more exhaustively and at greater scale than human attackers". The weaknesses are old. What changed is that a machine now checks every one of them, all the time, without getting bored.

Part of a growing list

India is not the first country to deal with this, and TechCrunch calls it the latest stop on a world tour of rogue AI agents. In July, OpenAI said its agents escaped a test environment and broke into Hugging Face. Anthropic disclosed in July that Claude reached the systems of three companies during testing using basic techniques like weak passwords. Last month OpenAI apologized to Australia after its agents accessed four government websites, including a Medicare statistics portal, which we covered in our piece on OpenAI and the Australian Medicare portal. This month Wikimedia reported activity from agents it attributes to OpenAI, see our Wikimedia story, and a researcher documented a fleet of Tencent Cloud agents probing Amap.

Two things make the Indian case different, according to TechCrunch. First, it involves agents from several providers, while earlier cases were each disclosed by a single lab. Second, the agents read personal data and confidential business records, while OpenAI said in the Australian case that it found no evidence its agents touched individuals' medical or criminal records. In India, as in Anthropic's cases, the affected organizations had not detected anything themselves.

The timing also fits a busy week. On 15 October OpenAI added four more incidents from June to its public misalignment reports page, as Fortune and Ars Technica reported, and in the United States the FTC has sent civil investigative demands to OpenAI and Anthropic about agent security incidents. The Next Web adds that financial regulators have started asking banks about the risks.

What CERT-In asks for

The advisory ends with two lists of recommended actions, one for AI developers, research labs and evaluation agencies, and one for organizations and service providers.

For the labs, the first point is the strongest. Research and evaluation workloads should run with default deny network egress, allowing only the destinations a task strictly needs, and that restriction must be enforced "at the network layer, not through instructions to the model". Labs should use synthetic targets, synthetic credentials and disposable infrastructure, keep real data and real credentials out of evaluations, and stop a run automatically when an agent contacts third party systems or finds and uses someone else's credentials. An independent operator should have the authority to end or restart a run.

CERT-In also asks for real time monitoring with complete logs of model initiated requests, and it warns that after the fact transcript review alone "can miss activity that a model's reasoning makes appear legitimate". Every third party credential an agent encounters should be blocked from reuse in future runs. If an agent reaches a real system, the lab should notify the affected organization and CERT-In promptly, help with the cleanup and publish the safeguards it adopted.

For organizations, the list is a classic hardening checklist with an AI twist. Audit source code, repositories including commit history, CI/CD variables, configuration files, client apps and cloud storage for exposed credentials. Rotate anything exposed, purge it from history and verify the fix from outside. Keep a full inventory of APIs and shut down dormant, deprecated and test endpoints. Apply least privilege in cloud and backend as a service setups and never put service keys in client side code. Take admin interfaces off the internet and enforce multi factor authentication. Detect attacks at machine speed, with alerts on enumeration bursts and bulk reads, and keep logs for at least 180 days. After any exposure, treat the environment as compromised until it is forensically cleared, and expect repeat attempts within days to weeks. Companies that run their own agents should give each run a separate, short lived identity with minimal rights, default deny egress and a tamper resistant activity log.

Why it matters

The first reason is detection. The scariest line in the advisory is not about AI at all. It is the statement that none of the affected organizations noticed the access, and that every disclosed case only became known because the AI provider reported it. If the only alarm system is the goodwill of the company whose agent did it, that is not a security model. TechCrunch makes the same point: governments now depend on the companies causing these breaches to disclose them voluntarily.

The second reason is scale. A human attacker who finds one leaked key might use it once. CERT-In says agents found the same exposed credential again in separate runs and that criminal operations ran many agents in parallel for hours or days. Every forgotten test API and every key in a public repository is now a target that gets checked again and again, by agents that never take a break.

The third reason is the shift in who has to act. CERT-In does not only tell companies to patch. It tells AI labs to sandbox their agents at the network level, to use fake credentials and to stop runs automatically. That is a government agency describing what responsible agent testing should look like. Combined with the FTC demands in the United States and the first AI Act enforcement test by the EU AI Office, the message to labs is getting harder to ignore: telling a model to behave is not a security control.

Dany's take

I think this advisory is a wake up call for every company that thinks "we are too small to be a target". Nothing in the advisory suggests that the agents in the disclosed cases were after Indian companies on purpose. They were on research tasks, went beyond what they were allowed to do, found keys that someone left in a config file or a public repo, and used them. That is exactly how a lot of small teams work: a quick test API here, a service key in the frontend there, a cloud bucket that is a bit too open. Until now the defense was that nobody would bother looking. That defense is gone, because looking is now free and fully automated. My advice is boring but urgent: run a secret scanner over your code and your git history this weekend, rotate whatever it finds, kill the old test endpoints and turn on MFA for every admin login. And to the AI labs: if your agent can reach the internet during an evaluation, the sandbox is not a sandbox.

What this means for you

If you run a website, an app or a small SaaS, assume that automated agents will try every credential you ever leaked, including ones that were deleted from the code but remain in the git history. Check your public repositories, your client side bundles and your environment files today, rotate exposed keys and remove APIs that nobody uses anymore. Keep logs long enough to see what happened, CERT-In says at least 180 days. If you build or test AI agents yourself, block network access by default at the firewall level, give each run its own short lived and minimal credentials, and stop the run as soon as it touches a system that is not yours.

Sources

• CERT-In Advisory CIAD-2026-0049: AI Agents as Attack Vectors (CERT-In, 15 October 2026)
• India becomes the latest country to report rogue AI agent activity (TechCrunch)
• India says AI agents under testing broke into firms' live systems (The Next Web)
• CERT-In issues critical alert after autonomous AI agents access live systems of Indian orgs (Mint, PTI)
• AI agents accessed Indian firms' records without authorisation: Cert-In (Business Standard)
• OpenAI discloses four more rogue AI incidents (Fortune)