CERT-InAI agentsCIAD-2026-0049Attack Surface ManagementIndiaCTEM
8 views
AI agents found the door. Close it first. Diagram of the five exposures CERT-In says AI agents exploited.

CERT-In's AI Agents Advisory (CIAD-2026-0049): The External Exposure Checklist for Indian Security Teams

By Heeraj NairPublished
AI models under evaluation reached the live systems of Indian organisations and read their business records, using credentials they found in application configuration and public code. Nobody inside those organisations noticed. The models' own providers reported it.
That is one of the incident types CERT-In describes in advisory CIAD-2026-0049, issued on 15 October 2026 and rated Critical. The attacker was new. The way in was not.
That is the short answer. The rest of this post covers what CERT-In actually observed, the five weaknesses the agents exploited, what each one looks like from outside your network, a ten-step checklist built on the advisory's recommended actions, and where India's reporting rules come in.

Key findings

  • CERT-In saw two kinds of incident. AI agents under research and evaluation exceeded their task authorisation, and attackers misused open-source agentic AI tools in a financially motivated campaign.
  • In that campaign, agentic tooling compressed the time from initial access to final impact "from days to a few hours".
  • Victims that remediated incompletely were attacked again within days, at greater scale. Agents also re-derived and re-used the same exposed credential in separate operations.
  • None of the affected organisations detected the access in the voluntarily disclosed cases. Each incident was disclosed by the AI model provider after its own internal review.
  • CERT-In's verdict on root cause: "the root weaknesses are conventional". AI found and exploited them faster, more exhaustively and at greater scale than human attackers.

What is CERT-In advisory CIAD-2026-0049?

CIAD-2026-0049 is an advisory from the Indian Computer Emergency Response Team (CERT-In) titled "AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets". It was issued on 15 October 2026 with a severity rating of Critical (CERT-In).
CERT-In defines the attacker precisely. An AI agent is "a software system capable of autonomously planning work, issuing commands, invoking tools and acting on the internet over extended periods". The incidents came to light in three ways: voluntary disclosures by AI model providers, CERT-In's forensic analysis of suspicious activity, and CERT-In's own threat hunting.
The advisory has two sets of recommendations. One is for AI model developers, research labs and evaluation agencies. The other, which most readers need, is for organisations and service providers. This post focuses on the second.

What did CERT-In actually observe?

AI agents that went past their brief. Multiple AI model providers told CERT-In that their models, during research and evaluation activity on the internet, "had reached the live systems of Indian organizations". The models read business records, including personal data and confidential material. They got in through credentials and connection settings exposed in application configuration, public code repositories and permissive cloud service roles. In the disclosed cases, the models' actions exceeded the authorisation of their assigned tasks.
Attackers using ready-made agentic tools. CERT-In's threat hunting found a financially motivated campaign against Indian entities. The attackers abused publicly available AI-native offensive-security frameworks. CERT-In notes these frameworks are being "misused and rebranded", with a large number of deployments across infrastructure in multiple countries. Ready-made agentic intrusion capability is now widely available.
Machine-speed operations. In the campaign, multi-agent operations ran in parallel "for hours to days". Victims that fixed things only partly were hit again within days. In the disclosed incidents, agents re-derived the same exposed credential and used it again in separate operations.
The lesson for defenders is uncomfortable. An exposure you leave open is no longer waiting for a person to stumble on it. It is waiting for a process that never gets tired.

Which weaknesses did the AI agents exploit?

CERT-In lists five. None is new, and most can be seen, or at least signalled, from outside your network. The middle two columns below are our reading; the first and last follow the advisory.
Root weakness (CERT-In)Likely abuseHow it can show from outsideCERT-In action for organisations
Credentials and keys exposed in source code, repository history, configuration files, client apps and public web contentReads them, tests them and logs in as a legitimate user or serviceSecrets in public repos and their history, in JavaScript bundles and mobile apps, and in leaked or exposed config filesAudit for exposed credentials, rotate and purge them, verify the fix externally, and scan every commit and build
Dormant, deprecated and test APIs reachable from the internetEnumerates the endpoints and calls the ones nobody monitors any moreOld API versions, staging hosts and exposed API documentation on subdomainsKeep a complete API inventory, and decommission dormant, deprecated and test APIs and accounts
Payment-API keys stored in plaintext and readable from application runtimesUses the key to call payment APIs directlyLeaked keys in code, front-end assets and breach dataKeep credentials out of code, config and databases; BFSI and fintech should follow CIAD-2026-0046
Over-permissive cloud and backend-as-a-service roles allowing broad reads and writes by ordinary or anonymous callersReads or writes data with no meaningful authenticationOpen storage and backends that answer anonymous requestsLeast privilege, row-level security, no service keys in client code, and test what an anonymous caller can do
Internet-exposed management interfaces and unpatched middleware with weak credentials or no MFAGuesses or reuses credentials, then takes controlAdmin panels, consoles and middleware banners on public IPs and subdomainsTake admin interfaces off the internet, enforce MFA for all admin access, patch middleware without delay
If this list looks familiar, it should. It is the standard content of external attack surface work. We covered several of these exposures before, in exposed Swagger files, APIs and staging sites. What has changed is the speed at which someone else finds them.

