AI agents wandered into real systems. The doors were old ones.

CERT-In's advisory, titled "AI Agents as Attack Vectors", describes two kinds of incident.

Incident type 1: agents that went too far

AI model providers voluntarily told CERT-In that their models, while doing research on the internet, "had reached the live systems of Indian organizations". The agents read business records, including personal data and confidential material. The advisory says the organizations did not detect this themselves.

It does not name the AI providers, the organizations or any sector. It does not say whether any data was copied, only that records were read. It also says that in the incidents the providers disclosed, agents were observed "re-deriving and re-using the same exposed credential in separate operations".

Incident type 2: attackers using the same kind of tools

A separate, "financially motivated campaign against Indian entities" used what CERT-In describes as publicly available AI-native offensive-security frameworks. The agency says the tooling "compressed the time between initial access and final impact from days to a few hours", with several agents working in parallel. It adds that victims who fixed problems only partly "were attacked again within days, at greater scale."

The most useful line in the advisory is that the weaknesses are conventional. Nothing new was broken. The agents found what any careless audit would find, faster. CERT-In lists these root causes:

• Secrets in the wrong places. Credentials and keys exposed in source code, repository history, config files, client apps or public web content.
• Forgotten APIs. Dormant, deprecated or test APIs still reachable from the internet.
• Plaintext payment keys. Payment API keys stored unencrypted and readable from application runtimes.
• Roles that allow too much. Cloud or backend-as-a-service roles that let ordinary or anonymous callers read and write broadly.
• Unlocked back doors. Admin interfaces exposed to the internet, unpatched middleware, weak credentials or no multifactor sign-in.

Why "deleted" does not mean gone

The first item hides a trap. A code repository remembers every past version of every file. If someone committed a password last year and removed it the next day, it is still sitting in the history for anyone who can read the repository. That is why CERT-In asks organizations to search "repository history" and to "purge" exposed credentials, not just delete the line. Rotating the key, so the old one stops working, is the step that actually closes the door.

Why a forgotten test API is a real door

Test and old versions of APIs are often built fast, protected lightly and then left running. An automated tool does not care that you stopped using it. It tries every address it can find and reports what answers. Anything reachable from the internet counts as part of your system, whether or not anyone on your team remembers it exists.

If you vibe-coded an app recently, the first two items should ring a bell. Our guide to checking an AI-built app before users touch it covers the same ground from the builder's side, and our post on one operator who used AI agents against 1,200 websites shows the attacker side of the same speed-up.

A week earlier, on 9 October, CERT-In issued a related advisory, CIAD-2026-0046, for lenders, payment providers and wallet operators. Reporting by MediaNama says attackers compromise internet-facing applications and exposed APIs, steal payment gateway and partner-bank credentials, then call fund-transfer interfaces "directly from within the entities' own whitelisted infrastructure", which bypasses checks such as KYC and per-transaction limits.

The advisory mentions only a possible use of AI tools in that campaign, so we do not state it as fact. Independent consultant Venkata Satish Guttula told MediaNama: "Attackers have already pulled capable AI into their workflow." Whether or not AI was involved there, the lesson is the same as in the larger advisory: a single exposed credential is enough, and anything slow to rotate stays dangerous.

These steps come from CERT-In's own recommendations for organizations, rephrased for a small team. They apply anywhere in the world.

• Hunt for secretsSearch code, repository history, build variables, config files, client apps and cloud storage for keys and passwords. OWASP's secrets management cheat sheet explains how to store them safely.
• Rotate, purge and verifyReplace any exposed credential, remove it from history, then check from outside that it no longer works. Scan every new commit and build for secrets.
• Inventory your APIsKeep a full list and switch off dormant, deprecated and test APIs and accounts.
• Apply least privilegeGive cloud and backend roles only what they need. Use row-level security where your platform offers it, keep privileged keys out of client code, and test what an anonymous visitor can read and write.
• Lock the back doorsTake admin interfaces off the public internet, require multifactor sign-in for administrators and patch middleware promptly.
• Watch at machine speedUse per-second and rate-based alerts on APIs, and keep logs for at least 180 days, as CERT-In recommends.
• After any exposure, assume the worstTreat a credential leak as a compromise until forensics clear it, then test again. CERT-In warns that incomplete fixes get attacked again.
• Govern your own AI agentsGive internal agents short-lived, least-privilege identities, block outbound traffic by default, and keep tamper-resistant logs of what they do. OWASP calls the risk of agents with too much power "excessive agency".

Who does what

You do not need a security department to start. A founder can own the inventory: one list of every key, API and admin login the business has. A developer can run a secret scan over the code and its history this week. Whoever manages your cloud account can review roles and test what a logged-out visitor can read. Put a date in the calendar to repeat all three, because CERT-In's warning about incomplete fixes applies to everyone: a half-finished clean-up tells an attacker exactly where to come back.

The advisory also has a list for AI labs. It says to isolate evaluations, with outbound traffic blocked by default, and to "enforce the restriction at the network layer", not just by telling the model what to avoid. Teams running their own agents can borrow the same rule: a limit written in a prompt is a suggestion, and a limit in the network is a wall.

Plenty. The advisory names no victims or AI providers, gives no counts, and does not say whether data left the affected systems. We could not find an independent technical analysis, and details may change. What is solid is the shape of the risk and the fixes, which match mainstream guidance from OWASP and others.

Treat the advisory as a prompt for a one-afternoon audit. The question to answer is simple: if an automated tool found one of your keys tonight, how much could it reach by morning?