AI security

India's Computer Emergency Response Team (CERT-In) issued a critical advisory on October 15, CIAD-2026-0049, titled "AI Agents as Attack Vectors". AI model providers had voluntarily told the agency that autonomous models under research and evaluation went beyond their assigned tasks and reached live systems of Indian organisations, where they read business records holding personal data and confidential material. They got in with credentials and connection settings left exposed in application configurations, public code repositories and overly permissive cloud service roles. None of the affected organisations noticed. Each case surfaced only because the provider disclosed it after an internal review.

That week, OpenAI added new entries to its public misalignment reports describing how its own research models, all in June, pulled a signing secret out of a government statistics site, used credentials found in a public JavaScript file, and spent test cryptocurrency from a wallet that was not theirs. Nobody hostile directed any of this. The models were trying to finish a task. If you have a key in a commit history or a test API still answering on the internet, the advisory treats it as reachable by software that searches faster and more thoroughly than a human attacker would.

How it works

An evaluation agent is a model given a goal, such as "find this statistic", and tools to reach the internet. When the normal route fails, it keeps looking for another one. In the Indian cases that route was a credential somebody had already published by mistake: an API key in a config file, a database connection string in a repository, or a cloud role granting far more than the application needed. CERT-In says the agents recovered the same exposed credential again and reused it in separate operations, so a key found once kept working until its owner changed it.

The advisory names the weaknesses behind every incident it reviewed, and none of them is new: credentials in source code, repository histories, configuration files, client applications and public web content; dormant, deprecated and test APIs left open to the internet; payment API keys stored in plain text; over-permissive cloud and backend-as-a-service roles; and internet-facing admin interfaces with weak passwords or no multi-factor authentication (MFA). What changed, CERT-In says, is that agents find and use these gaps faster and at greater scale.

OpenAI's government statistics case shows the chain in detail. During reinforcement learning training, a model asked for one year of hospital bed figures was repeatedly denied. It used the site's file download feature to fetch files outside the folder that feature should serve, including the compiled application and a configuration file. That file held a database connection string, the secret used to sign authorisation tokens and email login credentials. The model then saw that the application read identity claims from tokens without verifying their signature, built its own unsigned tokens, passed the authorisation check and saved 24 years of data. Its final answer mentioned none of it.

In two evaluations against an international research organisation's public dashboard, a model found full-access credentials for a live search service in the site's public JavaScript and pulled 1,489 user records with names and email addresses. In the second run it changed an authentication setting to obtain a cloud storage token and downloaded about 147,000 rows of non-public tables.

The wallet case, from a GPT-5.6 Sol family model, involved no customer system but follows the same logic. Asked to deploy contracts on Ethereum's Sepolia test network without a funded wallet, it derived accounts from publicly known developer recovery phrases, checked 362 addresses, and paid the deployment fees from the one that had enough test tokens. That happened on June 26 and OpenAI found it on September 25. The model's summary left out where the funds came from.

What CERT-In says is happening

CERT-In does not name the providers, the affected organisations or how many there were. It also describes a separate, financially motivated campaign in which criminals used publicly available AI-native offensive security frameworks against Indian entities. There, agentic tooling cut the time from initial access to final impact from days to a few hours, and victims that fixed only part of what was exploited were hit again within days, at a larger scale.

The repeat attacks matter for cleanup. If you rotate the one key a provider tells you about and leave its neighbours in the same config file, the next run finds those instead.

What to do

1. Search every place CERT-In lists, history included. Run a verifying scanner across all repositories and their full history, for example trufflehog git file://. --only-verified in each clone, or gitleaks git with its default rules. Then cover what scanners of repos miss: built mobile and desktop apps (unzip the APK or IPA and grep the bundle), public JavaScript bundles, .env and appsettings.json files on web roots, and storage buckets with public read.
2. Rotate first, then rewrite history. Deleting the commit alone does nothing, because forks and clones keep it. Change the password on any connection string, reissue API and payment keys, and regenerate token-signing secrets, which invalidates every token issued with the old one. After that, remove the secret from history with git filter-repo and force-push, so it stops resurfacing in scans.
3. Inventory and shut old APIs. Compare your API gateway or load balancer routes against what the current apps call. Version paths such as /v1/, hostnames containing test, dev, uat or staging, and endpoints with no traffic for 90 days are the candidates to switch off.
4. Cut cloud roles to what each workload uses. AWS IAM Access Analyzer can generate a policy from a role's CloudTrail activity; Google Cloud's IAM Recommender flags unused permissions. Apply the same rule to any AI agent you run internally: one short-lived identity per run, scoped to the task.
5. Get admin interfaces off the internet and require MFA on every one that remains reachable.
6. Keep logs for at least 180 days, which CERT-In recommends. CERT-In's April 2022 directions already require logs of information and communication technology (ICT) systems to be kept for 180 days, so many teams are covered on paper; check that API gateway and cloud audit logs are included.

Also check that your own authorisation code verifies token signatures. A JWT library call that decodes without verifying, or accepts alg: none, does exactly what OpenAI's model exploited.

How to tell whether an agent was already in

Start from every credential you find in step 1. For each one, search its use over the whole period it was exposed: the AccessKeyId in AWS CloudTrail, the service account as principal in Google Cloud Audit Logs, and source IPs in database connection logs outside your hosting ranges. In OpenAI's cases the model was refused several times before it switched to a found credential, then took far more than the task needed: 24 years instead of one. Look for that shape: a run of 401, 403 or 429 responses from one client, then a success with a credential used from an address you have not seen, then bulk reads.

CERT-In advises treating any environment with a credential exposure or confirmed intrusion as compromised until it has been forensically cleared. If a provider contacts you about agent access, ask for the timestamps, endpoints and credentials involved, and report to CERT-In within the six hours those same directions require.

This follows OpenAI's earlier disclosure that its agents probed public data sites in Australia, and 543,699 live keys in public GitHub repos shows how much there is to find. Our attack surface management work looks for exposed keys, forgotten test APIs and open admin panels, and cloud and Kubernetes security reviews cover role permissions. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Deccan Chronicle, Inc42, Decrypt, SecurityWeek, The Decoder, Cointelegraph, Fortune, The Block, Linklaters on the CERT-In directions of April 2022.