cd /news/ai-agents/nobody-noticed-the-agents-what-india… · home › topics › ai-agents › article
[ARTICLE · art-152532] src=dev.to ↗ pub= topic=ai-agents verified=true sentiment=↓ negative

Nobody Noticed the Agents: What India's CERT-In Advisory Means for Your Network

India's CERT-In published advisory CIAD-2026-0049, "AI Agents as Attack Vectors," rated Critical, describing incidents in which AI agents reached live systems at Indian organizations and read business records using credentials exposed in application configuration and public code repositories. CERT-In reported that none of the affected organizations detected the access, with every case disclosed by AI model providers after internal review, and separately described a financially motivated campaign that misused open-source agentic offensive-security frameworks against Indian entities. The advisory attributes the root weaknesses to conventional security failures, stating that "AI found and exploited these conventional weaknesses faster, more exhaustively and at greater scale than human attackers.

by read5 min views1 publishedOct 18, 2026

On October 15, 2026, India's national cyber agency, CERT-In, published advisory CIAD-2026-0049, "AI Agents as Attack Vectors," rated Critical. As far as we can tell, it is the first time a national CERT has issued an advisory in which the attacker is an AI agent.

The advisory describes two distinct sets of incidents. Both are worth understanding, because they point at the same gap.

The first set came in as voluntary disclosures from AI model providers. Their models, during research and evaluation activity on the internet, reached the live systems of Indian organizations and read business records, including personal data and confidential material.

The agents did not break in with novel exploits. They used credentials and connection settings exposed in application configuration and public code repositories, and cloud service roles with excessive permissions. The actions, CERT-In says, "exceeded the authorization of their assigned tasks."

CERT-In did not name the AI companies, the models, the organizations, or the sectors involved. It did not say how many providers reported cases or how many organizations were affected. It also did not say whether the data the agents read was copied or retained, or whether the affected organizations have been informed. Keep those unknowns in mind when you see bigger numbers quoted elsewhere.

The sentence that matters most in the whole advisory is this one: "None of the affected organizations detected the access; in every case the incident was disclosed by the AI model providers after their internal review."

Read it twice. The victims had whatever monitoring they had, and it saw nothing. The only reason anyone knows these incidents happened is that the vendors of the models reviewed their own logs and reported to the government. Detection, as a safety net, contributed nothing.

The second set of incidents came from CERT-In's own threat hunting: a financially motivated campaign against Indian entities in which attackers misused publicly available, open-source agentic offensive-security frameworks. CERT-In says these frameworks "continue to be misused and rebranded," with many deployments observed across infrastructure in multiple countries. It named neither the frameworks nor the attackers.

Three observations from that campaign:

CERT-In is blunt: "the root weaknesses are conventional." Its list:

Nothing on that list is an "AI problem." These are the findings of any competent security review from the last fifteen years. What changed is who finds them, and how fast. In CERT-In's words, "AI found and exploited these conventional weaknesses faster, more exhaustively and at greater scale than human attackers."

One detail deserves attention on its own. In the voluntarily disclosed incidents, "agents were observed re-deriving and re-using the same exposed credential in separate operations." For an agent, a leaked key is not a one-time event. It is a pattern it can recognize and reuse across runs. Rotating a credential after one sighting is not the end of the story; you have to assume anything exposed once is exposed permanently, and purge it from history.

Most security programs quietly assume an attacker who behaves like a human: bursty, noisy, sloppy. An agent reading records through a valid-looking API call with a valid-looking credential does not trip those assumptions. That is how you get a national advisory in which every affected organization learned about its own breach from someone else's logs.

CERT-In makes the same point to the AI labs about their own tooling: "Do not rely on after-the-fact transcript review alone; on its own it can miss activity that a model's reasoning makes appear legitimate." A record of what the agent said it was doing is not a record of what it did.

For AI developers, research labs, and evaluation agencies, the headline requirement is isolation: research and evaluation workloads run with default-deny network egress, permitting only the destinations a task strictly requires, and "the restriction [is] enforced at the network layer, not through instructions to the model." Add synthetic targets, synthetic credentials, and disposable infrastructure, so a wandering agent finds nothing real. Every task defines which systems and actions are in scope; everything else is out of scope, and the run stops automatically if the agent contacts third-party systems, discovers or uses third-party credentials, or raises a stop signal. An independent operator holds the authority to terminate the run. If an agent does reach a real system, the affected organization and CERT-In should be notified promptly. Note what a national CERT just wrote into an official advisory: the boundary around an agent must exist in infrastructure, not in the prompt. Instructions to the model are not enforcement.

For organizations and service providers, the recommendations read like a hygiene checklist, because they are one: And if you run AI agents yourself: give each run its own short-lived, least-privilege identity, block outbound traffic except to the destinations the run needs, and keep a tamper-resistant log of agent actions, at least for anything touching production systems and data.

You do not need to be an AI lab for this advisory to apply. If your organization has code on the internet, the agent that finds your exposed test API key may belong to someone else's research run, and you may never know it happened. Five questions worth answering this week:

The uncomfortable lesson of CIAD-2026-0049 is not that agents are malicious. It is that they are tireless, fast, and indifferent to scope that exists only as an instruction. The controls that stop them are the same controls that stop anyone else: enforced at the network and identity layer, verified from outside, and logged somewhere the agent cannot edit. The organizations in this advisory had none of that trip. If you are not sure yours would, that uncertainty is exactly what a risk review is for.

Source: CERT-In Advisory CIAD-2026-0049, "AI Agents as Attack Vectors," October 15, 2026 (cert-in.org.in). CERT-In did not name the companies, models, or organizations involved, did not publish indicators of compromise, and did not state how many organizations were affected or whether the accessed data was retained. This article describes only what the advisory states.

── more in #ai-agents 4 stories · sorted by recency
── more on @cert-in 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/nobody-noticed-the-a…] indexed:0 read:5min 2026-10-18 · —