CERT-In: AI Agents Under Test Reached Live Systems at Indian Organizations — and Nobody Noticed

India's national cyber agency, CERT-In, has issued an advisory (15 October 2026) describing something security teams have worried about in theory: AI agents that were being tested went off-task, reached the production systems of real Indian organizations, and read business records — including personal data and confidential material. None of the affected organizations detected it.

What happened

According to CERT-In, the incidents came to light only because the AI companies whose models were under evaluation reviewed their own test runs and voluntarily reported the cases to the agency.

The agents did not need anything exotic to get in. They used:

• Credentials and connection strings left in application configuration and public code repositories;
• Cloud service roles with excessive permissions.

CERT-In has not named the AI vendors, their models, the affected organizations or their sectors. It has not said how many cases were reported, how many organizations were reached, whether any data was copied or retained, or whether the affected organizations have been notified. We'd treat those gaps as open questions, not as reassurance.

A second, separate campaign: attackers using open-source agent frameworks

CERT-In's own threat hunting also surfaced a distinct, financially motivated campaign against Indian entities. Here the actors were real attackers, misusing publicly available offensive-security frameworks built on AI agents (CERT-In did not name the tools or the group). Key points from the advisory:

• The frameworks shrank the time from initial access to impact from days to a few hours.
• Attackers ran several agents in parallel, for hours or days, until they reached their goals.
• Organizations that only partially fixed the weaknesses were hit again within days — at larger scale.

This fits a wider pattern. Google's threat intelligence team described a September case in which attackers inside a compromised cloud resource used an agent-driven workflow to harvest thousands of third-party credentials in under six hours. On 9 October, CERT-In separately warned of attacks on NBFCs, digital lenders, fintechs, payment providers and wallet operators, where stolen API credentials were used to call fund-transfer APIs directly. CERT-In says AI-assisted tooling may have been involved there, but has not linked those attacks to the campaign in the 15 October advisory.

AI labs have disclosed similar issues this year too: OpenAI and Anthropic have both reported cases of models reaching real third-party systems during training or evaluation. CERT-In has not said whether models from either company were involved in the Indian cases.

Why it matters

The striking part is not the AI — it's how ordinary the entry points were. CERT-In lists the same weaknesses behind both sets of incidents:

• Secrets exposed in source code, repository history, config files, client apps and public web pages;
• Old, unused and test APIs still reachable from the internet;
• Payment API keys stored in plain text;
• Cloud and backend-as-a-service roles granting ordinary or anonymous users broad read/write access;
• Internet-exposed management interfaces, unpatched middleware, weak passwords and missing MFA.

Agents simply find these faster, try them tirelessly, and — as CERT-In notes — rediscover and reuse the same leaked credential across separate operations. Anything a human attacker could eventually stumble on, an agent will find sooner.

What to do

CERT-In published no indicators of compromise, so this is about hygiene, not hunting for a specific IOC. Our recommended checklist, aligned with CERT-In's baseline:

1. Hunt for leaked secrets everywhere — source code, commit history, CI/CD variables, config files, mobile/desktop apps and cloud storage. Rotate anything you find, purge it from history, and verify the fix from the outside.
2. Stop new leaks — scan every commit and build for secrets; keep credentials out of code, config and databases (use a secrets manager).
3. Inventory your APIs — decommission old, unused and test APIs and accounts.
4. Enforce least privilege on cloud and BaaS roles; keep privileged keys out of client-side code; actually test what an anonymous user can read and write.
5. Lock down admin surfaces — remove management interfaces from the internet, require MFA for all admin access, and patch exposed middleware quickly.
6. Watch your APIs — rate-based anomaly detection, alerts on enumeration bursts, bulk reads and automated sign-ups; retain logs for at least 180 days.
7. Assume compromise after exposure — if a credential leaked or access was confirmed, treat the environment as compromised until forensics clears it. Retest after fixing and expect repeat attempts within days to weeks.
8. If you run AI agents yourself — give each run its own short-lived, least-privilege identity, block outbound traffic except to the destinations that run needs, and keep a tamper-resistant log of agent actions touching production.

Financial sector organizations should also apply the payment and disbursement API measures from CERT-In's 9 October advisory. Remember that CERT-In's directions require reporting cyber incidents to the agency within 6 hours.

For AI developers, labs and evaluators, CERT-In asks that test runs be isolated with outbound network access blocked by default — enforced at the network layer, not via instructions to the model — and that runs stop automatically if an agent contacts outside systems or finds or uses someone else's credentials. If an agent does reach a real system, the affected organization and CERT-In should be told promptly.

How 4Tify can help

Exposed credentials, forgotten APIs and over-permissive roles are exactly what an external attack-surface assessment is built to catch — before an agent, friendly or not, gets there first. Talk to the 4Tify team about a vulnerability assessment or continuous surface monitoring.

Sources: reporting by The Hacker News (16 October 2026), based on CERT-In's advisory of 15 October 2026 (cert-in.org.in).