AI agents are increasingly moving beyond generating answers. They can access enterprise data, use tools, call APIs, execute workflows, interact with applications and, in some cases, make decisions and take actions with limited human involvement.
That autonomy is what makes them useful—and what makes their compromise potentially serious.
So, can an AI agent “go rogue”?
Not in the science-fiction sense of an AI independently developing malicious intent. The more realistic cybersecurity concern is more straightforward: an attacker can manipulate an AI agent into using its legitimate capabilities for an unintended purpose.
NIST describes AI agents as systems capable of planning and taking autonomous actions that can affect real-world systems or environments, while specifically highlighting the security risks created when AI model outputs are combined with software functionality.
The result can be an AI system that appears to be operating normally while, in reality, its behaviour has been influenced by an attacker.
A conventional AI application might look relatively simple:
Input → AI model → Response
An AI agent introduces considerably more moving parts:
Input → Model → Reasoning → Memory → Tools → APIs → Action
The agent may retrieve information, decide what to do next, invoke a tool and use the result to determine its next action.
That changes the security equation.
If a chatbot produces an incorrect answer, the immediate impact may be limited to misinformation. If an AI agent produces an incorrect decision and has the authority to act on it, the consequences can extend into enterprise systems.
OWASP identifies risks such as agent goal hijacking, tool misuse, identity and privilege abuse, memory manipulation, excessive autonomy and cascading failures as distinct concerns in agentic applications.
The important question, therefore, isn't simply:
“Can someone hack the AI?”
It is:
“What can an attacker make the AI agent do after it has been compromised?”
An AI agent can have multiple attack surfaces, depending on its architecture and the systems it can access.
Prompt injection remains one of the most important attack paths.
An attacker may attempt to manipulate the instructions the agent follows. More concerning for autonomous agents is indirect prompt injection, where malicious instructions are embedded in content the agent retrieves or processes—such as a webpage, document, email or other external data.
NIST has specifically studied agent hijacking through indirect prompt injection, describing scenarios where malicious instructions inserted into data consumed by an agent can cause it to take unintended actions.
The attacker therefore doesn't necessarily need direct access to the agent's system prompt. They may only need to influence information the agent is going to read.
Agents become more powerful when they can use external tools.
An agent might have access to a database query tool, email system, cloud API, code execution environment or business application. If an attacker can manipulate the agent into selecting or using a tool in an unintended way, a seemingly harmless AI interaction can become an operational security problem.
MITRE ATLAS now explicitly tracks agent-focused techniques involving tool invocation, context poisoning and tool poisoning, reflecting the expanding attack surface around agentic systems.
An AI agent often acts using some form of identity and permissions.
If those permissions are broad, compromising the agent can effectively give an attacker access to capabilities that the agent was legitimately granted.
This is one reason excessive agency is such an important concept in AI security. OWASP has long identified excessive functionality, permissions and autonomy as factors that can allow unexpected model behaviour to result in damaging actions.
Agents that maintain memory or persistent context introduce another potential attack surface.
If malicious information becomes part of the context an agent trusts, future decisions may be influenced by that information.
In other words, the compromise may not always be a single malicious instruction. It could involve changing what the agent believes, remembers or considers trustworthy.
This is where the idea of a “rogue AI agent” becomes more realistic.
A hijacked agent does not necessarily look obviously malicious.
It may still:
* authenticate normally,
* access legitimate systems,
* call approved APIs,
* follow its programmed workflow, and
* produce plausible responses.
The difference is that an attacker has influenced the decisions behind those actions.
Imagine an AI operations agent that is authorised to retrieve customer information and update records.
If an attacker manipulates its instructions, the agent may still use the same legitimate credentials and tools. But it could retrieve information it should not expose, modify records it should not change, or trigger workflows outside the original business objective.
The agent does not need to know that it has been compromised.
It may simply believe it is completing its task.
That is what makes agent hijacking fundamentally different from the traditional idea of malware taking control of a machine.
The potential impact depends heavily on what the agent can access and what actions it is authorised to perform.
A compromised agent with access to internal systems could potentially expose confidential information, customer records, employee data, intellectual property, credentials or other sensitive material.
Data leakage may occur through the agent's output, tool calls, API interactions or connected applications. OWASP specifically identifies sensitive data exposure and data exfiltration among the security risks associated with agentic systems.
The consequences can go beyond information disclosure.
An agent with write access could potentially be manipulated into changing records, sending communications, triggering workflows or making other changes through connected systems.
The security concern is amplified when those actions are automated.
If an agent has access to high-value systems, a compromise can turn its legitimate permissions into an attacker's capability.
An attacker may not need to bypass the underlying application's authentication if the agent has already been authorised to access it.
An agent embedded in business processes could potentially disrupt those processes by taking inappropriate actions, repeatedly triggering workflows, consuming resources or interfering with downstream systems.
For organisations using multiple interconnected agents, the consequences could become broader still.
This question deserves a careful answer.
An AI agent is not automatically a computer virus.
Traditional viruses are malicious programs designed to replicate and spread. An AI agent does not inherently possess those characteristics simply because it can act autonomously.
But the more interesting security question is whether a compromised agent can help propagate an attack.
Consider an environment where multiple agents communicate with one another and share access to tools, APIs or enterprise data.
A compromised Agent A could potentially influence Agent B. Agent B may then interact with another system or agent based on that manipulated information.
This creates the possibility of cascading or propagating attacks across interconnected agentic workflows.
OWASP explicitly identifies cascading failures in multi-agent systems as a security concern, while MITRE ATLAS includes agentic techniques across areas such as lateral movement, collection, command and control and impact.
So the immediate concern isn't that AI agents will suddenly become self-replicating viruses.
It is that interconnected autonomous systems could potentially become attack multipliers.
Consider an AI agent used by an enterprise operations team.
It has access to internal documents, customer information, business APIs and communication systems.
An attacker manages to influence the agent through malicious content it processes.
The agent then retrieves information using an authorised tool, passes that information into another workflow and triggers an action through an API.
Nothing necessarily “breaks.”
- The credentials are valid.
- The API is functioning.
- The tools are legitimate.
- The agent is operating.
But the outcome is malicious.
This is the fundamental security challenge with AI agents: the attacker may not need to compromise every system individually. They may be able to manipulate an agent that already has legitimate access to those systems.
The greater the agent's autonomy and reach, the greater its potential blast radius.
The idea of an AI agent “going rogue” makes for a compelling headline, but the real cybersecurity problem is considerably more practical.
An AI agent doesn't need consciousness, malicious intent or an independent desire to cause harm.
It needs access, authority and a pathway through which an attacker can influence its behaviour.
That combination can potentially turn a useful enterprise capability into an attack vector.
As organisations move from AI assistants toward autonomous agents capable of interacting with business systems, the security question is changing.
It is no longer enough to ask whether the AI can generate a harmful response.
Businesses also need to understand:
What happens when the AI can act—and someone else manages to influence those actions?
That is where AI agent security becomes an enterprise cybersecurity issue rather than simply an AI governance concern.
The next question is even more important: How can organisations prevent AI agents from being hacked, hijacked or manipulated in the first place?