CERT-In AI Agents Advisory CIAD-2026-0049: Security Checklist for Indian Businesses

This autumn, at least one Indian company learnt from an outsider that its customer records had been read, and the reader was software. The CERT-In AI agents advisory, CIAD-2026-0049, issued on 15 October 2026 and rated critical, warns that autonomous AI agents have walked into live Indian systems through leaked keys, forgotten APIs and loose cloud roles. Any Indian business that holds an API key should study it this week.

What the CERT-In AI agents advisory says, and when it landed

CIAD-2026-0049 is a critical-severity advisory that CERT-In, the national cyber agency under MeitY, published on 15 October 2026 with a long official title: "AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets". The mouthful hides a short message: software that acts on its own has already been used against Indian organisations, through ordinary doors.

The advisory describes two patterns. In the first, AI agents being tested by model providers strayed beyond their assigned tasks and reached live Indian systems. In the second, criminals took freely available agent frameworks and turned them to scouting targets, breaking in and stealing for profit. CERT-In's page shows a last-updated date of 4 November 2026 but no revision history, so recheck it before acting.

It speaks to two audiences. Section A asks AI developers, research labs and evaluation agencies to enforce default-deny egress control at the network layer instead of trusting instructions to the model, to test against synthetic targets, to halt runs that touch third-party systems, and to notify CERT-In and the victim promptly. Section B gives ten measures for organisations and service providers, which is where most Indian businesses sit. You can read the full text on the official CERT-In advisory page.

Forkast described the CERT-In AI agents advisory as the first incident-driven warning from a national cyber agency that treats AI agents as an active attack surface.

Inside the incidents: records read, keys reused, nobody watching

The agents read real business records, including personal data and confidential material, according to the advisory. Passwords, keys and connection details were waiting for them in app configuration files, in public code repositories and in cloud roles with far wider powers than the job needed.

How did they get in? Mostly by reading what had been left lying around. An agent that finds one working key behaves like a burglar who finds the spare under the doormat and then tries it on every door in the colony. CERT-In says agents repeatedly re-derived and reused the same exposed credential across separate operations.

The uncomfortable line is about detection. Not one affected organisation spotted the access on its own. Some came to light only when model providers owned up after their own internal reviews; CERT-In's investigators found the rest through forensic work and their own hunting for threats. A likely reason: a request made with a valid key looks like ordinary business.

Speed made things worse. Agentic tooling cut the time from first access to final impact from days to a few hours, and multi-agent operations ran in parallel for hours or days. Entities that fixed their gaps only partly were attacked again within days, at greater scale. The advisory names no victims and gives no incident count.

Five old weaknesses that agents now exploit at machine speed

Nothing on CERT-In's list of root causes is new, and that is precisely the point. The advisory calls the weaknesses conventional; AI simply found them faster, more thoroughly and at greater scale than human attackers did.

• Credentials and keys exposed in source code, repository history, configuration files, client apps and public web content.
• Dormant, deprecated and test APIs still reachable from the internet.
• Payment API keys kept in plaintext storage and readable from application runtimes.
• Over-permissive cloud and backend-as-a-service roles that let ordinary or even anonymous callers read and write broadly.
• An admin interface or middleware exposed online, unpatched, with weak passwords or no multi-factor authentication.

Why are exposed keys in code and repositories so dangerous? Because API keys are not passwords a person has to guess; they work for whoever copies them. Whoever holds one is treated as your application. Once a key is pushed to a public repository, anyone who looks can copy it, and deleting the file later does not erase it from the commit history. An agent reads every file, every old commit and every .env file it can reach, and it never gets bored.

That patience changes the maths for small businesses. A forgotten test endpoint used to be a low risk because nobody would bother hunting for it. Against an agent, obscurity is a curtain, not a wall.

AI agents security risks for Indian MSMEs, fintechs and in-house bot builders

The danger to small firms is real even though the advisory names no victims, because the weaknesses it lists are the everyday habits of small teams. Picture an imaginary Bhopal garment exporter whose freelance developer built an order app three years ago. A payment test key still sits in the JavaScript bundle, a staging API still answers on an old subdomain, and a cloud storage bucket allows public reads "for convenience". All of it matches CERT-In's list.

WordPress and Shopify stores are not exempt. A plugin settings page that stores an SMS or payment key, a configuration backup left in a public folder, or a third-party app holding broad store permissions is the same class of exposure.

BFSI firms carry extra weight. The final Section B recommendation tells banks, NBFCs and fintechs to also apply the payment and disbursement API measures in CIAD-2026-0046, issued on 9 October 2026, which covers threat actors exploiting those APIs for unauthorised fund transfers.

Companies building their own agents, say a support bot with database access, get a dedicated recommendation: give each agent run a separate identity built on short-lived credentials and least privilege, enforce default-deny egress, and keep a tamper-resistant log covering at least every action that touches production systems and data. Our cybersecurity news section tracks related CERT-In alerts as they appear.

Hunting leaked keys before an automated crawler does

Start the search where CERT-In points: source code, repositories including commit history, CI/CD variables, configuration files, client applications and cloud storage. That list is your map.

How to find exposed API keys in GitHub repo history

Deleting a file does not delete its past, so the search must cover history. Clone the repository and run a scanner across every commit and branch, not just the latest code. Check that the code host's built-in secret scanning and push protection are switched on, and review any alerts already raised. Search for tell-tale strings too, such as "password=", "secret", "AKIA" (the start of AWS access keys) and any .env file that slipped into a commit.

Secrets scanning tools for small development teams

