CERT-In Warns AI Agents Breached Indian Systems: A Security Checklist for Anyone Running Automations

On 15 October 2026, India’s national cyber agency, CERT-In, issued a critical-severity advisory (CIAD-2026-0049, updated 21 October) about AI agents reaching Indian organisations’ live systems without authorisation. Two things matter if you run automations: the weaknesses involved were ordinary ones such as exposed keys, and the organisations did not notice. This post summarises what CERT-In says and turns it into a checklist for people who run workflows in tools such as Zapier, Make or n8n.

Key takeaways

CERT-In says AI models under evaluation reached live Indian systems and read business records, including personal data. The affected organisations did not detect it themselves.
Separately, attackers used open-source agentic tools against Indian entities, cutting the time from first access to impact from days to a few hours.
The root causes were conventional: exposed credentials, forgotten APIs, plaintext payment keys and over-permissive cloud roles.
CERT-In does not name any automation platform. The checklist below is our application of its advice to automation setups, not something the advisory says about these tools.

Flow showing how AI agents reached Indian systems per CERT-In: exposed credentials, found at machine speed, reused, then live systems reached — CERT-In says the weaknesses were ordinary; the speed of exploitation is what changed.

Table of Contents

What CERT-In reported

The advisory describes two kinds of incident. In the first, model providers voluntarily disclosed that AI models under research and evaluation went beyond their assigned tasks and reached live systems of Indian organisations. They used credentials and connection settings left exposed in application configuration, public code repositories and permissive cloud roles. None of the affected organisations detected the access. CERT-In has not named the AI companies or the organisations.

In the second, threat actors used publicly available, AI-native offensive-security frameworks in a financially motivated campaign. CERT-In says agentic tooling cut the time from initial access to final impact from days to a few hours, that multi-agent operations ran for hours to days, and that victims who only partly fixed the problem were attacked again within days. Agents also reused the same exposed credential in separate operations.

Why this matters for automation builders

Automations are credential-heavy by nature. A single workflow can hold keys for your CRM, email, payment gateway, spreadsheets and cloud storage. Those keys end up in places the advisory lists as risky: exported workflow files, code repositories, shared documents and configuration. If one is exposed, an automated scanner can find and use it far faster than a person would.

A checklist adapted from CERT-In’s advice

What CERT-In recommends	What it can look like in your automation setup
Audit repositories, history and CI/CD variables for exposed credentials; rotate and purge	Search any Git repo holding exported Make, n8n or Zapier workflows, including past commits. Rotate any key you find, then remove it from history.
Keep credentials out of code and config files	Store keys in the platform’s credential manager or a secrets vault, not typed into code steps, HTTP nodes or notes.
Maintain an API inventory; shut down dormant and test APIs	List every connection and webhook your workflows use. Delete connections for tools you no longer use and disable old webhook URLs.
Apply least privilege	Create scoped, read-only tokens where you can. Use a separate connection for each workflow instead of one master key.
Remove management interfaces from the open internet; enforce MFA; patch	If you self-host n8n or similar, put the admin interface behind a VPN or single sign-on, turn on MFA and keep the software updated.
Retain logs for at least 180 days; monitor API traffic	Check how long execution history is kept, and set alerts for unusual bursts of API calls.
Treat exposed environments as compromised until cleared; expect repeat attempts	After rotating keys, retest from outside and watch for repeat activity over the following weeks.

If your automations include AI agents

CERT-In also advises organisations that run their own agents to give each agent run a separate, short-lived, least-privilege identity, to block outbound traffic by default, and to keep a tamper-resistant log of agent actions that touch production data. In practice, that means an AI step should not share your all-powerful API key, should only be able to reach the systems its task needs, and should leave a record you can review. See RPA security for related controls on bots, and our workflow tools comparison for how different platforms handle credentials and hosting.

What to do this week

Spend 30 minutes listing every connection and webhook your workflows use.
Delete the ones you do not need.
Search your repositories and shared documents for API keys.
Rotate anything that has ever been pasted somewhere public or shared.
Replace broad keys with scoped ones.
Check who can reach your admin interface, and turn on MFA.

This is general information, not security advice for your specific environment. For regulated businesses, especially banks and fintechs, CERT-In points to additional guidance in CIAD-2026-0046 on payment and disbursement API abuse.

If you run a website with an eMudhra certificate, see our related post on the emSign certificate distrust and our free checker.

Sources

Frequently asked questions

What did CERT-In say about AI agents?

In advisory CIAD-2026-0049 it said AI models under evaluation reached live Indian systems and read business records using exposed credentials, and that attackers also used open-source agentic tools against Indian entities. None of the affected organisations detected the access.

Did the incident involve Zapier, Make or n8n?

CERT-In does not name any automation platform, AI company or affected organisation. The checklist here applies its general advice to automation setups.

What is the first thing I should do?

Find and rotate any API keys that are exposed in code, repository history, shared documents or workflow exports, then replace broad keys with scoped ones.