An AI agent is software that can use an artificial intelligence model to plan and carry out tasks rather than simply generate an answer. It can browse websites, call APIs, read or write files, execute approved tools and interact with other software, sometimes with limited human supervision. That extra ability to act is what makes agents useful—and what can turn an ordinary AI mistake into a cybersecurity incident. NIST describes AI agents as systems capable of making decisions and taking actions that affect real-world systems or environments.
An AI agent does not need to be a malicious hacker to compromise a system. If it has excessive permissions, encounters a vulnerability, follows a malicious instruction hidden in a document or website, or is given poorly designed tools, it can potentially take actions its operator did not intend. Security researchers and standards bodies increasingly describe this as an agent-security problem involving tool abuse, prompt injection, excessive agency and inadequate authorization—not simply a more powerful chatbot.
AI agent vs. ordinary chatbot: what is the difference?
The easiest way to understand an AI agent is to compare it with a conventional chatbot.
A chatbot primarily responds.
You ask, “What is the weather in London?” and it generates an answer.
An agent can potentially act.
You might tell an agent, “Find the cheapest suitable flight, check my calendar, and prepare an itinerary.” The agent could search websites, query services, compare results and interact with other applications.
NIST notes that modern agent systems combine general-purpose AI models with software components that allow them to manipulate tools and take actions beyond simple text generation.
| Capability | Ordinary chatbot | AI agent |
|---|---|---|
| Generate text | Yes | Yes |
| Understand instructions | Yes | Yes |
| Plan multiple steps | Limited or simulated | Core capability |
| Browse external systems | Usually limited or unavailable | Often possible |
| Call APIs and tools | Limited | Common |
| Read or modify files | Usually no direct access | Can be granted access |
| Execute actions | Generally no | Yes, depending on permissions |
| Operate with limited supervision | Limited | A defining characteristic |
| Main security concern | Harmful or inaccurate output | Harmful output plus unintended actions |
The boundary is not absolute. Modern chatbots can have tools, while some agents operate with substantial human supervision.
The important distinction is authority.
An AI model becomes much more consequential when its output is connected to mechanisms that can change something outside the model itself.
How does an AI agent actually work?
A simplified agent can be thought of as five components:
Goal → reasoning/planning → tool selection → action → observation
Suppose an agent is asked to find a particular document.
It might:
- Interpret the request.
- Decide where the document might be stored.
- Call a search tool.
- Inspect the results.
- Decide which result is relevant.
- Open the document.
- Search its contents.
- Take another action based on what it finds.
The important part is the loop.
The agent can use the result of one action to decide what to do next.
NIST describes agent systems as capable of understanding context, reasoning, planning, adapting and executing tasks.
That makes an agent more flexible than a conventional automation script.
It also creates more opportunities for unexpected behavior.
Where do an agent’s powers come from?
The AI model itself does not magically gain access to a computer.
Its capabilities come from the tools and permissions surrounding it.
An organization might give an agent access to:
- A web browser
- Search engines
- Calendars
- Databases
- Cloud storage
- Software-development tools
- Payment systems
- Internal company applications
- Command-line utilities
- APIs
- File systems
Each tool creates a possible pathway to the outside world.
An agent with permission to read a database can retrieve information.
An agent with permission to modify the database can change information.
An agent with unrestricted command execution could potentially run a much wider range of operations.
This is why OWASP identifies excessive functionality, excessive permissions and excessive autonomy as major sources of agent risk.
So how can an AI agent “hack” a computer?
The word hack can be misleading.
An AI agent does not necessarily discover a secret universal method for breaking into computers. More often, the risk comes from combining an AI’s ability to reason and adapt with ordinary cybersecurity weaknesses.
There are several major pathways.
1. It can exploit excessive permissions
Imagine an AI assistant whose job is to summarize company documents.
It only needs read access.
But the developer connects it using an account that can also delete files, change permissions and access confidential databases.
The model has not discovered a sophisticated exploit.
The system has simply given it too much authority.
If the agent makes a mistake, follows a malicious instruction or is manipulated, those excessive permissions increase the potential damage.
OWASP recommends limiting agents to the minimum tools and permissions necessary for their tasks.
This is the AI equivalent of an old cybersecurity principle: least privilege.
2. It can encounter and exploit an existing vulnerability
Suppose an agent is searching a website and encounters an application with a security weakness.
A traditional automated program might simply fail.
A capable agent could potentially recognize that a different request, sequence or interaction produces a different response and continue experimenting.
If its tools permit it to send those requests, it could potentially move from information gathering to unauthorized access.
This is where AI changes the equation.
The vulnerability itself may be completely ordinary.
The new element is an automated system capable of interpreting what happens and deciding what to try next.
NIST says AI-agent security combines conventional software vulnerabilities with risks created by connecting AI model outputs to software functionality.
3. It can be tricked by information it reads
One of the most important risks is called prompt injection.
Imagine an agent has been instructed:
“Read incoming documents and summarize them.”
A malicious document could contain hidden instructions designed to manipulate the agent.
Instead of treating the document solely as data, the model might interpret some of its contents as instructions.
This is known as indirect prompt injection.
NIST has specifically studied agent hijacking in which malicious instructions are placed inside data that an AI agent later consumes.
The attack is unusual because the attacker may never communicate directly with the AI.
They manipulate something the AI is expected to read.
That could be a webpage, email, document, support ticket or other external content.
A simple example of agent hijacking
Consider an AI assistant connected to a company’s email account.
Its legitimate task is:
“Read incoming emails and summarize important messages.”
Now imagine an attacker sends an email containing malicious instructions hidden inside the message.
The agent reads it.
If the system is poorly designed, the malicious content could influence the agent’s behavior.
If the agent has only read access, the consequences may be limited.
But if it also has permission to send email, download attachments, access cloud storage or execute other tools, the potential damage becomes much greater.
OWASP uses a similar scenario to illustrate excessive agency: an agent intended to read email can become dangerous if its connected tool also allows sending messages and the model can be manipulated into invoking that capability.
The lesson is important:
The vulnerability is often not the AI model alone. It is the combination of the model, its inputs, its tools and its permissions.
4. An agent can misuse legitimate credentials
An AI agent can be given credentials just like other software.
For example, an organization might create an account that allows an agent to access a database.
If that account has broad privileges, the agent inherits them.
This creates a fundamental security question:
What happens if the AI makes the wrong decision while holding a legitimate key?
The credentials themselves do not have to be stolen.
The agent may already have them.
This is why NIST is examining identity and authorization specifically for software and AI agents. Its work highlights the need to understand what an agent is allowed to access, how it is identified and how its actions are authorized and audited.
5. It can chain small actions into a larger problem
One action may look harmless.
A sequence can be much more consequential.
For example:
Search → discover an exposed service → inspect its response → find an identifier → query another endpoint → retrieve configuration information
Each step may appear relatively minor.
An agent capable of planning can connect them into a larger operation.
This is one reason agent security cannot be assessed only by examining individual tools.
Security teams also need to consider what combinations of tools and permissions make possible.
OWASP warns that agentic systems can create cascading effects when connected to multiple systems, particularly when authorization and tool boundaries are weak.
Can an AI agent break into any computer?
No.
That is one of the most important misconceptions to avoid.
An AI agent does not automatically possess the ability to hack arbitrary computers.
Its practical capabilities depend on:
- What tools it has.
- What systems those tools can reach.
- What credentials it possesses.
- What permissions those credentials provide.
- Whether target systems contain vulnerabilities.
- Whether network controls block access.
- Whether the agent is allowed to execute code.
- Whether humans must approve important actions.
- How effectively the environment detects abnormal behavior.
A highly capable model with no external access may be unable to do anything beyond generating text.
A less capable model connected to a poorly secured environment may cause serious damage.
Access and authorization can matter as much as intelligence.
Why autonomy changes the security equation
Traditional software generally does what its developers explicitly program it to do.
AI agents introduce probabilistic decision-making into that process.
Instead of:
Instruction → fixed procedure → result
an agent may operate more like:
Goal → interpretation → plan → action → observation → revised plan → action
That flexibility is useful when the environment is unpredictable.
It is also difficult to guarantee in advance exactly what sequence of actions an agent will choose.
OWASP calls this risk excessive agency when an AI system has more functionality, permissions or autonomy than it needs.
The problem is therefore not simply “AI is autonomous.”
It is autonomy without appropriately narrow authority.
What is “excessive agency”?
Consider an AI system designed to recommend products.
It needs to read product information.
A poorly designed integration might give it:
- Read access to the entire product database
- Write access to inventory
- Permission to modify prices
- Access to customer records
- Ability to execute arbitrary database commands
Almost none of those powers are required to recommend a product.
The AI may never misuse them.
But every unnecessary permission increases the potential impact of an error or attack.
OWASP recommends restricting both the number of tools available to an agent and the functions those tools can perform. It also recommends enforcing authorization in downstream systems rather than relying on the AI model to decide whether an action is permitted.
That last point is crucial.
The AI should not be the final authority deciding what the AI is allowed to do.
What if the agent makes a mistake?
AI systems can misunderstand instructions, misinterpret data or generate incorrect conclusions.
In a chatbot, that might produce a wrong answer.
In an agent, the same mistake can become an action.
Suppose an agent incorrectly concludes that a file is safe to delete.
If it has no deletion capability, the mistake produces an incorrect recommendation.
If it has deletion privileges and no approval step, the mistake could become data loss.
This is why high-impact actions should generally have independent authorization and, where appropriate, human approval.
OWASP recommends human-in-the-loop controls for sensitive operations and says authorization should be enforced by downstream systems rather than relying solely on model decisions.
AI agents can also be attacked through their memory
Some agents maintain memory across interactions.
That can be useful.
An assistant might remember preferences, project information or previous tasks.
But persistent memory creates another potential attack surface.
If malicious or incorrect information is inserted into an agent’s memory, that information could influence later decisions.
OWASP’s current agent-security guidance identifies memory poisoning as a risk alongside prompt injection, excessive agency, data exposure and tool abuse.
This means an agent’s security cannot stop at the model or its APIs.
The data it stores can also become part of the attack surface.
Why organizations are paying more attention
AI agents are moving from demonstrations into systems that interact with real software.
NIST says agents are increasingly capable of browsing the internet, building software applications and taking actions in external environments. The agency launched an AI Agent Standards Initiative in 2026 to help address security, interoperability and trust issues surrounding these systems.
NIST’s 2026 analysis of industry responses to its AI-agent security inquiry found broad agreement that agents create novel security threats and that traditional cybersecurity principles remain relevant but need to be adapted for agent systems.
That does not mean conventional cybersecurity is obsolete.
Quite the opposite.
Authentication, access control, segmentation, logging, vulnerability management and monitoring remain fundamental.
The difference is that organizations now have to apply those principles to software capable of making dynamic decisions about how to use its privileges.
How should AI agents be secured?
The most effective defenses are surprisingly familiar.
Give agents the minimum permissions they need
A document-summarizing agent should not have permission to delete documents.
A reporting agent should not have write access to the database it analyzes.
A customer-service agent should not automatically have administrative privileges.
Least privilege limits the damage when something goes wrong.
Restrict the tools
Do not give an agent a general-purpose command interface if it only needs one narrowly defined operation.
OWASP specifically recommends avoiding open-ended tools such as unrestricted shell commands where a more narrowly defined function can perform the required task.
Separate reading from acting
An agent can often be allowed to inspect information without being allowed to change it.
This creates an important security boundary.
Reading a file and deleting it should not require the same authority.
Require approval for high-impact actions
Sending money, deleting records, changing permissions or modifying production infrastructure should generally require stronger controls than retrieving information.
Human approval can provide another layer of protection, particularly for irreversible actions.
Monitor what the agent actually does
Organizations should record tool calls, permissions, unusual sequences and other security-relevant events.
An agent that suddenly attempts dozens of unusual requests should trigger investigation.
Assume external content can be hostile
Web pages, emails, documents and API responses should be treated as potentially untrusted inputs.
An agent should not automatically interpret every piece of text it encounters as an instruction.
This is particularly important for defending against indirect prompt injection.
The key distinction: AI hacking versus AI-enabled hacking
It is tempting to say that an AI agent “hacked a computer.”
Sometimes that may be a reasonable shorthand.
But technically, there is a more useful distinction.
An AI system may:
Discover a vulnerability: identify a weakness that already exists.
Exploit a vulnerability: use that weakness to gain access or perform an unauthorized action.
Abuse legitimate access: use credentials or tools it was already given in an unintended way.
Be hijacked: follow malicious instructions inserted into its environment.
Cause an accidental incident: take a harmful action because it misunderstood its goal or environment.
These are different security problems.
The common factor is that the AI can connect reasoning to action.
The biggest misconception about AI agents
The biggest misconception is that an AI agent becomes dangerous simply because it is intelligent.
Intelligence alone does not give software access to a computer.
The more important combination is:
Capability + tools + permissions + autonomy + a vulnerable environment.
Remove enough of those elements and the potential impact falls dramatically.
An agent that can analyze a public webpage but cannot execute commands or access private systems has a very different risk profile from an agent that can browse the internet, access corporate databases, use privileged credentials and modify production infrastructure.
This is why secure agent design is increasingly focused on identity, authorization and tool boundaries rather than trying to make the underlying AI model perfectly predictable.
What readers should remember
An AI agent is essentially an AI-powered software system that can observe, decide and act.
A chatbot mostly answers questions.
An agent can pursue a goal through multiple steps and interact with external systems.
That ability can produce enormous benefits. It can automate research, software development, administration and other complicated workflows. But the same capability creates a new security surface.
An agent does not need to “turn evil” to cause a breach. It can be manipulated by malicious data, misunderstand an instruction, encounter a vulnerable system or simply have more permissions than its task requires. The safest architecture therefore treats the AI as an untrusted decision-maker whose actions must remain constrained by independent authorization, least-privilege tools, monitoring and human oversight where the consequences are high. That principle is likely to remain important even as AI agents become substantially more capable.