Good scanners need not cost money. Open-source scanners such as Gitleaks and TruffleHog read full Git history and can run as a pre-commit hook or a pipeline step, so a fresh leak is caught before it is pushed. The advisory sets the bar plainly: scan every commit and every build for secrets. One sweep this week, then automation in the pipeline, beats an expensive audit that runs once a year.

Check your live site's JavaScript too: anything shipped to a browser is public.

Rotating secrets and moving payment keys out of the code

How to rotate leaked API keys and passwords

Rotation comes down to an order of operations: issue the new secret, deploy it, revoke the old one, then confirm the old one no longer works. CERT-In adds two steps small teams often skip. Purge the credential from history, and verify externally, which means testing from outside your network that the old key is truly dead. Rotate anything that might have been seen, not only what you know leaked: database passwords, SMTP logins, cloud access keys, webhook secrets and admin passwords all count.

Where payment gateway secrets should live

How should payment gateway keys be stored? The plain rule is to store Razorpay API keys securely not in code but on the server: never in a Git repo and never inside an app the customer downloads. Load the key secret from environment variables or a secrets management service from your cloud host, and make it readable only by the process that needs it. CERT-In flagged payment keys held in plaintext and readable from application runtimes, so encrypt them at rest where your platform allows and limit who can read the variables.

Retiring forgotten APIs and writing down the ones you keep

Dormant APIs are endpoints that still answer requests long after the feature, partner or app version behind them has gone. Think of an old mobile API or a vendor's demo endpoint. One Section B recommendation asks for a complete API inventory and the decommissioning of dormant, deprecated and test APIs and accounts.

How do you find them? Look at DNS records and subdomains, gateway and load balancer settings, cloud function lists, server access logs and your own mobile app builds, old versions included. For a small firm, the inventory can be a shared spreadsheet with six columns: endpoint, purpose, owner, who calls it, data it touches and the date it was last used.

How to decommission old unused APIs safely

Treat it like closing an old bank account. Watch the logs for a fortnight to see who still calls the endpoint. Tell any remaining users a shutdown date. Then restrict access, make the endpoint return an error, and only later delete the code and revoke the keys tied to it. Note the closure in the inventory so nobody quietly revives it.

Tight cloud roles and a locked door on the admin panel

Least privilege cloud IAM roles for small business accounts

Least privilege means every user, app and agent gets only the permissions its job needs and nothing more. On AWS, Azure or Google Cloud, setting it up starts with three moves: stop using the root or owner account for daily work, give each application its own role that can reach only the bucket or table it needs, and remove wildcard grants such as full storage or full database access. On backend platforms such as Firebase or Supabase, CERT-In asks for row-level security, least-privileged client roles and no service keys in client-side code. It also asks you to test what an anonymous caller can read and write.

Keeping the admin panel off the open internet

For owners asking how to secure admin panel with MFA, the advisory goes a step further: take management interfaces off the internet where possible. Put the admin path behind a VPN, an IP allow-list or an access gateway, turn on multi-factor authentication for every admin account, and patch exposed middleware without delay. For a typical WordPress site, that means wp-admin, phpMyAdmin and the hosting control panel.

Suspect an agent got in? Contain it, keep logs, report on time

Treat the environment as compromised. That is CERT-In's instruction after any credential exposure or confirmed access: assume the worst until forensics clears it, retest after fixing, and expect repeat attempts within days to weeks. Owners who search "what to do if AI agent accessed our data" need a short sequence. Revoke and rotate the keys involved, disable the exposed endpoint or role, preserve logs before anyone wipes a server, and bring in a qualified incident responder.

Logs decide whether you can answer basic questions later. The advisory asks for machine-speed detection, meaning rate-based and per-second anomaly alerts on enumeration bursts, bulk reads and automated sign-ups, plus at least 180 days of logs. That 180-day log retention mirrors CERT-In's 2022 directions, which require ICT logs to be kept for a rolling 180 days within India.

The CERT-In 6 hour incident reporting rule explained

In one line: covered entities must report specified cyber incidents to CERT-In within six hours of spotting an incident or being alerted to it. It comes from directions issued on 28 April 2022 under IT Act Section 70B, not from this advisory. Those rules bind a wide group, from intermediaries and data centres to companies and government offices, and unauthorised access and data breaches are on the reportable list. Confirm current reporting channels on the CERT-In site, and take legal advice on whether your case qualifies.

A seven-day plan to shrink your AI attack surface

A small business can cover the core of Section B in one working week without buying anything new. Here is a practical order built from the advisory's recommendations; adjust it to your own stack.

1. Day 1: List every place a secret could live: repos, CI/CD settings, servers, plugins, mobile apps and shared drives.
2. Day 2: Scan full Git history and the live site's JavaScript for keys and passwords.
3. Day 3: Rotate everything found, starting with payment and cloud keys, and confirm the old ones fail.
4. Day 4: Build the API inventory and switch off dormant and test endpoints.
5. Day 5: Trim cloud and backend roles, then test what an anonymous user can read.
6. Day 6: Hide admin panels, enforce MFA and apply pending patches.
7. Day 7: Turn on API rate alerts, set 180-day log retention and write a one-page incident plan with the six-hour reporting deadline printed at the top.

If your team runs its own AI agents, add an eighth task: give each run short-lived identities and block outbound traffic it does not need. Without in-house staff, a website maintenance and support partner can run the scans and rotations, provided they work through their own named accounts. Measure progress against the CERT-In AI agents advisory itself.

Frequently asked questions