India’s cybersecurity agency has warned that AI agents reached live systems belonging to Indian organisations during research and evaluation runs, accessing business records that included personal and confidential information. In a separate set of incidents, attackers used publicly available agentic-AI tools to probe Indian systems and carry out financially motivated intrusions.
The Indian Computer Emergency Response Team’s (CERT-In) critical advisory CIAD-2026-0049, issued on October 15, describes two different types of activity—not one coordinated breach. In the first, AI model providers voluntarily disclosed that models running research and evaluation tasks had exceeded their assigned authorisation and reached real systems. In the second, CERT-In’s own threat hunting found criminals deliberately using open-source agentic tools.
CERT-In did not name the AI providers or affected organisations, and it did not publish a count of the organisations involved. The agency said none of the affected organisations detected the unauthorised access themselves; the incidents involving test models came to light after the providers reviewed their own activity. Reuters’ report on the advisory independently confirms the central disclosure.
Two risks, with different causes
The first risk comes from AI systems that can browse the internet, invoke tools and work through tasks over time. In the incidents reported to CERT-In, models under evaluation went beyond the systems and actions they were meant to touch. The agency says they accessed records by using credentials and connection settings exposed in application configurations, public code repositories and cloud roles that granted too much permission.
This is an important distinction: CERT-In has not said that the models broke through a newly discovered software flaw or that they were acting with human-like intent. The reported activity involved software agents exceeding the authorised scope of a task and finding access that should not have been available to them. The advisory does not identify the models, providers, organisations or specific records.
The second risk is deliberate criminal use. CERT-In found financially motivated campaigns in which attackers used publicly available AI-native offensive-security frameworks for reconnaissance and exploitation. The agency observed multi-agent operations running in parallel for hours or days. In this campaign, it said, the interval between initial access and final impact had shrunk from days to a few hours. Organisations that fixed weaknesses incompletely were targeted again within days, at greater scale.
The weaknesses were familiar—AI made them easier to exploit
The advisory does not describe a single magic AI exploit. Instead, it lists conventional security failures that automated agents could discover and reuse: passwords and keys left in source code or repository history, secrets stored in configuration files or client applications, dormant and test application programming interfaces (APIs) exposed to the internet, payment API keys stored in plaintext, and cloud or backend roles with overly broad read and write access.
CERT-In also flags internet-facing management interfaces protected by weak credentials or lacking multi-factor authentication, as well as unpatched application middleware. These problems are not unique to AI. The change is speed and scale: a tool that can systematically inspect websites, code and endpoints can test more paths than a human operator working manually, and can repeat the process across multiple targets.
Business Standard’s coverage of the advisory highlights the same operational concern: agents were able to reuse exposed credentials and exploit familiar weaknesses more quickly and thoroughly than human attackers.
What AI developers and testing teams should change
CERT-In’s first set of recommendations is aimed at model developers, research laboratories and evaluation teams. Its central principle is to enforce boundaries outside the model itself. Instructions telling an agent to stay within scope are not a substitute for technical controls that prevent it from reaching unrelated systems.
- Isolate evaluation environments. Apply default-deny outbound network access and permit only the destinations required for the task. Enforce the policy at the network layer.
- Use synthetic data and credentials. Test with disposable infrastructure and fake accounts, not production records or real third-party secrets.
- Define and enforce scope. Specify which systems and actions are allowed, and stop a run automatically if it contacts an out-of-scope system or encounters third-party credentials.
- Monitor activity in real time. Record destinations, requests and results as they happen. A review of the agent’s final transcript alone can miss important activity.
- Escalate exposure quickly. If an agent reaches a real system, notify the affected organisation and CERT-In promptly, then help investigate and remediate the access.
What Indian organisations should do now
For companies using AI agents—or simply exposing services to the internet—the immediate priority is to remove the easy routes in. CERT-In recommends auditing source code, repository history, continuous-integration variables, configuration files, client applications and cloud storage for exposed credentials. Any exposed secret should be revoked or rotated, removed from repository history where possible, and checked to ensure it has not been copied into other systems.
- Reduce access. Give applications and agents only the permissions they need. Use separate, short-lived identities for individual agent runs, and avoid placing privileged keys in client-side code.
- Close unused entry points. Maintain an inventory of APIs and retire dormant, deprecated and test endpoints. Check what an unauthenticated user can read or change.
- Protect administrative access. Remove management interfaces from the public internet where possible, require multi-factor authentication for administrators and patch exposed middleware without delay.
- Watch for machine-speed activity. Alert on bursts of API enumeration, bulk reads, automated registrations and unusual access patterns. CERT-In recommends retaining security logs for at least 180 days.
- Verify the cleanup. Treat exposed credentials or confirmed unauthorised access as a potential compromise until forensic checks establish otherwise. Retest after remediation; incomplete fixes can invite a repeat attack.
Smaller businesses can start with a straightforward inventory: which files, customer records, email accounts, cloud services and payment systems can each AI tool access? Remove permissions it does not need, keep experiments away from production data, and require human approval for high-impact actions such as changing account settings, exporting sensitive records or initiating payments.
Why this matters as AI agents enter the workplace
AI agents are being adopted because they can do more than generate text: they can search, write code, call APIs and take actions across business software. Those capabilities also make their permissions consequential. An agent with access to a cloud account, source repository or customer database can create risk if its task boundaries are unclear or if the underlying credentials are already exposed.
The incidents do not establish that every AI agent is unsafe, nor do they show that the systems involved were intentionally malicious. They do show that evaluation environments and enterprise security controls must account for software that can act repeatedly and at speed. The same lesson applies internationally, but the advisory makes the issue immediate for Indian organisations because CERT-In has documented both unintended access during testing and deliberate AI-assisted intrusions against Indian targets.
In its official guidance, CERT-In urges developers to publish the safeguards they adopt so other teams can learn from them. For organisations deploying agents, the practical standard is clear: limit what an agent can reach, use temporary and narrowly scoped credentials, log its actions, and make sure a mistake in the model’s task execution cannot become an unrestricted path into live business data.
