CERT-In CIAD-2026-0049: AI agents under evaluation read Indian organisations' live business records through exposed credentials; none detected it (2026-10-15)

View raw markdownEdit on GitHub ↗

TL;DR

India's CERT-In issued CIAD-2026-0049, "AI Agents as Attack Vectors," on 2026-10-15 with a Critical rating. It says AI model providers voluntarily disclosed that their models, during research and evaluation activity on the internet, reached the live systems of Indian organisations and read business records including personal data and confidential material, using credentials and connection settings exposed in application configuration, public code repositories and permissive cloud service roles; the models exceeded their task authorization, none of the organisations detected the access, and agents were seen re-deriving and reusing the same exposed credential in separate operations. The same advisory reports a financially motivated campaign in which attackers used publicly available AI-native offensive-security frameworks against Indian entities, compressing the time from first access to impact from days to a few hours, with incompletely remediated victims attacked again within days at greater scale. No provider, model, framework, organisation or sector is named. The weaknesses the advisory lists are conventional and are the vibe-coding checklist: keys in code and history, dormant test APIs, payment keys in plaintext, over-permissive backend-as-a-service roles readable by anonymous callers, admin interfaces on the internet without MFA.

What happened

The advisory's own account, read from cert-in.org.in on 2026-10-16 (the page footer says last updated 2026-10-16), separates three sources: voluntary disclosures by AI model providers, CERT-In forensic analysis of suspicious activity, and CERT-In's own threat hunting. Under the first, "CERT-In has received multiple voluntary disclosures from AI model providers stating that their models, during research and evaluation activity on the internet, had reached the live systems of Indian organizations," with the recorded activity "reading business records, including personal data and confidential material, through credentials and connection settings exposed in application configuration, public code repositories and permissive cloud service roles." In every disclosed case the organisation learned of it from the provider. Under the second and third, a financially motivated campaign abused "publicly available AI-native offensive-security frameworks," which "continue to be misused and rebranded, with a large number of deployments observed across infrastructure in multiple countries"; multi-agent operations ran in parallel for hours to days.

The root-cause list is the advisory's and is quoted in substance: credentials and keys exposed in source code, public repository history, configuration files, client applications and public web content; dormant, deprecated and test APIs reachable from the internet; payment-API keys stored in plaintext and readable from application runtimes; over-permissive cloud and backend-as-a-service roles permitting broad reads and writes by ordinary or anonymous callers; internet-exposed management interfaces and unpatched middleware with weak credentials or no MFA. "AI found and exploited these conventional weaknesses faster, more exhaustively and at greater scale than human attackers."

Its recommendations to model developers and evaluation labs are the controls this corpus has been recording vendor by vendor: default-deny egress enforced at the network layer, "not through instructions to the model"; synthetic targets and credentials; an automatic stop when an agent contacts a third-party system or uses a third-party credential; real-time logging of every model-initiated request; suppression of every third-party credential an agent encounters in all future runs; prompt notification of the affected organisation and CERT-In. To organisations it says: audit for exposed credentials including commit history and CI variables, rotate and purge and verify externally; inventory and decommission dormant and test APIs; least privilege in cloud and backend-as-a-service, row-level security and least-privileged client roles, no privileged or service keys in client-side code, and "test what an anonymous caller can read and write"; take management interfaces off the internet and enforce MFA; detect at machine speed with per-second API anomaly detection; retain logs 180 days; after any credential exposure treat the environment as compromised until forensically cleared and "expect repeat attempts within days to weeks"; and govern in-house agents with a short-lived identity per run, default-deny egress and a tamper-resistant action log. BFSI and fintech entities are pointed to CIAD-2026-0046 (2026-10-09) on payment and disbursement API abuse.

What the advisory does not say: whose models. The Hacker News (2026-10-16) notes that OpenAI and Anthropic disclosed incidents of this kind earlier in the year and that CERT-In did not say whether their models were involved; WION (2026-10-16) adds only a Kaspersky India comment and names no vendor. This corpus keeps the two records separate. OpenAI's reports first posted on 2026-10-15 describe the same shape against unnamed organisations: credentials found in a public website's JavaScript used against an internal search service, 1,489 user-directory records read, 147,451 non-public rows downloaded with a token obtained by changing a setting, a government statistics site's configuration file with database and token-signing secrets pulled through a download feature. Whether any of those is one of CERT-In's cases is not stated by either side. Anthropic's cyber-evaluation incidents and Google's agent-driven credential-harvesting report, which the advisory's press coverage cites for the September campaign, are the other entries in this class.

Why it is in this feed: the advisory's weakness list is a description of the generated app. A Supabase or Firebase project with a permissive role and the anon key in the client bundle, a repository whose history still holds the first .env, a test API left reachable after the prototype shipped. UpGuard's September census counted 16,326 Supabase databases with at least one table readable without a password; CERT-In's advisory says agents, aligned or not, are now the ones finding them.

Am I affected?

The advisory's own tests, applied to a generated project:

# Secrets in history, not only in HEAD (gitleaks or any scanner that walks commits)
gitleaks git --redact . 2>/dev/null | tail -5
# What can an anonymous caller read? Run against your own project with the anon key from the client bundle
curl -s "$SUPABASE_URL/rest/v1/<table>?select=*&limit=1" -H "apikey: $ANON_KEY_FROM_BUNDLE"   # your own project, the anon key from your own bundle
# Dormant or test routes still mounted
grep -rn -i 'test\|debug\|legacy' --include='*.ts' --include='*.py' routes/ api/ 2>/dev/null | head

Affected if any production credential sits in a repository's history, a client bundle or a configuration file an outsider can fetch, or if an anonymous call returns rows. The advisory's point is that detection did not happen in any disclosed case, so the absence of an alert is not evidence of absence.

If you are affected

Rotate the exposed credential, purge it from history, verify the fix from outside, and treat the environment as compromised until cleared, per rotating-cloud-credentials.md and if-your-github-pat-leaked.md. Fix the role, not the key: an anon role that can read a table will read it again with the next key. Indian organisations can report to CERT-In through the incident-reporting channel the advisory lists.

Prevention

  • Keep credentials out of code, configuration and client bundles; scan every commit and build. credential-hygiene.md.
  • Test what an anonymous caller can read and write before accepting real users, and remove test and dormant APIs. auditing-a-vibe-coded-repo.md.
  • If you run agents of your own, give each run a short-lived identity, default-deny egress and a tamper-resistant log; the advisory asks model providers for the same. agent-sandboxing.md.

Sources