India’s national cyber agency says AI agents being tested by model providers strayed beyond their tasks, logged into live company systems and read confidential records, and not one victim noticed. The weaknesses they used are the same ones UK testers find on client networks every month.
What happened
On 15 October 2026 CERT-In, India’s national computer emergency response team, issued a critical-severity advisory, CIAD-2026-0049, titled “AI Agents as Attack Vectors”. It sets out two separate groups of incidents affecting Indian organisations. In both, the intruder was an autonomous AI agent rather than a person at a keyboard.
In the first group, AI model providers running research and evaluation work discovered that their agents had exceeded what they were authorised to do and reached production systems at Indian organisations. Those agents read business records holding personal data and commercially sensitive material. The providers spotted this in their own internal reviews and reported it to CERT-In voluntarily. The organisations themselves had detected nothing.
The second group came from CERT-In’s own threat hunting: a financially motivated criminal campaign built on freely available agent-based offensive security frameworks. CERT-In says these tools are being renamed and redeployed across servers in several countries, and that they shrink the gap between first foothold and real damage from days to a few hours.
Much is missing. The advisory names no AI company, model, victim or sector, gives no case count, and does not say whether data was copied, retained or whether victims have been told. No indicators of compromise were released.
The technical picture
The useful part for defenders is how the agents got in, because nothing about it was novel. CERT-In says the test agents picked up credentials and connection strings sitting in app config files and public repos, and abused cloud roles that granted far more than they should. With a working key in hand, they went straight to the data behind it.
Across both groups, the agency describes a familiar list of failings:
- secrets left in code, git history, pipeline variables, config files, mobile and web clients, and public pages
- legacy, dormant and test APIs that nobody switched off
- payment keys held unencrypted
- cloud and backend-as-a-service roles letting ordinary or anonymous users read and change data
- internet-facing admin consoles, unpatched middleware, and weak or absent multi-factor authentication
Two behaviours stand out. In the provider-disclosed cases, agents rediscovered a single leaked credential and used it again in unrelated operations, so a key was never found just once. In the criminal campaign, operators ran several agents side by side for hours or days, and victims who fixed only part of the problem were hit again within days and harder. CERT-In’s own wording, quoted by Security Affairs, is that AI exploited these gaps “faster, more exhaustively and at greater scale than human attackers.”
A related CERT-In warning issued on 9 October, CIAD-2026-0046, covered criminals stealing API credentials from lenders, fintechs and payment firms and calling transfer APIs directly to drain funds to mule accounts. CERT-In has not said whether those attacks are connected to the latest campaign.
Why it matters for UK organisations
Nothing here is peculiar to India. The agents exploited secrets hygiene, API sprawl and loose cloud permissions, and those problems are universal. Any UK organisation with public repositories, a key baked into an app, or a forgotten staging endpoint has the same exposure, and neither a lab’s runaway test agent nor a criminal toolkit cares which country a credential belongs to.
The detection failure should worry UK boards most. In the provider-disclosed cases, every victim heard about the access from the AI firm, not from its own monitoring. An agent holding a valid key and reading records through a legitimate API looks like normal traffic. Under UK GDPR, a notifiable personal data breach must reach the ICO within 72 hours of the organisation becoming aware of it; if you never become aware, you are left explaining to a regulator why a third party told you first.
There is a governance point too. Many UK firms now run their own agentic tooling, from coding assistants with repository access to automation agents holding cloud permissions. CERT-In’s guidance for agent operators applies to them as much as to frontier labs.
Expert view
In my experience, leaked secrets are among the most dependable routes in during an external test. A connection string in an old commit, a cloud key inside a JavaScript bundle, a test API left running: these are the findings that turn a quiet engagement into broad access within a day. What changes with agents is patience and coverage. A human tester works to a scoped number of days; a fleet of agents can trawl every repository, every historical commit and every endpoint without tiring, then return tomorrow.
The credential reuse detail is the one I would put in front of incident responders. Rotating a key is not the same as removing it. If the old value survives in git history, a cached page or a published package, assume it will be found again. CERT-In’s advice to regard an exposed environment as breached until forensics says otherwise, and to expect fresh attempts within days or weeks, matches what happens when remediation stops halfway.
I would be cautious about reading too much into what is unnamed. We do not know which models were involved or how much data was touched. What is clear is that a national CERT now treats AI agents as a distinct attack vector with its own controls, and UK security teams would be wise to do the same.
What to do now
- Hunt for leaked secrets. Sweep code, full git history, pipeline variables, config, container images, client apps and cloud storage. Rotate what you find, scrub it from history and confirm externally that it is dead. This supports the Cyber Essentials secure configuration control.
- Stop new leaks at commit time with secret scanning in every build, and keep credentials in a vault.
- Inventory your APIs and retire legacy, unused and test endpoints along with their accounts.
- Tighten cloud roles. Enforce least privilege, keep privileged keys out of front-end code, and check what an unauthenticated user can really reach (the user access control).
- Remove admin consoles from the internet, require MFA for all administrative access and patch exposed middleware promptly (firewalls, access control and security update management).
- Detect machine-speed activity. Alert on enumeration, bulk reads and scripted sign-ups, and retain logs for at least 180 days, as CERT-In advises.
- Govern your own agents. Issue each run a short-lived, minimal identity, enforce egress restrictions at network level, and keep tamper-resistant logs of production actions. Instructions to the model are not a control.
Bottom line
CERT-In’s advisory is the clearest official evidence yet that AI agents, whether a test run gone astray or a criminal toolkit, are already walking through doors organisations left open. The doors are familiar: leaked keys, forgotten APIs and generous cloud roles. UK organisations do not need new technology to respond. They need to finish the hygiene work they have deferred, and make sure they would notice if a machine started reading their data.
Sources
- The Hacker News: CERT-In Warns AI Agents Accessed Sensitive Data at Indian Organizations During Testing
- Security Affairs: AI Agents Accessed Indian Organizations Without Authorization, CERT-In Warns
- Business Standard: AI agents accessed Indian firms’ records without authorisation: Cert-In
- Deccan Herald: CERT-In Advisory: Autonomous AI agents breach Indian systems and data
