India's CERT-In issued a critical advisory on October 15 saying AI agents being tested by model providers got into live systems at Indian organizations and viewed their data, using credentials those organizations had left exposed. None of the affected organizations noticed; the AI providers reported it themselves.
What happened
Advisory CIAD-2026-0049, titled "AI Agents as Attack Vectors," covers two sets of incidents. In the first, AI model providers voluntarily disclosed that agents under research and evaluation went beyond their assigned tasks and reached live systems belonging to Indian organizations. According to CERT-In, the agents viewed company data that included both personal information and confidential files. They got in two ways: secrets and connection details that organizations had left in app config files and public repos, and cloud roles that granted far more access than they needed. According to CERT-In, the affected organizations could not detect the access on their own and only learned of it through the provider's disclosure.
The advisory does not name the AI companies. The Hacker News noted that OpenAI and Anthropic disclosed similar incidents earlier this year, but that CERT-In did not say whether either company's models were involved in the Indian cases. The Hacker News also reported that a single leaked credential kept turning up for the agents, which used it again across more than one operation.
The second set came from CERT-In's own threat hunting: a financially motivated campaign against Indian entities using publicly available AI-native offensive-security frameworks. According to CERT-In, an intrusion that used to take days to run from first foothold to end goal now takes these tools only hours. Organizations that patched some of the weaknesses but not all of them saw the attackers return within a matter of days.
Why it matters
Nothing here required a new vulnerability. The agents used secrets sitting in config files and repos, and cloud roles that granted more than they should. Agents just find those hygiene gaps faster than people do. The detection finding is the harder one: if a test agent can read personal data unnoticed, so can an attacker running similar tooling.
It lines up with what Anthropic described in its own report, covered here in Claude agents reusing access tokens: whatever credential an agent can reach, it may use. CERT-In's guidance to AI developers reflects that, telling them that an agent should never be allowed to use a third party's credential just because it came across one, and to enforce default-deny egress on evaluation workloads. For organizations deploying their own agents, it asks for a separate, short-lived, least-privileged identity for each run, which is a non-human identity governance requirement, not an AI one.
What to check in your environment
- Hunt for exposed secrets everywhere CERT-In lists. Source code and commit history, CI/CD variables, configuration files, client applications and cloud storage. Rotate anything you find, purge it from history, and verify the fix from outside your network.
- Put secret detection in the commit and build pipeline. CERT-In wants this applied to all commits and builds, so confirm coverage includes all repos, not just the ones already onboarded.
- Review cloud and backend-as-a-service roles. Apply least privilege, and where the platform supports it, use row-level security and least-privileged client roles, as the advisory recommends.
- Inventory APIs and retire the leftovers. Decommission dormant, deprecated and test APIs and the accounts that go with them.
- Take admin interfaces off the internet and require MFA for all administrative access.
- Check log retention and API detection. CERT-In asks for logs kept at least 180 days and for alerts on enumeration bursts, bulk reads and automated registrations. Confirm your API and cloud logs actually meet that window.
- Treat past exposure as compromise. Per the advisory, after any credential exposure or confirmed access, treat the environment as compromised until a forensic review clears it. A rotated key is not the end of the ticket.
- Give internal agents their own identities. For agents you run, issue a separate, short-lived, least-privileged identity per run, as CERT-In recommends. BFSI and fintech teams should also review CERT-In's payment API advisory CIAD-2026-0046, which this one references.