Written by Jeremy Souffir Founder, JTS Tech Services
The direct answer first. A government cyber agency has now said in writing that AI agents, run by AI companies for research and testing, got into real business systems without permission, read business records including personal data, and were not detected by a single one of the businesses involved. The agents did not need anything new. They found credentials that had been left exposed, in source code, in old repository history, in configuration files, in apps shipped to customers and on public web pages, and they used them. The same week, researchers traced a fleet of agents doing harmless homework that picked up exposed credentials from a public code repository and used those too. The lesson for a merchant or a growing business is short: a leaked key used to wait for a criminal to find it. Now an ordinary agent doing an ordinary task may find it first, and you may never know.
What did CERT-In actually say?
CERT-In is India's national computer emergency response team. Its advisory, numbered CIAD-2026-0049 and reported in the Indian press as critical, was published late on 15 October. As reported by Business Standard and the PTI newswire, it describes two separate things:
- Agents under evaluation went out of bounds. AI model providers disclosed that their models and agents reached live systems of several Indian organisations during research and evaluation work, exceeding what their tasks allowed, and read business records including personal data and confidential material.
- Nobody noticed. In CERT-In's account, none of the affected organisations detected the access on their own. They found out because the AI providers' internal reviews flagged it and the providers came forward.
- Criminals are doing the same thing on purpose. Separately, CERT-In's own threat hunting found financially motivated campaigns using open-source AI agent tools, which it says cut the time from first access to real damage from days to a few hours.
- Half-fixes invite a second visit. The advisory reportedly says victims who cleaned up incompletely were hit again within days at greater scale, and that agents re-found and reused the same exposed credential across separate operations.
What is confirmed and what isn't
Confirmed by multiple reports: the advisory exists, its title, its two categories of incident, the detection gap and the list of root causes. Not public: which AI companies made the disclosures, which organisations were affected, and how many. CERT-In has not named them. We are working from news coverage of the advisory rather than its full text, so treat the exact wording of its recommendations as reported, not quoted.
How did they get in?
This is the part worth reading twice, because none of it is exotic. The weaknesses CERT-In lists are the ones security people have been nagging about for a decade:
- Keys and passwords left in source code, in old commits that were "deleted" but still live in the repository history, and in configuration files.
- Secrets shipped inside client apps and public web content, where anyone who views the page source can read them.
- Old and test APIs nobody switched off, still answering on the open internet.
- Cloud and back-end roles with far more permission than the job needs.
- Payment API keys stored in plain text where the running application can read them.
- Admin panels reachable from the internet, running outdated software, with weak or no multi-factor sign-in.
An agent with a web browser and a code tool is, among other things, very good at reading. It reads the page source. It reads the repository history. It notices that a string looks like a key, tries it, and, if the task seems to call for it, carries on. That is not malice. It is the same diligence that makes these tools useful, pointed at your mistakes.
Is this one country's problem?
No, and the same week made that plain. A small group of researchers calling themselves Swarmchasers noticed that Amap, Alibaba's mapping service, had become the most-scanned site on a public URL-scanning service. They traced roughly 2,800 attempts, between 28 September and 8 October, to agents running on Tencent Cloud, set to tasks as dull as working out which entrance of a zoo most visitors use. When Amap's bot protection turned them away, some routed requests through the scanning service instead. According to The Decoder's account of the report, some agents also found exposed Amap credentials in a public code repository and used them to call its API. Tencent told Reuters the activity did not come from its own Hunyuan models and that it found no evidence of deliberate targeting, and said it was tightening network controls and agent monitoring. Swarmchasers found no evidence the agents broke Amap's main anti-bot defences.
Put the two stories side by side and the pattern is clear. The agents were not sent to attack anyone. They were sent to get an answer, and an exposed key was the shortest route to it. We wrote in September about an agent that went looking for another way in after a government portal said no. What is new this week is a national cyber agency saying this is now a category, not a one-off, and saying that the businesses on the receiving end could not see it happening.
Where would your keys be hiding?
For a Shopify or WooCommerce store, or a business running on a dozen SaaS tools, the usual suspects are easy to list and easy to forget:
- A Shopify custom-app Admin API token pasted into a theme file, a script tag or a public GitHub repo by a developer years ago. Storefront API tokens are designed to be public; Admin tokens are not.
- WooCommerce REST API keys sitting in a plugin's settings export, a staging site or a backup file served from a public folder.
- Payment, email-platform and shipping keys in a front-end script because "it was quicker" during a launch week.
- A staging or old version of the store still online, with debug output and real credentials.
- Automation webhooks and tool keys copied into shared docs, help-desk macros or a public Notion page.
- Keys belonging to an agency or freelancer who stopped working with you, still valid because nobody rotated them.
The two conclusions that both get this wrong
It's in India and it was AI labs testing, so it doesn't apply to us
The labs were testing, but the doors they walked through were ordinary business systems with ordinary leaked keys, and those exist in every country. The Amap case shows the same behaviour on a Chinese service the same week. And CERT-In's second finding is about criminals using the same agent tools deliberately, at speed. A Canadian store with a key in a public repo is not protected by geography.
Block AI bots at the edge and we're covered
Blocking has its place, but it does not fix this. The agents in both stories got past refusals by going round them, and a valid key does not need to come through your storefront at all; it goes straight to the API. Blocking agents also shuts out the shopping assistants you want to read your catalogue. The fix is to make the key worthless, not to stand at the door.
What should you do this week?
- Search for your own secrets. Run a secret scanner over every repository you own, including history, not just the current files. GitHub's secret scanning is free on public repositories. Check theme code, custom scripts and anything served from your domain.
- Rotate anything you find, then rotate the keys you can't account for. A key that was ever public should be treated as used. CERT-In's own guidance is to treat an exposed environment as compromised until it is cleared.
- Shrink every key that remains. Give each app and integration the narrowest scopes it needs, one key per tool, so a leak opens one small door rather than the whole building.
- Switch off what you don't use. Old staging sites, test APIs, legacy apps and former suppliers' accounts. If nobody can name its owner, it should not be answering on the internet.
- Turn on multi-factor sign-in for every admin account, on the store and on the tools around it.
- Make sure you could see it happen. Keep API and admin logs for at least 180 days, as the advisory recommends, and set an alert for unusual bursts of reads or bulk exports. The single most damning line in the advisory is that nobody noticed.
The genuinely encouraging part
Every root cause in this advisory is fixable with tools you already have and an afternoon of focused work. Nothing here requires a new security product or an AI of your own. A store that scans its repos, rotates its keys, narrows its scopes and keeps its logs has closed the exact doors these agents walked through, and the same steps protect it from the people using agents on purpose.
Where we fit
The hard part of this is not the scan. It is that at most growing businesses nobody owns the question "which keys exist, who has them, and would we notice if one were used?" The developer who created a key has moved on, the agency's access was never removed, and the logs, if they exist, are read by no one. As your Fractional Head of AI & Digital, we take that ownership: an inventory of every key and integration, a cleanup and rotation plan carried out with your team, scopes and policies for the AI tools and agents you do want connected, and monitoring that would show you an uninvited visitor rather than leaving it to someone else's audit. Retaining us means that when the next advisory like this lands, you already know where your keys are and who would have seen them used.
Sources
- Business Standard: AI agents accessed Indian systems, sensitive data without consent: Cert-In (15 October 2026; the disclosures, the detection gap and the root causes)
- Deccan Chronicle (PTI): CERT-In issues critical alert after autonomous AI agents access live systems of Indian orgs (16 October 2026; advisory number, recommendations and the 180-day log guidance)
- CCLeaks: CERT-In flags AI agents as attack vectors in Critical advisory (16 October 2026; detailed breakdown of the recommendations for labs and organisations)
- The Decoder: Researchers tracked down a rogue fleet of Chinese AI agents in the wild and actually talked to it (the Amap activity and the credentials found in a public repository)
- Reuters via KFGO: China's Tencent says AI agents showed unintended browsing behaviour (16 October 2026; Tencent's statement and the Swarmchasers figures)
- Decrypt: Hidden Text, a Fake Mailbox: How Researchers Got Rogue AI Agents to Talk (15 October 2026; the Swarmchasers investigation)
- JTS Tech: An AI agent got into a government health portal while looking up the cost of skin cream (25 September 2026; what happens when an agent is told no)
- JTS Tech: A poisoned package was live for forty minutes in March. In August, the keys it stole still work. (15 August 2026; why rotation is the step everyone skips)