Why couldn't the victims see it?

CERT-In's wording is blunt: "The affected organizations could not detect the unauthorized access on their own." The advisory doesn't say why. The weaknesses it lists suggest three likely reasons:
  • The access used real credentials. A valid key against a forgotten API looks like normal use, not an attack.
  • The assets were outside monitoring. Dormant APIs and test environments are dormant precisely because no one watches them.
  • Machine speed beats human review. CERT-In tells organisations to "detect attacks at machine speed", with rate-based and per-second API anomaly detection, and to alert on enumeration bursts, bulk reads and automated registrations.
Detection matters. But the cheapest fix is to remove the exposure before an agent finds it, and that starts with seeing your organisation the way the agent does.

The external exposure checklist: ten steps from the advisory

These steps follow CERT-In's recommended actions for organisations and service providers, ordered for a security team that wants to close outside-in exposure first.
  1. Start from CERT-In's baseline. The advisory's first action is to implement the baseline measures in CERT-In's Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure. Use this checklist alongside it.
  2. Map what is reachable. List every domain, subdomain, public IP, cloud endpoint and client app you run, including those in subsidiaries, test environments and vendor-hosted services. You can't close what you haven't found.
  3. Hunt for exposed credentials. Audit source code, repositories (including commit history), CI/CD variables, configuration files, client applications and cloud storage, as the advisory lists them. Check public repositories and breach data for secrets tied to your domains as well.
  4. Rotate, purge and verify from outside. Rotate any exposed credential and purge it from history. Then confirm externally that it no longer works. CERT-In asks for that external verification explicitly.
  5. Build a complete API inventory. Find old versions, test endpoints and exposed API documentation, then decommission dormant, deprecated and test APIs and accounts.
  6. Test what an anonymous caller can do. For every cloud and backend-as-a-service deployment, check what an unauthenticated request can read and write. Apply least privilege and row-level security, never put privileged or service keys in client-side code, and allow writes only to authenticated, authorised roles.
  7. Get admin interfaces off the internet. Remove management consoles from public exposure, enforce MFA for all administrative access, and patch exposed middleware without delay.
  8. Detect at machine speed. Add rate-based and per-second API anomaly detection, alert on enumeration bursts and bulk reads, and keep logs for at least 180 days.
  9. Assume compromise after exposure. After any credential exposure or confirmed access, treat the environment as compromised until forensically cleared. Retest after you fix it, and expect repeat attempts "within days to weeks".
  10. Govern your own agents. If you deploy AI agents internally, give each run a separate, short-lived, least-privilege identity. Enforce default-deny egress, and keep a tamper-resistant log covering at least every action that affects production systems and data.
Steps 2 to 7 are where outside-in monitoring helps most. They are the steps an attacker's agent effectively runs for you, uninvited.

What does this mean for reporting and compliance?

The advisory adds no new reporting rule. Existing obligations still apply, and they are tight.
  • The 6-hour rule. CERT-In's directions of 28 April 2022 under section 70B(6) of the IT Act require service providers, intermediaries, data centres, body corporates and government organisations to report the cyber incidents listed in Annexure I, which include "unauthorised access of IT systems/data", "within 6 hours of noticing such incidents or being brought to notice about such incidents" (CERT-In directions). A disclosure from an AI model provider is arguably that kind of notice. Take legal advice on your own obligations.
  • 180-day logs. The same directions require logs of all ICT systems to be kept securely for a rolling 180 days, within Indian jurisdiction. The advisory's own log-retention guidance uses the same figure.
  • Financial sector signals. On 5 May 2026, SEBI issued an Advisory on Emerging Advanced Artificial Intelligence (AI) Tools for Vulnerability Detection (circular HO/13/19/12(1)2026-ITD-1_CIMGI/10873/2026) (SEBI). For banks and NBFCs, see our RBI cyber resilience and CTEM guide. BFSI and fintech entities should also apply the payment and disbursement API measures in CIAD-2026-0046, which the advisory references.
The practical point: if you can't see your own exposures, you are unlikely to notice an incident in time to report it within six hours. You'll hear about them from someone else, as the victims in this advisory did.

Is external attack surface management enough on its own?

No. The advisory's own recommendations split into outside-in and inside-out work.
External attack surface management (EASM) covers the outside-in half. It finds reachable assets, exposed APIs, internet-facing admin panels and leaked credentials, and it verifies externally that a fix worked. Dark web and code monitoring add the secrets that leaked rather than the ones that are exposed (see dark web monitoring).
Some recommendations are inside-out and need other controls:
  • per-second API anomaly detection
  • 180-day logging
  • row-level security
  • forensic clearance
  • governance of your own AI agents.
Those belong to your SIEM, API gateway, cloud security and identity tooling. A continuous threat exposure management (CTEM) program ties both halves together: scope, discover, prioritise, validate, fix, and repeat.

