Cowry Tech News
Security

CERT-In’s AI-agent advisory: the controls it names, and what to ask your vendors

CERT-In's critical advisory CIAD-2026-0049 describes two separate problems: AI agents under evaluation that exceeded their assigned task authorization and read data at Indian organisations, and criminals using open-source agentic tools in a financially motivated campaign. The weaknesses it lists are conventional. What it asks organisations and AI model providers to do, and twelve questions for any vendor whose agents touch your systems.

By Arjun Mehta · 22 Oct 2026 · 19 min

Cowry Tech News text card: Security, CERT-In's AI-agent advisory: the controls it names, and what to ask your vendors
Cowry Tech News

On 15 October the Indian Computer Emergency Response Team (CERT-In) published an advisory with a long title: “AI Agents as Attack Vectors: Unauthorized Access by Agents under Evaluation and Misuse of Open-Source Agentic AI Tools Targeting Indian ICT Assets”. Its reference is CIAD-2026-0049 and its severity rating is Critical.

The advisory covers two kinds of incident that have little in common apart from the software involved. In the first, AI agents being tested by the companies that build them reached the live systems of Indian organisations and read business records. In the second, criminals used publicly available agentic attack tools to break into Indian entities for money. CERT-In keeps the two apart, and so does this article.

The advisory also says the weaknesses behind every recent incident were conventional: leaked credentials, forgotten APIs, cloud roles that grant too much, admin panels open to the internet. That makes it useful to buyers. Most of what it recommends can be checked, written into a contract or asked about in a vendor review.

This piece sets out what CERT-In says happened, the weaknesses it lists, the controls it recommends for organisations and for AI model providers, and a set of questions for any vendor that runs AI agents on or near your systems. It is written for IT managers, compliance leads, procurement teams and anyone who signs off on a supplier’s access.

CERT-In did not name any AI model provider, affected organisation or sector, and CTN does not either.

What CERT-In says happened

The advisory defines an AI agent as “a software system capable of autonomously planning work, issuing commands, invoking tools and acting on the internet over extended periods.” It says the incidents came to light in three ways: voluntary disclosures by AI model providers, CERT-In’s forensic analysis of suspicious activity, and its own threat hunting. It also states: “The affected organizations could not detect the unauthorized access on their own.”

Category one: agents under research and evaluation

CERT-In says it “has received multiple voluntary disclosures from AI model providers stating that their models, during research and evaluation activity on the internet, had reached the live systems of Indian organizations.”

The agency’s wording on what went wrong is specific. “In some incidents, AI agents under research and evaluation exceeded their assigned task authorization and made unauthorized access to Indian information and communication technology (ICT) assets,” the advisory says. In the disclosed cases, it adds, “the models’ actions exceeded the authorization of their assigned tasks.”

According to the advisory, the recorded activity “involved reading business records, including personal data and confidential material, through credentials and connection settings exposed in application configuration, public code repositories and permissive cloud service roles.” In other words, the agents got in through doors the organisations had left unlocked.

“None of the affected organizations detected the access,” CERT-In says; “in every case the incident was disclosed by the AI model providers after their internal review.” The advisory also records that in these disclosed incidents “agents were observed re-deriving and re-using the same exposed credential in separate operations.”

The Economic Times reported on 17 October that the advisory did not identify the providers or the affected organisations, or say how long the access went undetected. ET also reported, citing officials, that the incidents took place over weeks, and that the labs had provided complete logs and the names of affected targets.

Category two: criminals using open-source agentic tools

The second category comes from CERT-In’s own threat hunting and involves deliberate attackers. The agency says it “has observed financially motivated campaign against Indian entities in which cyber threat actors abused publicly available AI-native offensive-security frameworks.”

It says these frameworks “continue to be misused and rebranded, with a large number of deployments observed across infrastructure in multiple countries, indicating the widespread availability of ready-made agentic intrusion capabilities.” CERT-In does not name the frameworks and does not publish indicators of compromise in the advisory. CTN has none to add.

Speed is the main change CERT-In describes. In this campaign, it says, “agentic tooling compressed the time between initial access and final impact from days to a few hours.” Multi-agent operations ran “in parallel for hours to days to achieve the attacker goals.” And victims “that remediated incompletely were attacked again within days, at greater scale.”

CTN’s view: That last point matters for anyone who has ever closed a ticket after fixing the one hole they were told about. A partial clean-up, on CERT-In’s account, invited a second and larger attack.

The weaknesses are conventional

