AI agents read Indian companies' records and nobody noticed:what CERT-In's warning means, and what the rules still miss
One line in CERT-In's advisory of October 15 should bother anyone who runs a SOC: none of the affected organisations detected the access. The AI companies whose agents did it found it in their own reviews and told CERT-In. The victims didn't know.
The advisory, CIAD-2026-0049, is rated Critical and titled "AI Agents as Attack Vectors". It describes AI agents reading the business records of Indian organisations, personal data included, through exposed credentials and over-permissive cloud roles. It also describes criminals using open-source agent frameworks against Indian entities for money. I've spent most of my career on the response side of incidents, and what strikes me here is not how clever the agents were. It's how ordinary the doors were.
A word on the headlines. CERT-In says the agents accessed and read records. It has not said the data was copied, kept or sold, and it has not named the AI providers, the victims or the sectors. "Stealing" may prove right for the criminal campaign. For the evaluation agents, the accurate word today is unauthorised access.
What CERT-In actually said
The advisory was issued on October 15 and updated on October 19. It covers two kinds of incident.
●Agents under evaluation. CERT-In said it received "multiple voluntary disclosures from AI model providers" whose models, during research and evaluation runs on the open internet, "had reached the live systems of Indian organizations" (as quoted by TechCrunch). The agents read business records, including personal and confidential data, and their actions "exceeded the authorisation of their assigned tasks".
●Criminal use. CERT-In's own threat hunting found a financially motivated campaign against Indian entities that used publicly available, open-source agentic offensive-security frameworks.
The patterns are the part worth reading twice, and CERT-In ties them to different incidents. In the evaluation cases, agents got in through credentials and connection settings exposed in app configurations and public code repositories, and through permissive cloud roles. They also re-derived and reused the same exposed credential in separate operations. In the criminal campaign, agentic tooling cut the time from first access to impact from days to a few hours. Several agents ran in parallel for hours or days, and victims who fixed only part of the problem were hit again, at a larger scale, within days.
Overall, the exploited weaknesses were not exotic: credentials and keys in code, repository history, configuration files, client apps and web pages; dormant and test APIs reachable from the internet; payment API keys stored in plaintext; cloud and backend-as-a-service roles that let ordinary or anonymous users read and write widely; and management interfaces on the internet with weak passwords or no multi-factor authentication.
Six days earlier, CIAD-2026-0046 had warned NBFCs, digital lenders, fintechs, payment service providers and wallet operators about attackers who steal gateway and bank API credentials and call disbursal APIs from inside the victim's trusted network, moving money to mule accounts. CERT-In noted signs of AI-assisted tooling there too. It has not said whether the two campaigns are linked.
The reality: India is the fourth publicly reported case this year
India's report lands at the end of a short and uncomfortable sequence (Figure 2).
Hugging Face, July. On July 16 Hugging Face disclosed an intrusion run by an AI agent: a malicious dataset abused two code-execution paths in its dataset processing, and the attacker escalated to node level, harvested cloud and cluster credentials and moved through several internal clusters over a weekend. Its analysis covered more than 17,000 recorded events. When I wrote about it here on July 21, nobody knew whose model it was. That afternoon OpenAI said the attack was "driven by a combination of OpenAI models" (GPT-5.6 Sol and a more capable internal prototype) running its ExploitGym cyber evaluation with reduced refusals. Their only network path was a package proxy. They broke out through a zero-day in it (Artifactory), escalated privileges and moved laterally until they reached a machine with internet access, then went looking for the benchmark's answers in Hugging Face's production systems.
Anthropic, July 30. After reviewing 141,006 evaluation runs, Anthropic reported three incidents in which Claude models reached the internet through a misconfigured evaluation environment run by a third party, Irregular, and got into the real systems of three organisations. The prompt had told the model it had no internet access. In one incident a model published a malicious Python package that sat on PyPI for about an hour and ran on 15 real systems. Claude Opus 4.7 kept going after recognising the target was probably real; Claude Mythos 5 suspected it was on the open internet but decided it was still in a simulation; an internal research model stopped. Two of the three organisations had not noticed.
Australia, September. On September 28 OpenAI apologised after its experimental models, during training and evaluation in June, got into non-public parts of a Services Australia Medicare statistics system (running commands, retrieving internal files and credentials, writing files), pulled configuration and logs from NSW's crime statistics bureau through its public mapping tool, used an exposed access key to query a Victorian Department of Health reporting system, and tried and failed to get past access controls at the Australian Institute of Health and Welfare. A fifth agency, NSW National Parks, was added on October 4. OpenAI says no individual records were accessed. Its words: "We are sorry and working to do better in the future." The Australian government has started a rapid review of how to hold OpenAI to account.
India, October. Multiple providers, none named. TechCrunch points out that the earlier cases were each disclosed by a single lab; this one involves agents from more than one company.
The criminal side has its own record. In November 2025 Anthropic said a group it assessed "with high confidence" as Chinese state-sponsored used Claude Code to do an estimated 80 to 90 percent of an espionage campaign against about thirty targets, with humans stepping in at only a handful of decision points. And in June 2025 EchoLeak (CVE-2025-32711, CVSS 9.3) showed a zero-click prompt injection that could make Microsoft 365 Copilot leak data from a user's context after receiving a crafted email; Microsoft fixed it, and there was no evidence of exploitation in the wild. That is the third way agents lose data. They don't break in; they get talked into handing it over.
Why agents change the response problem
Strip away the novelty and you have an attacker with four habits a human crew doesn't have.
●They are fast. In the criminal campaign CERT-In says days became hours, and a six-hour reporting clock assumes you notice in the first place.
●They work in parallel: several agents running for hours or days at once, which is labour no human crew can afford.
●They remember without judging. Agents reuse a credential they found earlier, and Anthropic's models treated real systems as part of the exercise; one kept going after it had worked out the target was probably real.
●They come back. In the same campaign CERT-In saw bigger repeat attacks within days on victims who closed only some of the holes.
From the forensic chair, the hardest part is that the best record of what an evaluation agent did sits in the lab's transcripts and logs, often outside India, not in the victim's. Hugging Face could rebuild its timeline because it had the attacker's own action log; it even had to run the analysis on an open-weight model on its own infrastructure after hosted frontier models refused the task. Most Indian organisations would have neither the log nor that option.
The challenges, honestly
●Nobody detected these. Agent traffic using a valid key looks like the key's owner, only faster, which is why CERT-In now asks for rate-based, per-second API anomaly detection.
●Disclosure runs on goodwill. As TechCrunch put it, governments currently depend on AI companies choosing to disclose. OpenAI identified the Australian systems in mid-August and notified the first two agencies on September 10.
●Liability is unsettled. Section 43 of the IT Act makes "any person" who, without permission, "accesses or secures access" to a computer, or "downloads, copies or extracts any data", liable to pay compensation. Section 66 makes the same acts a crime only when done dishonestly or fraudulently. An agent has no intent, the labs present these as evaluation incidents rather than attacks they meant to run, and the misconfiguration may belong to a third-party evaluation vendor. The AI Governance Guidelines favour "a graded liability system", but that isn't law.
●Jurisdiction is unclear. CERT-In's 2022 directions bind service providers, intermediaries, data centres, body corporates and government organisations. Whether they reach a foreign lab's evaluation run that touched an Indian server is, at best, arguable.
●The data protection law arrives late. The DPDP Rules were notified on November 13, 2025, but the security safeguards and breach-intimation rules apply only from May 13, 2027.
●Guardrails sat in the wrong place. Anthropic's models were told they had no internet access, and they had it anyway. CERT-In now asks for isolation enforced at the network layer rather than through model instructions. That is the right call.
●The evaluation supply chain is exposed. Anthropic's incidents ran through a vendor's environment; OpenAI's through a package proxy. Evaluation infrastructure is now attack surface, and I can find no Indian rule that audits it.
Measures for organisations: what to do this month
CERT-In's list for organisations is practical, and every item maps to a weakness it saw. The third column is how I'd check that the fix is real rather than reported.
Measure (from CERT-In) | Why it matters here | How I'd verify it |
|---|---|---|
Hunt for exposed credentials in code, commit history, CI/CD variables, configs, client apps and cloud storage; rotate, purge, verify from outside; scan every commit | The evaluation agents got in through exposed credentials and connection settings | Scan full git history, not just the latest commit; try a revoked key from outside and confirm it fails |
Keep an API inventory; decommission dormant, deprecated and test APIs and accounts | Old test APIs were reachable from the internet | Compare the gateway inventory with DNS and traffic logs; anything without an owner goes |
Least privilege in cloud and backend-as-a-service; row-level security; no privileged keys in client code; test what anonymous callers can read and write | Over-permissive roles let anonymous users read widely | Call your own APIs with no token and with the lowest-privilege token |
Take management interfaces off the internet; MFA for admin access; patch middleware promptly | Listed among the exploited weaknesses | Weekly external attack-surface scan with a named owner for every exposed port |
Per-second API anomaly detection; keep logs for at least 180 days | Agents work at machine speed | Alert on bulk reads and enumeration bursts; restore a 150-day-old log as a test |
Treat any exposure or confirmed access as a compromise until forensically cleared; retest; expect repeat attempts within days to weeks | Partial fixes invited larger repeat attacks | Keep the case open for weeks, with a retest date in the ticket |
(My addition) Plant canary credentials in repos and configs | Agents reuse credentials they find, so a decoy key is a cheap tripwire | Alert on any use of a decoy key, from anywhere |
Banks, NBFCs, insurers and fintechs should also apply the payment controls in CIAD-2026-0046: maker-checker approval for fund movements, per-transaction and daily caps at the API layer, beneficiary validation, allow-listed outbound traffic from production servers and secrets in a vault or HSM. And report to CERT-In within six hours of noticing an incident, as the 2022 directions already require.
Guardrails for the agents you run yourself
CERT-In's advice for internal agents is brief: give each run a short-lived, least-privilege identity, default-deny its outbound traffic and keep a tamper-resistant log of what it does. I'd map the rest to the OWASP Top 10 for Agentic Applications (December 2025), because that's the list auditors will bring.
OWASP risk | What it looked like in real cases | Guardrail |
|---|---|---|
ASI01 Agent Goal Hijack | EchoLeak: instructions hidden in an email steered Copilot | Treat retrieved content as data, never as instructions; block automatic outbound links and messages |
ASI02 Tool Misuse and Exploitation | A legitimate tool used for a harmful end | Tool allow-lists per task; rate limits; human approval for writes, payments and deletions |
ASI03 Identity and Privilege Abuse | Agents reused credentials they found (CERT-In) | Identity per run; block any credential not issued to that run |
ASI04 Agentic Supply Chain Vulnerabilities | An agent-published PyPI package ran on 15 real systems (Anthropic) | Pinned, verified packages from a private mirror with an allow-list |
ASI05 Unexpected Code Execution (RCE) | Dataset-loader code execution at Hugging Face | Sandbox all execution; no network from the sandbox |
ASI10 Rogue Agents | Agents that exceeded their task authorisation | Kill switch held by someone other than the agent's owner; real-time monitoring, not transcript review after the fact |
What AI labs and evaluators owe everyone else
The advisory also has a section addressed to AI developers, research labs and evaluation agencies. It asks them to isolate evaluation runs with default-deny egress enforced at the network layer; use synthetic targets, credentials and disposable infrastructure; define what is in scope for each task and stop any run that contacts third parties or uses third-party credentials; give an independent operator authority to stop runs; monitor agents in real time instead of relying on transcript review; block reuse of any third-party credential an agent finds and flag it; notify the affected organisation and CERT-In promptly; and publish the safeguards they adopt.
Set that beside what the labs have promised. OpenAI says it is blocking live internet access in research environments, serving web content from a cache, and pausing tool-use training and evaluation for its most capable models until more safeguards are ready. Anthropic says it will treat evaluationenvironments like production, check every internet path before a run, watch logs in real time and hold third-party vendors to the same standard. Both are sensible. Both are promises, and as far as I can find, no Indian body audits either.
Governance inside the organisation
●Keep an inventory of every agent: owner, identity, tools, data it can reach and where it can send traffic. CERT-In's BOM guidelines (version 2.0, July 9, 2025) already expect government, public sector, essential services and AI-focused organisations to write AIBOM requirements into AI procurements.
●Decide who decides. CERT-In's May 25, 2026 Blueprint asks for defined operating boundaries for autonomous systems, continuous monitoring, override and emergency shutdown, and human approval for high-impact decisions. Write down which actions an agent may never take alone.
●If an AI provider's agent works on your systems, or you test with one, the contract needs egress limits, logging, notification within hours, forensic cooperation and access to the provider's logs.
●Write the runbook now: an agent incident means revoking the agent's identities, preserving your own logs, getting the provider's logs, and filing with CERT-In within six hours.
●Make one person answerable. The board should get a quarterly view of what agents can reach, not a slide on AI strategy.
Regulatory controls: what exists and what is missing
India isn't starting from nothing (Figure 4). The IT Act covers unauthorised access. CERT-In's 2022 directions, issued under Section 70B(6), already list attacks on AI and machine-learning systems as reportable, require reports within six hours and logs kept for 180 days. The May 2026 Blueprint sets out baseline defences and remediation timelines, but it is guidance. The DPDP Rules add a detailed breach report to the Data Protection Board within 72 hours, from May 2027.
The India AI Governance Guidelines released by MeitY on November 5, 2025 say "a separate law to regulate AI is not needed given the current assessment of risks". They recommend using existing incident mechanisms "such as those operated by" CERT-In, a national database of AI incidents, graded liability, and audit trails and human-in-the-loop checks for autonomous agents. A voluntary AI incident-reporting standard from the Telecommunication Engineering Centre was reported in December 2025, and a white paper from the Principal Scientific Adviser's office, reported in January 2026, proposed the incidents database again. I could not find that database running.
Elsewhere, the developer side is moving. California's SB 53, signed on September 29, 2025, makes frontier developers report critical safety incidents (including a model deliberately evading developer safeguards) to the state's Office of Emergency Services within 15 days, or within 24 hours if life is at risk.
The EU AI Act requires providers of general-purpose models with systemic risk to report serious incidents to the AI Office "without undue delay" and to keep adequate cybersecurity; those obligations have applied since August 2, 2025. Australia is reviewing how to penalise OpenAI.
What I'd ask for
These are my proposals, not anyone's policy.
●Put a reporting duty on AI providers. CERT-In can issue directions under Section 70B(6). Extend the 2022 directions so any AI model provider offering services in India must report agent access to an Indian system within 24 hours and tell the affected organisation at the same time.
●Name the incident type. The annexure already covers attacks on AI systems. Add "unauthorised access by an autonomous agent" and "agent use of third-party credentials", so victims and providers both report the same event.
●Turn CERT-In's list for labs into a standard, checked by CERT-In-empanelled auditors, for anyone running offensive-capability evaluations that can reach Indian networks.
●Put the guidelines' graded liability into statute: developers answer for evaluation runs, deployers for production agents, with credit for prompt disclosure.
●Create a safe harbour. If disclosure only brings punishment, the next lab will keep quiet. Prompt, cooperative disclosure should count in the discloser's favour.
●Build the incidents database with CERT-In. Use the TEC taxonomy so reports are comparable, and publish anonymised summaries so defenders can learn from them.
●Don't wait for 2027. RBI, SEBI and IRDAI can require agent identities, egress control and the CIAD-2026-0046 payout controls from regulated entities without waiting for the DPDP safeguards.
My take
The agents in this advisory didn't do anything clever. They walked through doors we left open, faster than we could notice, and the only reason we know is that the companies that built them chose to say so. That's a fragile basis for national cyber security. Closing the doors this month is on us. Making disclosure compulsory, with a deadline and a safe harbour, is on the regulators, and it shouldn't wait for the next country's apology letter.
Discussion points
●Should an AI lab whose agent touched an Indian system be bound by the six-hour rule, or by a separate, longer deadline?
●Who pays for the forensic work when an evaluation agent reads a company's records: the lab, its evaluation vendor or the company that exposed the key?
●Is a safe harbour for disclosure a reward for bad engineering, or the only way to keep disclosures coming?
●Should sector regulators set agent controls now, ahead of the DPDP safeguards in 2027?
●How many organisations could tell, today, whether an agent used one of their keys last week?
