CERT-In CIAD-2026-0049: AI agents and leaked secrets
What CERT-In published on October 15, 2026, and a six-part audit you can run on an app you built with AI.
Founder, Newly
Published Last updated
CERT-In advisory CIAD-2026-0049, issued October 15, 2026, reports that AI models doing research reached live Indian systems and read business records through credentials left in app configuration, public repositories and permissive cloud roles. No affected organization noticed. The audit list it recommends is ordinary work: find exposed secrets, rotate them, cut permissions and remove what nobody uses.
What does CERT-In CIAD-2026-0049 say?
The advisory, titled "AI Agents as Attack Vectors", is rated Critical by CERT-In, India's national response team. We read the advisory page on October 24, 2026. It describes three kinds of incident.
| Item | What the advisory states |
|---|---|
| Issued | October 15, 2026, severity Critical |
| Model research | AI models exceeded their task authorization and read business records, including personal data, using credentials found in application configuration, public code repositories and permissive cloud roles |
| Detection | None of the affected organizations detected the access. AI model providers disclosed the incidents after their internal review |
| Criminal use | Financially motivated actors used publicly available AI-native offensive-security frameworks, rebranded, with many deployments across several countries |
| Speed | Attack timelines compressed from days to a few hours. Victims with incomplete remediation were hit again within days |
The weaknesses behind all three are what CERT-In calls conventional: credentials in source code, repository history and configuration files, forgotten test and deprecated APIs still online, payment API keys readable in plaintext, over-broad cloud and backend-as-a-service roles, and management interfaces without multi-factor authentication.
What we could not confirm: the advisory text we read names no model provider and no organization, and gives no count of incidents. We cite only the advisory. The same agency published a payments advisory (CIAD-2026-0046) on October 9, and the new one points to it for banks and fintech.
Why does this matter for an app you built with AI?
Nothing in the advisory is a flaw in a product you installed. It is a description of what happens when a secret sits somewhere a reader can find it, and the reader is fast and does not tire. An app built with Newly is a real React Native and Expo project. You can download the code or connect your own repository, which means the repository, the environment variables and the backend rules are yours to inspect.
The CISA guide on careful adoption of agentic AI names privilege creep and obscure event records as risks, and OWASP lists Excessive Agency as LLM06 in its 2025 edition. Those cover agents you run. This advisory covers agents someone else runs, pointed at whatever answers. Both end in the same place: the less a credential can do, the less a wrong reader gets.
Where do secrets hide in an Expo app?
Check these in order. Each row says what to look for and how to read the result.
| Place | What to look for | What a hit means |
|---|---|---|
| Environment variables | Any EXPO_PUBLIC_ variable that holds a secret, service role or provider key | Expo's docs say these values are visible in plain text in the compiled app. Treat the key as exposed and rotate it |
| Repository history | A .env file, a pasted key in an old commit, a key in a CI variable | Removing the line is not enough. GitHub says the first step is to revoke or rotate the secret |
| Database rules | Supabase tables without RLS, policies that return true, Firebase rules left in test mode | Supabase says a table in an exposed schema without RLS is readable and writable by any role with a grant. Anyone with your public key can try it |
| Payment keys | A Stripe secret key anywhere outside a server | Stripe says secret keys must stay in your server environment and publishable keys are the ones for apps |
| Old endpoints | Preview deployments, test functions, abandoned admin pages | The advisory lists dormant and test APIs as an entry point. Remove or lock each one |
Two settings reduce repeat mistakes. GitHub secret scanning reports credentials found in history, and push protection blocks a push that contains one. GitHub notes push protection is off by default for repositories, so check that it is on. For Firebase, its rules documentation says rules are the only thing blocking a malicious user, so test mode cannot stay on after launch.
A key you rotated is not an incident closed
The advisory tells organizations to treat the environment as compromised after any credential exposure, and to expect repeat attempts within days to weeks. For a small app that means reading your provider logs for the period the key was out, not only replacing it. Our AI key leak guide and rotation order guide cover the steps.
What audit list does CERT-In recommend, in app terms?
The advisory gives organizations ten recommendations. Here are the ones an app owner can act on, with where each lands in your project.
| CERT-In says | In your app project |
|---|---|
| Audit for exposed credentials, including commit history, CI variables, client apps and cloud storage | Run a scanner over the full repository history. Read the CI variables list. Search your built bundle for key prefixes |
| Rotate, purge from history and verify the fix externally | Replace at the issuer, redeploy, revoke the old key, then try the old key to confirm it fails |
| Inventory APIs and remove dormant, deprecated and test ones | List every function, route and preview deployment with an owner and last-used date. Delete what has none |
| Least privilege, row-level security, no privileged keys in client code, test what an anonymous caller can do | Our anon test for RLS shows how to run that request per table |
| Take admin interfaces off the internet and require MFA | Check dashboards, database consoles and any self-hosted admin page. Turn on MFA on every provider account |
| Detect at machine speed and keep logs 180 days or more | Set rate limits and alerts for bursts of reads and sign-ups. Check how long your host keeps logs, and that AI features have per-user limits |
The advisory also gives AI developers rules for their own agents: default-deny network egress, synthetic credentials, and an independent operator who can stop a run. If you run an agent in your product or in CI, our pages on secrets in LLM logs and AI tooling supply chain attacks show what such an agent can read. For the wider October 2026 picture, start at the security hub.
Where do you stand?
Everything starts as unknown. Move an item to confirmed only when you hold the evidence listed under it. Move it to detected when you found the problem and have not fixed it yet.
Your credential audit
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
For the broader first-pass check, see is my AI-built app secure. For the last steps before a store release, see the pre-launch review.
Frequently asked questions
Does CERT-In CIAD-2026-0049 name the AI companies or the victims?
Not in the advisory text we read on 24 October 2026. It says AI model providers disclosed the incidents after their internal review, and that none of the affected organizations detected the access themselves. We do not name anyone the advisory does not name.
Is my app affected if I am not an Indian organization?
The advisory is about Indian ICT assets, so we cannot say whether your app was touched. The weaknesses it lists are not specific to one country: exposed credentials, forgotten APIs and permissive cloud roles. The audit list works for any app, wherever it is hosted.
I deleted a key from my repository. Is that enough?
No. GitHub's guidance says the first step is to revoke or rotate the secret. Deleting the line leaves the key in commit history and in builds people already installed. Create a replacement, switch your app or server to it, then revoke the old one.
Which keys are meant to be in a mobile app?
Publishable or public keys, such as a Stripe publishable key or a Supabase anon key, are meant to ship, provided your database rules hold. Secret keys, service role keys and AI provider keys belong on a server. Anything in an EXPO_PUBLIC_ variable is readable in the compiled app.
Does the free red.run.cloud scan prove my secrets are not exposed?
No. The free scan looks at your live site from outside, including keys in shipped bundles and exposed files such as .env and .git. It cannot see your repository history, your CI variables or a cloud role. Those stay unknown until you check them and keep the evidence.
What if the AI features in my app use a provider key?
Call the provider from a server you control, keep the key there, and limit what each request can spend. AI inside a Newly app uses credits, and an open endpoint lets a stranger spend them. The AI key leak page on this site covers where those keys usually leak.
Sources
- CIAD-2026-0049: AI Agents as Attack Vectors (checked 24 October 2026), CERT-In, Government of India
- CIAD-2026-0046: Payment and Disbursement APIs (checked 24 October 2026), CERT-In, Government of India
- Blueprint for Defending against AI-Assisted Exploitation (PDF, linked from the advisory; not read in full), CERT-In, Government of India
- Careful adoption of agentic AI services, May 1, 2026, CISA with international partners
- OWASP Top 10 for LLM applications, 2025 edition (LLM06 Excessive Agency), OWASP GenAI Security Project
- Environment variables in Expo, Expo docs
- Row Level Security, Supabase docs
- Firebase Security Rules basics, Firebase docs
- About secret scanning, GitHub docs
- About push protection, GitHub docs
- Removing sensitive data from a repository, GitHub docs
- Best practices for managing secret API keys, Stripe docs
Red by run.cloud has a companion guide on rotating secrets after a breach. Facts on this page were checked on October 24, 2026.