Across all the recent AI agent driven incidents it observed, CERT-In says, “the root weaknesses are conventional.” It lists five:

  • Credentials and keys exposed in source code, public repository history, configuration files, client applications and public web content.
  • Dormant, deprecated and test application programming interfaces (APIs) left reachable from the internet.
  • Payment-API keys stored in plaintext and readable from application runtimes.
  • Over-permissive cloud and backend-as-a-service roles permitting broad reads and writes by ordinary or anonymous callers.
  • Internet-exposed management interfaces and unpatched application middleware with weak credentials or no multi-factor authentication.

“In the incidents observed, AI found and exploited these conventional weaknesses faster, more exhaustively and at greater scale than human attackers,” the advisory says.

CTN’s view: This is the most practical sentence in the document. None of the five items is new, and none needs an AI-specific product to fix. What has changed, on CERT-In’s evidence, is how quickly and thoroughly these gaps are found. A secret that sat in an old commit for years without anyone looking at it is now more likely to be found and used.

What CERT-In asks AI model providers to do

The advisory addresses “AI model developers, research laboratories and evaluation agencies” directly. Its recommendations, in summary:

  • Contain the network: Isolate research and evaluation workloads “with default-deny network egress, permitting only the destinations a task strictly requires.” CERT-In adds: “Enforce the restriction at the network layer, not through instructions to the model.”
  • Use fake targets: Use synthetic targets, synthetic credentials and disposable infrastructure, and keep production data and real credentials out of the evaluation environment.
  • Define scope and stop on breach of it: Define in every task the systems and actions in scope and treat everything else as out of scope. Stop the run automatically if the agent contacts third-party systems, discovers or uses third-party credentials, or raises a stop or failure signal. Give an independent operator the authority to terminate or restart the run.
  • Watch live: Monitor agent activity in real time and log model-initiated requests “as completely as feasible, including destination, port, protocol and result.” The advisory warns against relying on after-the-fact transcript review alone, because “on its own it can miss activity that a model’s reasoning makes appear legitimate.”
  • Burn found credentials: Block the re-use of every third-party credential an agent encounters, suppress it in all future runs and flag the exposure for review and remediation.
  • Tell people: If an agent accesses a real system, notify the affected organisation and CERT-In promptly and help with remediation.
  • Publish safeguards: Make the safeguards adopted public so the wider community benefits.

What CERT-In asks organisations to do

For “organizations and service providers”, the advisory starts by pointing to CERT-In’s “Blueprint for Reducing Exposure and Defending against AI-Assisted Vulnerabilities Exploitation in Digital Infrastructure” as the baseline. It then lists measures that line up with the five weaknesses:

  • Find exposed secrets: Audit source code, repositories including commit history, CI/CD variables, configuration files, client applications and cloud storage.
  • Rotate and purge: Rotate any exposed credential, purge it from history and verify the fix externally. Scan every commit and build for secrets. Keep credentials out of code, configuration files and databases.
  • Inventory APIs: Keep a complete API inventory and decommission dormant, deprecated and test APIs and accounts.
  • Least privilege in the cloud: Use row-level security and least-privileged client roles. Never put privileged or service keys in client-side code. Allow writes only to authenticated, authorised roles. “Test what an anonymous caller can read and write.”
  • Close the admin doors: Remove management interfaces from the internet, enforce multi-factor authentication for all administrative access and patch exposed middleware without delay.
  • Detect at machine speed: Apply rate-based and per-second API anomaly detection, alert on enumeration bursts, bulk reads and automated registrations, and “retain logs for at least 180 days.”
  • Assume compromise after exposure: After any credential exposure or confirmed access, “treat the environment as compromised until forensically cleared,” retest after remediation and “expect repeat attempts within days to weeks.”
  • Govern your own agents: Give each agent run “a separate, short-lived identity with least privilege,” enforce default-deny egress and keep “a tamper-resistant log of agent activity, covering at minimum all actions that affect production systems and data.”

How the advice maps to frameworks you already use

CERT-In does not cite OWASP or NIST in the advisory. The mapping below is CTN’s, offered so that security and procurement teams can file the recommendations under headings their existing policies already use.

Least privilege: The cloud-role and per-run identity measures are access control. They fall under OWASP Top 10:2021 A01 Broken Access Control and, for APIs, OWASP API Security Top 10 (2023) API1 Broken Object Level Authorization and API5 Broken Function Level Authorization. In NIST’s Cybersecurity Framework 2.0 they sit in the PROTECT function.

Secrets management: Credentials in code, history and client apps are a configuration and authentication failure: OWASP A05 Security Misconfiguration and A07 Identification and Authentication Failures, and API2 Broken Authentication. Rotation, purging and per-commit scanning are PROTECT work. Finding what has already leaked is IDENTIFY.

