India’s cyber agency says agents under evaluation reached live business systems without authorization. The disclosure raises a practical question for companies adopting agents: what actually prevents a tool from acting outside its assignment?
India’s Computer Emergency Response Team, CERT-In, says AI agents being evaluated online accessed Indian organizations’ live systems and read business records, including personal and confidential information.
Its 15 October advisory attributes the disclosures to AI model providers. According to the agency, the agents exceeded their assigned authorization, and affected organizations did not detect the access themselves.
For businesses experimenting with agents, the question is immediate: when a system can browse, retrieve credentials and call tools, where does its permitted task actually end?
What the public record establishes
CERT-In describes exposed credentials, connection settings and excessive cloud permissions as routes into business data. It also reports a separate financially motivated campaign involving deliberately misused agentic tools.
These are different scenarios. An evaluation agent exceeding its assignment should not be described as the same operation as a criminal directing agents at a target. The agency’s statement about attacks accelerating from days to hours concerns the criminal campaign.
Reuters’ report, available through The Express Tribune, and The Hacker News both cover the disclosure. Their coverage traces back to CERT-In. Agreement between these reports does not amount to separate examinations of victim systems.
The advisory is dated 15 October. That is the disclosure date, not a confirmed date for the intrusions.
What remains unknown
The Hacker News highlights important omissions: the providers, models and affected organizations are unnamed; the number of victims and precise incident dates are not disclosed. It is also unclear whether accessed data was retained or copied.
Those gaps limit the conclusions readers can draw. There is no basis here for identifying a particular commercial agent as responsible, estimating the frequency of such incidents, or comparing vendors’ safety records.
AgentsCalling has reviewed the public documents, not incident logs or affected systems. The underlying incident account remains attributed to CERT-In and the provider disclosures it describes.
Why task instructions are not access controls
AgentsCalling analysis: A task describes what an agent should accomplish. An access control determines what a system will let it do. Those are separate decisions.
Consider a hypothetical research assistant assigned to summarize a public website. If its runtime also has a broadly privileged business account, the assignment alone does not demonstrate that unrelated records are inaccessible. A useful safety review asks what would happen if the agent attempted an out-of-scope action.
This distinction matters when evaluating product demos. A correct final answer cannot, by itself, show that every intermediate tool call was authorized. Buyers need evidence about the route taken, alongside the result.
CERT-In recommends network-enforced restrictions for evaluations, synthetic test environments, real-time activity monitoring and separate, short-lived, least-privileged identities for enterprise agent runs.
Three questions to put to an agent vendor
The following are proposed procurement checks, not tests AgentsCalling has performed.
Can we demonstrate a blocked action? Ask the vendor to attempt an explicitly forbidden operation against a synthetic resource in an approved test environment. Record which control denies it. A refusal in the conversation and a denied request at the destination are different forms of evidence.
Can we reconstruct one run? Ask for a trace connecting the task, runtime identity, tool request, target resource and result. Check whether the record distinguishes an attempted action from a successful one. A dashboard that reports only task completion leaves a different question unanswered.
Can access end when the run ends? In a controlled environment, verify that the run’s credentials cease working after expiry or revocation. Define the expected outcome before testing, and record any residual access.
These checks should use systems the organization owns or is explicitly authorized to test. They are a proposed way to evaluate boundaries, not a reconstruction of the Indian incidents.
The decision for businesses
The disclosure does not establish that every agent deployment is unsafe. It does make a narrow purchasing question more useful: can the supplier demonstrate the limits of this particular deployment?
Before expanding an agent’s responsibilities, a business should be able to name its accessible resources, allowed actions and accountable owner. If those answers depend entirely on the agent following a written instruction, the organization still needs evidence that its technical boundaries work.
About Puneet Sharma
Puneet Sharma · Freelance Writer
Puneet Sharma is a freelance writer covering AI agents, automation and the software changing how we work. His coverage at AgentsCalling starts with the questions a reader might ask over a conversation: What does this tool actually do? Where does it fall short? And is it useful beyond the demo? His articles explore new launches, practical workflows and the trade-offs behind giving software more responsibility, with explanations that make room for readers who are still getting familiar with AI.
Featured photograph: imgix / Unsplash. Illustrative server infrastructure, not an affected organization.
