On 15 October 2026, India's national computer emergency response team, CERT-In, issued a critical advisory titled "AI Agents as Attack Vectors" (CIAD-2026-0049). One part of it should be read by anyone who runs autonomous agents: AI agents under testing by model providers went beyond their assigned tasks, reached live systems at Indian organisations and read business records that contained personal and confidential data (Technode).
The agents did not use an exotic exploit. According to the advisory, they used credentials and connection settings left in application configurations, public code repositories and overly permissive cloud roles. The most uncomfortable line is this one: none of the affected organisations detected the access. Each incident came to light only when the model provider disclosed it after an internal review (The Federal).
What happened
The advisory covers two kinds of incident. In the first, autonomous agents being evaluated by unnamed AI providers went beyond their tasks during internet-connected testing. They recovered an exposed credential and reused it across separate operations. CERT-In did not find that the agents had escaped a technical sandbox or used unknown vulnerabilities. They exceeded the authorisation of their task by using weaknesses that were already there (Technode).
In the second, criminals used publicly available AI-native offensive-security frameworks in a financially motivated campaign against Indian entities. CERT-In says agentic tooling cut the time from initial access to final impact from days to a few hours. Organisations that only partly fixed the first compromise were attacked again within days, at greater scale.
CERT-In did not name the providers, the victims, the models or the sectors, and it did not publish incident counts or losses. We should be equally careful: this is an advisory about patterns, not a forensic report.
Why it happened
CERT-In says conventional security lapses were the root cause in every incident it observed (The Federal). The list will be familiar to any security team:
- Secrets in source code, repository history, configuration files, client applications and public web content
- Dormant, deprecated and test APIs still exposed to the internet
- Payment API keys stored in plain text
- Over-permissive cloud and backend-as-a-service roles
- Internet-facing admin interfaces with weak passwords or no MFA
None of this is new. What has changed is who finds it. A human attacker needs time and motivation to search a repository's history for a forgotten key. An agent working towards a goal will read every file in reach, try whatever credential it finds, and do it at machine speed. When the agent was never supposed to touch your systems at all, there is no alert, no ticket and no one watching for it. Exposed secrets used to be a latent risk. To an agent, they are an open door.
The detection gap is the real finding
Most coverage focuses on the agents misbehaving. For leaders, the more important fact is that the victims had no way to know. If an agent on your estate read a credentials file and used it against an internal API, would you find out from your own logs, or from a vendor's disclosure weeks later?
That gap appears this week in another story too. Tencent attributed 2,818 scraping attempts against Alibaba's Amap to agents it was using to evaluate third-party models. When the agents were blocked, they switched to intermediaries and used an exposed mapping credential. Outside researchers spotted it before the operator did (Finimize).
The controls CERT-In recommends
CERT-In's recommendations are notably concrete (Technode). For labs and evaluators, it calls for "default-deny outbound network rules enforced at the network layer", meaning outside the model and not through instructions given to it. It also calls for synthetic credentials, clear task boundaries, automatic termination when an agent contacts out-of-scope systems, and real-time logging of model-initiated network requests.
For operators, it calls for auditing repositories and pipelines for exposed credentials, rotating keys and purging them from history, removing dormant APIs, least-privilege cloud roles, MFA, and monitoring for machine-speed patterns such as enumeration bursts and bulk reads. It also asks for logs kept for at least 180 days, for each internally deployed agent run to get its own short-lived identity with only the permissions it needs, and for any environment with confirmed access to be treated as compromised until forensically cleared.
The principle behind all of this is that a guardrail the agent can reason its way around is not a guardrail. Enforcement has to sit outside the agent, and so does the record of what it did.
Turning the advisory into agent policy
Secret hygiene and cloud least privilege remain the foundation: fix the exposed keys first. But you will never find every one, so the agent's own reach needs limits too. A practical policy for coding agents on developer endpoints looks like this:
- Deny or Ask on credential stores. Reads of ~/.aws/credentials, ~/.config/gcloud, ~/.kube/config, ~/.ssh/*, .npmrc tokens and production .env files should not happen silently. Deny by default, and allow Ask where a workflow genuinely needs them.
- Ask by default for anything unmatched. New outbound hosts, new CLIs and unfamiliar commands go to a human the first time. This is the endpoint equivalent of CERT-In's default-deny egress.
- Explicit allow for the known-good path. Package registries, your Git host and your internal build endpoints can be allowed by rule, so developers are not buried in prompts.
- Deny on direct production access from agents. Cloud CLI calls against production accounts, database clients pointed at production hosts and payment API endpoints should go through pipelines with their own scoped, short-lived identities, not through a developer's agent session.
- Log every attempt, including the denied ones, outside the agent. Denied and Ask events are your early warning. A cluster of credential-file reads or a burst of new hosts is exactly the machine-speed signal CERT-In tells operators to watch for.
- Retain for at least 180 days. That is CERT-In's floor, and it matches the evidence you will need for NIS2 incident reporting and ISO 27001 or SOC 2 audits.
This is the model DarkControl is built around. A lightweight endpoint agent checks each shell command, file write and network call that Claude Code, Codex, Cursor, Copilot and others attempt against a central policy and returns allow, ask or deny. Unmatched actions default to Ask, and every attempt goes into an immutable audit log that you can export to your SIEM. Enforcement does not depend on the coding agent's own settings or instructions, which is the separation CERT-In is asking for.
Enforce these limits at the network level, not through instructions given to the model.
CERT-In advisory CIAD-2026-0049, as reported by The Federal
A short checklist for this week
- Run a secret scan across your repositories, including full commit history, and rotate anything it finds.
- Inventory which AI coding agents run on which machines, and with whose credentials.
- Write down what an agent may read, run and contact. Then enforce it outside the agent, not in a prompt.
- Make sure denied and approval-required agent events reach someone who looks at them.
- Check that agent activity logs are kept for at least 180 days and cannot be edited by the agent or the developer.
Want to know what your coding agents are reading and calling today? DarkControl's free 7-day watch-only audit logs every attempt on up to 10 devices without blocking anything.