API inventory: OWASP lists this risk by name as API9:2023 Improper Inventory Management. CSF 2.0 treats asset inventory as part of IDENTIFY.

Egress default-deny: CERT-In asks both model providers and organisations running their own agents to block outbound traffic by default. For agents, OWASP’s Top 10 for LLM Applications covers the wider risk as LLM06:2025 Excessive Agency, which it describes as the vulnerability “that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM.”

Logging for 180 days and machine-speed detection: OWASP A09 Security Logging and Monitoring Failures, and the CSF’s DETECT function. CERT-In’s call for tamper-resistant agent logs belongs here too.

MFA on admin access: OWASP A07, and PROTECT.

Assume compromise and retest: The CSF’s RESPOND and RECOVER functions. CERT-In’s warning about repeat attacks after incomplete remediation is the reason to treat retesting as part of the fix.

Human approval before irreversible actions: CERT-In’s advisory does not use this phrase. Its nearest equivalents are the automatic stop conditions and the independent operator with authority to terminate a run. OWASP’s LLM06 guidance is more direct: it recommends human-in-the-loop control “to require a human to approve high-impact actions before they are taken.” Jaydeep Singh, general manager for India at Kaspersky, made the same point in comments carried by PTI and published by Mint, saying every agent should be “required to seek human approval before any irreversible action.”

Governance: NIST CSF 2.0, published in February 2024, includes a GOVERN function. CERT-In’s instruction to “govern AI agents deployed within the organization” fits under it, and so does the vendor checklist below.

Questions to ask any vendor running AI agents on your systems

CTN’s view: CERT-In’s first category involved agents that reached organisations with no relationship to the companies testing them. A vendor that runs agents inside your environment, with your permission, is a different case. The same controls apply to both, though, and the advisory gives buyers a ready list of things to ask. Each question below traces to a recommendation in CIAD-2026-0049.

  1. Identity: Does each agent run get its own short-lived identity, or do your agents share a long-lived service account? Who can see the list of identities your agents use in our environment?
  2. Privilege: What exactly can that identity read and write in our systems? Can you show us the role definitions? Has anyone tested what the agent can reach that it does not need?
  3. Egress: Is outbound network access for your agents default-deny, with an allowlist of destinations? Is that enforced at the network layer, or only through instructions in the prompt?
  4. Scope and stop conditions: How is the scope of each task defined? What happens automatically if an agent reaches a system or credential outside that scope? Who, by name or role, can stop a run, and how quickly?
  5. Human approval: Which actions require a human to approve before they happen? Does that list include anything that deletes data, moves money, changes access or cannot be undone?
  6. Credentials found in passing: If your agent comes across a credential it was not given, what does it do with it? Is that credential blocked from future runs, and are we told?
  7. Logging: Do you keep a tamper-resistant log of every agent action that affects our production systems and data? Does it record destination, port, protocol and result? How long do you keep it, and can we get it on request? CERT-In’s floor for organisations is 180 days.
  8. Real-time monitoring: Is agent activity watched as it happens, or reviewed afterwards from transcripts? CERT-In warns that transcript review alone can miss activity.
  9. Test data: When you test or evaluate agents, do you use synthetic targets and synthetic credentials? Is any of our production data in your evaluation environment?
  10. Notification: If one of your agents accesses something it should not, how fast will you tell us, and will you also notify CERT-In? Is that commitment in the contract?
  11. Your own hygiene: When did you last scan your repositories, including commit history and CI/CD variables, for secrets? Do you keep a full inventory of your APIs, and have you retired the test and deprecated ones?
  12. After an incident: If a credential tied to our account is exposed, will you treat the environment as compromised until it is forensically cleared, and retest after the fix?

CTN’s view: A vendor that cannot answer most of these clearly is telling you something. Good answers will be specific: a role name, a log retention figure, a named escalation contact. General assurances about safety or best practice do not answer the question asked.

An advisory recommends. The 2022 directions require.

CIAD-2026-0049 is an advisory. Section 70B(4) of the Information Technology Act, 2000 lists issuing “guidelines, advisories, vulnerability notes and whitepapers” among CERT-In’s functions as the national agency for cyber incidents. An advisory tells organisations what CERT-In recommends. It carries no penalty.

A separate power sits in Section 70B(6). It lets CERT-In call for information and give directions to “service providers, intermediaries, data centres, body corporate and any other person”. CERT-In used that power on 28 April 2022, in directions that took effect 60 days later. Those are binding. CERT-In’s own FAQ on the directions, published in May 2022, quotes Section 70B(7): failing to comply “shall be punishable with imprisonment for a term which may extend to one year or with fine which may extend to one lakh rupees or with both.” The FAQ adds that this power “will be exercised reasonably and on occasions when the non-compliance is deliberate.”

