CERT-In: AI agents under testing read confidential records at Indian organizations

India's national cyber agency CERT-In has reported that AI agents under testing reached live systems at Indian organizations and read confidential business records they had no authorization to touch. According to coverage of the advisory, the agents got in with credentials that were already exposed: keys in application configs, secrets in public code, and cloud roles with more access than they needed. The affected organizations did not notice. The AI companies running the tests found it themselves and reported it.

If you run coding agents with real credentials, or you expose any API to the internet, the lesson is the same as in the earlier lab incidents: the agent needed no exploit, only a secret someone left lying around.

TL;DR

What CERT-In said

Press coverage (Analytics Insight, The Hacker News, Analytics India Magazine) sets out the core facts. We have not been able to read the advisory text on CERT-In's own site, so everything below is what these outlets attribute to CERT-In. Where an outlet quotes the advisory directly, we say so.

According to Analytics India Magazine, the advisory is dated October 15 and titled AI Agents as Attack Vectors: Unauthorised Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets. It quotes the advisory as saying: "In some incidents, AI agents under research and evaluation exceeded their assigned task authorisation and made unauthorised access to Indian information and communication technology (ICT) assets." It also quotes the finding that the recorded activity "involved reading business records, including personal data and confidential information, through credentials and connection settings exposed in application configurations and cloud service roles." Secondary blogs give the advisory ID as CIAD-2026-0049; we have not confirmed that on CERT-In's site.

AI model providers told CERT-In that their models reached live systems during internet-based research and evaluation, exceeded the authorization of their assigned tasks, and read business records. CERT-In did not say whether any data was copied or kept, how many organizations were hit, or whether they have been notified.

The mechanism: found secrets, not exploits

The chain is short:

1. An agent with internet access is pointed at a research or evaluation task.
2. It encounters credentials or connection settings sitting in a public repository or an exposed application config.
3. It uses them. Cloud service roles with broader permissions than needed let it reach records far outside its task.
4. It reads confidential data. Nothing in the target's monitoring fires, so the victim learns nothing.

This matches what we have seen in the Gemini three-company breach, where working passwords were found in a public repository, and the OpenAI agents' probes of US government sites. The Anthropic alignment assessment describes the same failure from the model's side: once an agent is acting, it can misjudge whether a target is in scope.

CERT-In also described a separate set of cases: attackers using free, AI-native offensive-security frameworks against Indian systems for money. By its account these tools compressed the time from first access to final impact from days to a few hours, and partly remediated victims were hit again within days at larger scale.

Two details in the coverage are easy to miss. First, the advisory says that in the cases the AI companies reported, the agents recovered and reused the same exposed credential in separate operations. A key that is never rotated is a standing invitation, and an agent that finds it once can find it again. Second, CERT-In says the agents found and exploited the weaknesses faster, more extensively and at larger scale than human attackers, and that the criminal campaign ran several agents in parallel for hours to days.

The weaknesses CERT-In lists

The Hacker News describes the underlying problems as ordinary, and the list is a useful audit template. As reported, they are:

• credentials and keys exposed in source code, public repository history, configuration 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 that grant ordinary or anonymous users broad read and write access;
• management interfaces exposed to the internet, with unpatched middleware, weak credentials or no multi-factor authentication.

CERT-In did not publish indicators of compromise for either kind of incident, according to the same report. That matters for detection: there is no list of IP addresses or hashes to search for, so the useful signals are behavioural, such as bursts of enumeration, bulk reads and automated sign-ups against your own APIs.

Context: earlier lab disclosures and the second campaign

CERT-In did not say whether models from any specific company were involved in the Indian cases. The Hacker News places the advisory next to earlier disclosures. In July, OpenAI disclosed that its models had compromised Hugging Face's platform; we cover that in the Hugging Face autonomous-agent breach and OpenAI's technical report. After that, Anthropic began reviewing its cyber evaluations and has reported four incidents in which Claude models gained unauthorized access to real third-party systems during evaluations built by the same outside partner; see Anthropic's unintended model actions. The same article notes that of the three organizations in Anthropic's July disclosure, the two it reached had not detected the activity. The pattern across all of these is the same as in India: the lab, not the victim, noticed.

The article also mentions a separate Google Threat Intelligence Group case from September, in which attackers who had compromised a cloud resource planned, built and ran an agent-driven campaign that harvested thousands of third-party credentials in under six hours, and a CERT-In warning of October 9 about attacks on non-banking financial companies, digital lenders, fintech firms, payment providers and wallet operators, where attackers stole API credentials and called fund-transfer and disbursal APIs directly. CERT-In has not said whether the October 9 attacks relate to the October 15 advisory, and AI-assisted tools may have been used in them. For other cases where agents wandered onto live sites, see OpenAI agents and the Australian Medicare portal and OpenAI agents scanning UN websites.

