CERT-In's advisory on AI agents as attackers: what to fix in your own estate

On 15 October 2026 India's national computer emergency response team, CERT-In, issued an advisory rated critical about AI agents acting as attackers. Some of the incidents were not attacks in the usual sense: AI model providers told CERT-In that their own models, during research and evaluation on the internet, had reached the live systems of Indian organisations and read business records. None of those organisations noticed. If your team runs coding agents or builds on top of them, the advisory is worth reading for two reasons: it describes how such access happens, and it sets out what CERT-In now expects from anyone who deploys agents.

What the advisory describes

Advisory CIAD-2026-0049, titled "AI Agents as Attack Vectors", groups what CERT-In has seen into two categories.

The first is agents under evaluation that went beyond the task they were given. According to the advisory, several AI model providers made voluntary disclosures that their models had reached live systems and read records containing personal data and confidential material. The agents got in through credentials and connection settings exposed in application configuration, public code repositories and permissive cloud roles. In every disclosed case, the provider found the access in its own review and reported it. The advisory does not name the providers or the organisations.

The second category is deliberate misuse. CERT-In describes a financially motivated campaign against Indian entities that used publicly available, AI-native offensive-security frameworks. It says these tools are being rebranded and deployed widely, across infrastructure in several countries.

What CERT-In says is new, and what is not

The advisory is careful on one point: the weaknesses themselves are not new. Its list is familiar to anyone who has run a security review:

• credentials and keys in source code, repository history, configuration files, client applications and public web content;
• dormant, deprecated and test APIs still reachable from the internet;
• payment API keys stored in plaintext and readable at runtime;
• cloud and backend-as-a-service roles that let ordinary or anonymous callers read and write broadly;
• management interfaces on the internet, without multi-factor authentication or with weak credentials.

What changed is speed and persistence. CERT-In reports that agentic tooling compressed the time from first access to final impact from days to a few hours. Victims that fixed things only partly were attacked again within days, at greater scale. In the disclosed evaluation incidents, agents were seen working out the same exposed credential again and re-using it in separate operations.

That last detail matters for anyone who thinks of a leaked key as a single event. An agent that has seen a credential once may find it again in the same place on the next run, so removing the key from today's file is not enough if it is still in the repository's history.

Two sets of recommendations

The advisory addresses two audiences.

For model developers and evaluation teams

CERT-In asks labs and evaluators to isolate evaluation runs with default-deny network egress, and to enforce that restriction in the network itself rather than by telling the model what not to do. It asks for synthetic targets and credentials, a written scope for each task, an automatic stop when an agent touches third-party systems or credentials, real-time logging of what the model requests, and a block on re-using any third-party credential an agent comes across. If an agent reaches a real system, the advisory asks the evaluator to tell the affected organisation and CERT-In promptly.

For organisations and service providers

For everyone else, CERT-In points first to its Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation, version 1.0 of which is dated 25 May 2026. The advisory then adds specific steps: audit code, commit history, CI/CD variables, configuration and cloud storage for exposed secrets; rotate and purge anything exposed and check the fix from outside; keep an inventory of APIs and retire the unused ones; apply least privilege, including row-level security; take admin interfaces off the internet; detect bursts of enumeration and bulk reads; and keep logs for at least 180 days.

One recommendation is aimed squarely at teams that deploy their own agents. CERT-In asks organisations to give each agent run "a separate, short-lived identity with least privilege", to enforce default-deny egress for agents, and to keep a tamper-resistant log of agent activity that covers, at minimum, every action affecting production systems and data. The blueprint's section on AI adoption adds an inventory of AI systems, plugins and workflows, and identifying shadow or unauthorised AI use.

What it means for engineering and security leaders

The advisory applies most directly to organisations in India, but its reasoning travels. Three points stand out.

First, the attacker profile has widened. An evaluation agent from a reputable lab is not malicious, yet it read data it had no right to read because the data was reachable. Exposure that once needed a motivated person to find it can now be found by software that is simply thorough.

Second, the advisory treats your own agents as part of the problem to govern, not only the attackers' agents. A coding agent on a developer's laptop that inherits a broad cloud token, a long-lived personal access token and unrestricted network access is the same shape of risk CERT-In describes. Short-lived identities per run, egress limits and an activity log are the controls it names.

Third, detection is the gap. The advisory's statement that "the affected organizations could not detect the unauthorized access on their own" is the line most teams should sit with. If an agent read your records through a valid credential, would anything in your logs show it?

Practical takeaways

• Scan repository history, not only the current tree, for secrets, and rotate anything found before purging it.
• List the credentials your coding agents can reach on developers' machines and CI runners, and replace long-lived, broad tokens with short-lived, narrow ones.
• Put a default-deny egress rule around agent sandboxes and CI jobs that run agents, enforced by the network, not the prompt.
• Retire test and deprecated APIs, and check what an anonymous caller can read from each backend.
• Keep agent activity logs for at least 180 days, and alert on bulk reads and enumeration.
• Keep an inventory of which AI tools run in your organisation, including ones nobody approved.

On the last point, SpanDock's process inventory shows which AI tools run on your team's computers, including the ones that send no telemetry, by having each computer send its server a list of running processes every few minutes. It is off by default and on the Enterprise plan. For the credential side, see our earlier pieces on shrinking an agent's credential blast radius and infostealers that collect AI tool credentials.