Artificial intelligence (AI) agents can do more than answer questions. They may use tools, run commands, access online services, and complete multi-step tasks. That makes them useful, but it also creates a security riska: an agent may exceed its intended permissions, or a criminal may use agentic tools to speed up an attack.
On 15 October 2026, India’s Computer Emergency Response Team (CERT-In) warned about incidents involving AI agents accessing Indian organisations’ live systems without authorization. Some activity was disclosed by AI providers after their own reviews; other incidents involved attackers deliberately using open-source agent tools. CERT-In said affected organisations had not detected the unauthorized access themselves. The advisory did not name the organisations or providers. Read the CERT-In advisory.
How can an AI agent become a security risk?
An AI agent is software that can plan actions and use tools to pursue a goal. For example, it might query a database, call an application programming interface (API), or run a command. An agent does not need to “turn evil” for this to become dangerous. A poorly limited task, excessive permissions, exposed credentials, or a compromised tool can allow it to perform actions its operator did not authorize.
CERT-In identified familiar weaknesses behind the incidents it observed, including keys and passwords exposed in code or configuration files, old APIs left accessible, overly broad cloud permissions, and management interfaces with weak protection. The concern is not that AI creates every vulnerability; it can find and exploit existing weaknesses faster and at greater scale
What should investigators examine?
The first task is to establish what happened, not to accept the agent’s explanation of its own actions. Investigators should identify the systems involved and preserve relevant records before routine retention periods erase them.
Useful evidence may include:
- Identity and access logs: which user, service account, or agent identity authenticated, and what resources it accessed.
- Cloud and application logs: database queries, file access, API calls, permission changes, and administrative actions.
- Endpoint and network records: process execution, outbound connections, Domain Name System (DNS) requests, and transfers of data.
- Agent and orchestration logs: prompts, tool calls, task history, configuration, and the approvals or restrictions applied.
- Credential and configuration records: where a key was stored, which permissions it granted, and whether it may have been exposed.
Not every system records all these events. Investigators should document gaps, time zones, clock differences, and whether logs could have been altered. A transcript or agent-generated summary can help guide the inquiry, but it should be checked against independent system records.
How to reconstruct the incident
Start by recording the time the incident was detected and the systems that may be affected. Preserve logs, relevant configurations, and available agent records in a way that maintains their integrity. Where practical, calculate cryptographic hashes and record who collected each item, when it was collected, and how it was stored.
Next, build a timeline. Correlate authentication events, tool calls, API requests, process activity, and data access. Check whether an action was within the agent’s assigned task and permissions, and determine whether a human approved it. Look for signs of credential misuse, lateral movement, repeated access, or data leaving the environment.
Separate confirmed facts from hypotheses. An unusual agent action does not, by itself, prove malicious intent or identify who was responsible. The agent may have exceeded its scope, a person may have misused it, or an attacker may have compromised the surrounding system. Attribution requires corroborating evidence.
What organisations should do now
Prevention and investigation depend on many of the same controls. Give agents only the access needed for a specific task, use distinct identities for agents and people, and require additional approval for sensitive or irreversible actions. Keep secrets out of source code, remove unused APIs, protect administrative interfaces with strong authentication, and monitor agent tool use as well as ordinary account activity.
Guidance published by the US Cybersecurity and Infrastructure Security Agency and partner agencies in May 2026 similarly recommends limiting agent autonomy, applying layered defenses, maintaining oversight, and monitoring activity. Read the joint guidance announcement.
The forensic takeaway
AI agents can change the speed and scale of cyber incidents, but the investigative fundamentals remain the same: preserve reliable evidence, reconstruct events from multiple sources, test explanations against system records, and clearly document uncertainty. The aim is not simply to prove that an AI agent was involved. It is to establish what it did, which controls failed, what information was affected, and what the evidence can—and cannot—prove.