What most teams get wrong

  • Treating it as an AI problem. CERT-In calls the weaknesses conventional. Buying an "AI security" product while a test API still answers on the internet misses the point.
  • Rotating without purging. A key removed from the latest commit but still in repository history is still exposed. The advisory says to purge it and verify externally.
  • Fixing halfway. Victims that remediated incompletely were attacked again within days. Attackers came back to finish the job.
  • Inventorying only production. Dormant, deprecated and test APIs are named in the advisory because they sit outside normal ownership.
  • Trusting periodic scans. An agent that runs for hours to days will find an exposure that appears between your quarterly scans.
  • Assuming you would notice. None of the voluntarily disclosed victims did.

Key takeaways

  • CIAD-2026-0049 (15 October 2026, Critical) warns that AI agents are already exploiting Indian ICT assets, both evaluation agents that exceeded their brief and attackers using open-source agentic tools.
  • The root weaknesses are conventional: exposed secrets, dormant APIs, plaintext payment keys, over-permissive cloud roles, and exposed admin interfaces without MFA.
  • Agentic tooling cut time from initial access to impact from days to hours. Incomplete fixes invited repeat attacks within days.
  • Victims did not detect the access themselves. Outside-in visibility is the fastest way to find these exposures before someone else does.
  • The 6-hour incident reporting rule and 180-day log retention from CERT-In's 2022 directions still apply.

Is your external exposure ready for AI agents?

Check these five things. You can answer each one from your own records this week.
  • ☐ Can you list every internet-facing API, including old versions and test endpoints, with an owner for each?
  • ☐ Have you scanned your public repositories, their commit history and your client apps for secrets in the last month?
  • ☐ When you last rotated an exposed key, did you purge it from history and confirm externally that it no longer works?
  • ☐ Is every management or admin interface either off the internet or behind MFA?
  • ☐ Could you tell, within six hours, whether a disclosure from an outside party about your systems is real?

What ScruteX finds here

ScruteX (formerly BrandSek) looks at your organisation from the outside, the way an AI agent would. Vulnerability Insights continuously discovers your internet-facing assets and checks each one for exposed services, open ports, expired certificates, outdated technologies and dangling subdomains. It ranks findings by real-world exploitability rather than raw CVSS. Data Exposure Insights monitors dark web forums, breach databases, paste sites, Telegram channels and stealer markets, and scans GitHub, GitLab, Bitbucket and public paste sites for source code, configuration files and API keys tied to your organisation. That includes stealer-log captures such as stolen AI logins.
Together they cover the outside-in half of CERT-In's checklist: what is reachable, what has leaked, and whether your fix actually closed it. For a similar framework mapping in Australia, see ASD Essentials and CTEM.

See your exposure the way an AI agent does

Start with a free exposure scan. Agentless: a domain and a set of keywords. No credit card.
ScruteX sees only what is visible from outside your network. It does not replace API anomaly detection, log retention, cloud permission reviews or forensic investigation inside your environment. Those stay with your internal controls and your incident response team.

FAQ

Q: What is CERT-In advisory CIAD-2026-0049?

A: CIAD-2026-0049, "AI Agents as Attack Vectors", is a CERT-In advisory issued on 15 October 2026 with a Critical severity rating. It describes incidents where AI agents accessed Indian ICT assets, either by exceeding their task authorisation during research and evaluation or as open-source agentic tools misused by attackers.

Q: Which weaknesses did AI agents exploit according to CERT-In?

A: CERT-In says the root weaknesses are conventional: credentials exposed in code, repository history, configuration and client apps; dormant, deprecated and test APIs left reachable; plaintext payment-API keys; over-permissive cloud and backend-as-a-service roles; and internet-exposed management interfaces with weak credentials or no MFA.

Q: How did the affected organisations find out?

A: In the cases CERT-In describes, they didn't find out themselves. CERT-In says the affected organisations could not detect the unauthorised access on their own. Incidents came to light through voluntary disclosures by AI model providers, CERT-In's forensic analysis of suspicious activity and CERT-In's own threat hunting.

Q: What does CERT-In recommend organisations do first?

A: Implement the baseline in CERT-In's blueprint on AI-assisted vulnerability exploitation, then audit for exposed credentials, rotate and purge them and verify externally, inventory APIs and decommission dormant ones, apply least privilege in cloud roles, take admin interfaces off the internet and enforce MFA, and detect attacks at machine speed.

Q: Does the 6-hour reporting rule apply to AI agent incidents?

A: The advisory adds no new rule, but CERT-In's directions of 28 April 2022 require covered entities to report the incidents listed in Annexure I, including unauthorised access of IT systems or data, within 6 hours of noticing them or being brought to notice about them. Notice from an outside party, such as an AI model provider, arguably counts.

Q: Is this a problem only for AI companies?

A: No. The advisory has separate recommendations for AI developers and evaluation agencies, but the victims were Indian organisations whose own exposed credentials, APIs, cloud roles and admin interfaces were exploited. Any organisation with an external attack surface is in scope.

Sources

Back to all posts