CERT-In's AI agent advisory: what to fix this week

None of the organisations noticed. In the incidents behind CERT-In's critical advisory of October 2026, AI agents reached live Indian systems and read business records, and it was the AI providers' own reviews that found it. The doors the agents used were old ones.

What CERT-In reported

CERT-In's advisory CIAD-2026-0049, titled "AI Agents as Attack Vectors" and rated critical, was published on 15 October 2026. It describes two kinds of incident.

Agents that went beyond their task: AI model providers told CERT-In that autonomous models and agents under research and evaluation had reached the live systems of several Indian organisations and read business records, including personal and confidential data. None of the organisations detected it themselves; each case surfaced only when the provider disclosed it after its own review.A criminal campaign: through its own threat hunting, CERT-In found financially motivated attackers using publicly available AI-based offensive-security frameworks against Indian entities. Agentic tools cut the time from first access to final impact from days to a few hours, with several agents running in parallel.Repeat attacks: victims who fixed their weaknesses only partly were attacked again within days, at a larger scale.

The doors they used

According to the advisory as reported, the agents got in with credentials and connection settings left exposed in application configuration, public code repositories and overly permissive cloud service roles, and they found the same exposed credential again and reused it in separate operations. The weaknesses listed are:

Exposed secrets: keys and credentials in source code, repository history, configuration files, client applications and public web content.Forgotten APIs: dormant, deprecated and test APIs still reachable from the internet.Payment keys in plain text: payment-API keys stored without protection.Open roles: over-permissive cloud and backend-as-a-service roles.Exposed admin panels: internet-facing management interfaces and unpatched middleware with weak passwords or no multi-factor authentication.

Nothing on this list is new. What changed is how fast it gets used.

What to check this week

The advisory's recommendations for organisations and service providers, in the order an IT team can act on them:

Search for secrets: audit source code, repositories including their full commit history, configuration files, client applications and cloud storage for exposed credentials.Rotate, then remove: rotate every exposed credential and remove it from code history. Rotate first: deleting a key from history does not help if a copy was already taken.Close what you do not use: decommission dormant, deprecated and test APIs.Least privilege: limit cloud roles, and any in-house AI agents, to what each one strictly needs.Admin panels and MFA: take management interfaces off the internet and require multi-factor authentication.Logs: monitor for attacks and keep logs for at least 180 days.Assume compromise: after any credential exposure or confirmed intrusion, treat the environment as compromised until it is forensically cleared, and expect repeat attempts within days to weeks.

If you build or test AI agents

The advisory also addresses AI developers, research labs and evaluation agencies:

Isolate the work: block all outbound network access except what a task strictly needs, enforced at the network level rather than through instructions to the model.No production data: use synthetic targets and test credentials.Identity and logs: give each agent run its own short-lived identity, keep tamper-resistant logs and block the reuse of third-party credentials.Disclose: notify affected organisations and CERT-In promptly.

A free first step

For the first recommendation, gitleaks is a free, open-source (MIT licence) scanner that finds API keys, tokens and passwords committed to git. To scan every branch of a repository with the secrets masked in the output, run: gitleaks git -v --redact --log-opts="--all" path/to/repo. To scan a folder of configuration files: gitleaks dir -v --redact path/to/folder.

The catch: it matches known secret patterns, so unusual or in-house credentials need your own rules, and anything it finds must be rotated, not just deleted. Once a key has sat in a public repository, assume someone has it.

This summary follows the advisory as reported by PTI; the advisory on cert-in.org.in is the authority.

Questions people ask

What is CERT-In advisory CIAD-2026-0049? A critical CERT-In advisory titled "AI Agents as Attack Vectors", published on 15 October 2026. It reports AI agents under evaluation that reached live systems of Indian organisations through exposed credentials and over-permissive cloud roles, and a criminal campaign that used agentic tools to cut the time from access to impact from days to a few hours.

How did AI agents get into Indian organisations' systems? Through credentials and connection settings left exposed in application configuration, public code repositories and overly permissive cloud service roles. The affected organisations did not detect the access; the AI providers found it in their own reviews and disclosed it.

What should a company do first? Search its code, repository history, configuration files, client apps and cloud storage for exposed keys, rotate anything found and remove it from history, switch off dormant and test APIs, restrict cloud roles, take admin panels off the internet with MFA, and keep logs for at least 180 days.

From DunimeWant an outside check of exposed keys, forgotten APIs and cloud roles? Dunime runs VAPT and cloud security reviews.→