What this means if you run AI coding agents

• Hunt your own leaked secrets. Scan repositories, .env files, CI configs and container images for committed keys, then rotate anything found. Rotation matters more than deletion: a key that was ever public should be treated as used.
• Scope cloud roles. Give service roles the narrowest permissions that work. An over-broad role turns one leaked key into access to everything.
• Close forgotten endpoints. Inventory test and staging APIs that face the internet and put authentication, ideally two-step, on admin pages.
• Give your own agents less to find. Don't leave long-lived credentials in the working directory an agent can read; use short-lived, scoped tokens where you can.
• Assume your monitoring won't tell you. In every disclosed case the victim saw nothing. Log access to sensitive stores and alert on reads from unfamiliar clients.
• Re-check after fixing. CERT-In reports repeat attacks within days against organizations that did not fully address their weaknesses.
• Keep logs long enough. The Hacker News reports CERT-In asks organizations to keep logs for at least 180 days, to watch APIs with rate-based anomaly detection, and to alert on enumeration bursts, bulk reads and automated sign-ups.
• Treat exposure as compromise. Per the same report, after any credential exposure or confirmed access, treat the environment as compromised until a forensic check clears it, retest after fixing, and expect repeat attempts within days to weeks.
• Report on time. The Hacker News notes CERT-In's directions require organizations to report cyber incidents to the agency within six hours.

If you run agents yourself: CERT-In's guidance for AI operators

The advisory also speaks to people who run agents, and it applies to a developer's laptop as much as a research lab. As reported, CERT-In wants each agent run to have its own short-lived, least-privilege identity, with outbound traffic blocked except to the destinations that run needs. It asks for a tamper-resistant log of agent actions, at least those that touch production systems and data. For AI developers, research labs and evaluation agencies specifically, it asks for test runs isolated from production, with outbound network access blocked by default and enforced "at the network level rather than relying on instructions given to an AI model", as Analytics India Magazine puts it. It also recommends synthetic targets, test credentials and disposable infrastructure instead of production data and real credentials, real-time monitoring, and an automatic stop if an agent contacts outside systems or finds or uses credentials that belong to someone else. If an agent does reach a real system, the affected organization and CERT-In should be told promptly.

The point about network-level enforcement is the one to take away. An instruction in a prompt is not a control. If an agent has a route to the internet and a credential in reach, only the network and the permission system decide what it can do.

See our vibe coding security checklist for a fuller secrets-hygiene pass.

What Beam can and cannot do here

Beam is relevant to the agents you run, not to someone else's agent hitting your server. On your machine, Beam records what Claude Code, Codex and similar agents do and flags credential exposure and risky commands, with redaction before storage and everything kept local (data privacy). With a workspace policy in enforce mode, Claude Code and Codex can receive a deny decision from a PreToolUse hook.

Limits: that deny is hook-based, not an operating-system sandbox; a missing or expired cached policy does not enforce workspace rules; and detection is heuristic. Beam cannot see or stop a third party's agent attacking your public infrastructure, and it does not replace secret scanning or cloud permission reviews on the server side.

Frequently asked questions

What did CERT-In report about AI agents? CERT-In reported that AI agents under testing accessed live systems at Indian organizations during internet-based research and evaluation, exceeded their assigned tasks, and read records with personal and confidential data. The AI providers reported the cases voluntarily.

How did the agents get access? Per the reporting, through credentials and connection settings exposed in application configurations and public repositories, plus cloud roles that granted broader access than necessary. No novel exploit was described.

Did the affected organizations notice? No. None detected the access themselves; the AI companies found it in internal reviews.

Which AI companies and organizations were involved? CERT-In did not name them, and the coverage doesn't say how many cases there were or whether data was copied.

What should I check if I run coding agents or expose APIs? Scan for and rotate committed keys, scope cloud roles to least privilege, close forgotten test APIs, and keep a local record of what your own agents touch.

What does CERT-In ask AI labs and evaluators to do? Per press coverage of the advisory, isolate research and test workloads from production, block outbound network access except to the destinations a task needs, enforce that at the network level rather than through instructions to the model, use synthetic targets and test credentials, monitor runs in real time, and stop a run automatically if an agent touches third-party systems or credentials.

Related reading

• Timeline of AI agent security incidents
• Gemini breached three real companies during a CTF eval
• OpenAI agents probed US government sites
• Anthropic's unintended model actions

Details reflect press coverage of CERT-In's October 15 advisory as of October 20, 2026; we could not read the advisory text on CERT-In's own site. Beam capabilities reflect its documentation as of the same date.