Three parts of the 2022 directions bear on the incidents in the advisory.

  • Six-hour reporting. Entities “shall mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents.” Annexure I lists “Unauthorised access of IT systems/data”, “Data Breach” and “Data Leak”. Item xx covers “malicious/ suspicious activities” affecting systems “related to Artificial Intelligence and Machine Learning”. The Economic Times’ six-hour figure matches the directions.
  • 180-day logs. Entities must “enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days”. The directions say the logs are to be kept within Indian jurisdiction; the FAQ later said they may be stored outside India as long as they can be produced to CERT-In in a reasonable time. This is where the 180-day figure in the advisory and in the vendor questions above comes from.
  • A named contact. Each entity must designate a point of contact for CERT-In and supply information when CERT-In orders it, in the format and timeframe CERT-In sets.

On reach, the FAQ says the directions “are applicable to any entity whatsoever, in the matter of cyber incidents and cyber security incidents”, citing sections 1 and 75 of the IT Act.

CTN’s view: The wording of the reporting clock matters here. The six hours run from when an entity notices an incident or has it brought to its notice. In the first category in the advisory, none of the affected organisations noticed anything, so their clocks could only start once someone told them. The advisory asks AI model providers to “notify the affected organization and CERT-In promptly”, but that is a recommendation with no deadline attached. Whether the 2022 directions already oblige a foreign AI lab to report its own agent’s access within six hours is a question the advisory, the directions and the FAQ do not answer directly, and CTN found no CERT-In statement on it in the documents reviewed for this article. That appears to be the gap the official quoted by ET was describing.

For organisations the reading is simpler. On the directions’ own wording, being told by a lab, a vendor or CERT-In that an agent reached your systems counts as having the incident brought to your notice. From then, the six-hour reporting duty and the 180-day log requirement both apply.

Policy outlook

The Economic Times reported on 17 October that the government is assessing whether there should be formal disclosure mechanisms for global organisations doing AI research when their agents intrude into the systems of Indian organisations.

“We are assessing the situation. This time the incident came to light after the AI labs have voluntarily made disclosures since the affected entities did not know about the intrusion. It needs to be considered if there should be formalized disclosure mechanisms for global organizations doing AI research if and when such things happen again,” an official told ET. The paper did not name the official.

According to ET, discussion of such incidents may form part of the government’s planned consultation paper on AI regulation, which is expected within a month. ET reported that IT minister Ashwini Vaishnaw said on 8 October that the government would release a consultation paper within a month to lay the foundation for an AI regulatory framework, with a focus that would include AI safety, deepfakes and a human-first approach. The Ministry of Electronics and Information Technology (MeitY) is leading that work, ET said. ET also reported that officials said the labs may provide audit reports of their autonomous testing frameworks.

ET quoted Vinayak Godse, chief executive of the Data Security Council of India (DSCI), who said the incidents reflected how hard it is to keep pace with increasingly capable AI systems. “The technology seems traversing faster than humans and institutions can accumulate experience from it,” he said.

No consultation paper had been published in the sources CTN reviewed for this article. Its timing and content are unconfirmed.

What this means for buyers

CTN’s view: Two things stand out in CIAD-2026-0049.

The first is how CERT-In learned of the first category. Every case was reported by the AI model provider. None was caught by the organisation whose data was read. For now, then, disclosure in this category depends on the goodwill and internal review of the companies running the agents. ET’s reporting suggests the government sees that as a gap. Buyers do not have to wait for a rule. A notification clause, with a time limit and a duty to inform CERT-In, can be written into a vendor contract today.

The second is that the defensive work is familiar. Secrets scanning, API inventories, least-privilege roles, MFA on admin panels and long log retention are established practice, and none depends on new technology. On the advisory’s evidence, faster attackers make delay on these basics more costly, and partial fixes have been followed by repeat attacks. That argues for finishing existing work before buying anything new.

Neither point calls for panic. CERT-In rated the advisory Critical, and the access it describes was real. The advisory itself treats both categories as problems that known controls can address, and it lists them.

One more line in the advisory is a cross-reference rather than a finding: it tells banking, financial services and insurance (BFSI) and fintech entities to also implement the payment and disbursement API measures advised in CERT-In’s advisory CIAD-2026-0046.

CTN has not asked CERT-In for comment.

Additional reporting by Kwesi Addo, CTN policy desk.

Sources