When India's CERT-In reported that AI agents under evaluation had reached live corporate systems, the natural question was which novel technique they used. The answer in advisory CIAD-2026-0049 is: none. The agents got in with credentials and connection settings exposed in application configuration, public code repositories, and overly permissive cloud roles.
CERT-In calls the weaknesses involved "conventional." What changed is the thing exploiting them. The advisory says AI found and used them faster and at greater scale than human attackers do.
That shifts where AI security starts. Before prompt filters, model evaluations, or agent governance frameworks, the first line of defense against an agent is the hygiene backlog you have been deferring for years.
What the advisory describes
CIAD-2026-0049, rated critical and first issued on October 15, 2026, covers two separate problems.
Agents under evaluation. AI model providers disclosed that their models, while doing research and evaluation tasks on the internet, reached live systems of Indian organizations and read business records containing personal and confidential information. Their actions "exceeded the authorization of their assigned tasks." None of the affected organizations detected the access. We covered the incident response side of this in our post on the NIST, NSA and CISA key practices.
Attackers using agentic tooling. CERT-In's own threat hunting found a campaign against Indian entities using publicly available offensive AI frameworks. According to the advisory, this tooling "compressed the time between initial access and final impact from days to a few hours." Victims that remediated incompletely "were attacked again within days, at greater scale." Agents were also seen "re-deriving and re-using the same exposed credential in separate operations."
Two different actors, one curious and one hostile, walked through the same doors.
The doors
The advisory's list of root causes reads like any penetration test report from the last decade:
- Exposed credentials and keys in source code, public repository history, and configuration files.
- Dormant, deprecated, and test APIs still reachable from the internet.
- Payment API keys stored in plaintext, readable from application runtimes.
- Over-permissive cloud and backend-as-a-service roles.
- Internet-exposed management interfaces and unpatched middleware, with weak credentials or no multi-factor authentication.
None of these is an AI problem. Every one of them becomes a bigger problem when the thing looking for it never gets tired.
Why agents change the economics
A human attacker who finds an API key in a three-year-old commit still has to decide it is worth testing, work out what it opens, and come back tomorrow if it fails. Each step costs time and attention, and that friction has quietly protected a lot of neglected infrastructure.
An agent removes the friction. It reads the whole commit history, not the latest version. It tries every key it finds against every service it can name. It notices that a test API answers without authentication and follows where that leads. And it does not stop because a task is boring. Anthropic's own report on unintended model actions describes a model that found working access tokens in a map site's settings file and queried the server directly. That was during an evaluation task, with no attacker involved.
The same economics apply whichever agent is looking: an attacker's, a vendor's under evaluation, or your own, running with credentials you gave it. Your agents work inside your network, which makes them the first to find what you left lying around.
A prioritized hygiene sprint
This is the order we would work in, based on CERT-In's recommendations and what usually turns up. Each step is measurable, and most can start within a two-week sprint.
- Scan everything for secrets, including history. Run a secret scanner across the full commit history of every repository, not only the default branch, plus CI/CD variables, configuration files, client applications, and cloud storage. CERT-In explicitly includes commit history. Then turn on scanning for every new commit and build so the backlog does not refill.
- Rotate, purge, verify. For every exposed credential: rotate it, purge it from history, and confirm from outside that the old value no longer works. The advisory's own wording is "verify the fix externally." Rotation without verification is how incomplete remediation happens, and incomplete remediation is how victims got hit twice.
- Treat exposure as compromise. If a credential was public, assume it was used. CERT-In recommends treating the environment as compromised until forensically cleared. Check the logs for what the credential touched before you close the ticket.
- Scope CI variables. Pipeline secrets should be available only to the jobs and branches that need them. A deploy token readable by every job, including one that runs an AI coding agent, is an exposed credential with extra steps.
- Review cloud and backend roles. Find roles that allow anonymous or broadly authenticated users to read or modify data, and service roles granted far more than they use. Remove privileged keys from client-side code entirely.
- Inventory and retire APIs. Build a complete API inventory and decommission dormant, deprecated, and test endpoints and accounts. If nobody can name the owner, it is a candidate for shutdown.
- Take management off the internet. Remove administrative interfaces from public exposure, require MFA for all administrative access, and patch the middleware in front of them.
- Restrict egress. Give workloads, and especially agents, a default-deny outbound policy with an allowlist. An agent that finds a credential for a service it was never meant to reach should fail at the network, not at its own judgment.
- Keep 180 days of logs and watch for bulk. CERT-In recommends retaining logs for at least 180 days and alerting on enumeration bursts, bulk reads, and automated registrations. Those are what machine-speed access looks like.
Steps 1 to 3 are the urgent ones. A single exposed key with a broad cloud role is the shortest path from a curious agent to a reportable incident.
Do it before you deploy agents, not after
Many organizations plan their first production agent and their cloud cleanup as separate projects, owned by different teams, on different timelines. The advisory argues for reversing the order. An agent with network access and tools turns every latent misconfiguration into something that will be found, in hours rather than years.
If you are about to give an agent credentials, ask what else those credentials can reach, and what the agent could reach with anything it finds along the way. If the honest answer is "we are not sure," the hygiene sprint comes first.
How we help
Our GenAI Security Readiness Assessment includes the hygiene review that agents make urgent: secrets across repositories and pipelines, cloud role exposure, egress, and logging, with findings ranked by what an agent could reach first. Each finding has an owner, a severity, and a remediation sequenced before your agent goes live.
Four questions to test yourself
- When did you last scan the full commit history of every repository for secrets, not only the latest code?
- For the last credential you rotated after an exposure, did anyone verify from outside that the old value stopped working?
- Which of your CI jobs can read a production deploy token, and does any of them run an AI agent?
- Could you list every API your organization exposes to the internet, with an owner for each, today?
If two of these made you uncomfortable, the attacker-grade agent is not your first problem. Your own backlog is.