A chatbot answers a question.
An AI agent may answer the question, open a file, search a database, call an API, send a message and decide what to do next.
That difference matters for security.
The more an AI system can act, the less useful it is to think about security only at the model level. The agent’s identity, permissions, tools, memory, external data and surrounding software all become part of the attack surface.
This is why agent security has become a serious topic in 2026. OWASP has published a Top 10 specifically for agentic applications, and NIST’s Center for AI Standards and Innovation has been studying security considerations for AI agent systems.
What is an AI agent?
There is no single product design that defines every agent, but the general idea is an AI-enabled system that can work toward a goal and take actions using tools or connected services.
An agent might:
- read email
- search documents
- browse websites
- query a database
- create or update files
- call business APIs
- run code in a controlled environment
- create support tickets
- schedule tasks
- interact with other agents
Some agents require confirmation for each important action. Others are designed to operate with more autonomy.
From a security perspective, the important question is not whether the product uses the word “agent”. It is what the AI can access and what it can do.
Why agents change the risk
A normal LLM application may produce a bad answer. That can still matter, but the effect is usually limited to the output.
An agent can turn a bad decision into an action.
Imagine an assistant that reads an untrusted webpage and also has access to a company document store. If content on that webpage can redirect the agent, the problem is no longer just inaccurate text. It can become a data-access or tool-misuse problem.
NIST has studied this as agent hijacking, a form of indirect prompt injection where malicious instructions in external content influence an agent.
1. Agent goal hijacking
OWASP’s agentic security guidance uses the term Agent Goal Hijack for attacks that redirect an agent from its intended objective.
The malicious instruction may come from content the agent is expected to process normally.
For example, an agent researching websites might encounter text that attempts to change its task. An email-processing agent might read hostile instructions inside an email.
This is closely related to indirect prompt injection.
The important point is that external data can contain instructions from an attacker, even when the user never typed those instructions directly.
2. Tool misuse
Tools make agents useful, but every tool creates power.
A calendar tool can create events. A file tool can modify documents. A cloud tool may change infrastructure. A shell tool may execute commands.
If the agent is manipulated, confused or simply wrong, those same tools can be used in unintended ways.
A good security design should therefore make each tool narrow and predictable.
Do not give a model a general “do anything” interface when a small set of specific functions will do.
3. Identity and privilege abuse
Every action happens under some identity.
An agent may use:
- a service account
- an API token
- a user’s delegated session
- a cloud identity
- a database account
- an application-specific role
If that identity has broad privileges, the agent inherits those privileges.
This is a classic least-privilege problem, but agents make the consequence more obvious because a language model is deciding when to use the access.
A useful rule is:
The agent should not have more authority than the task requires.
For sensitive workflows, it may be better to create separate identities for separate tools rather than giving one agent account broad access everywhere.
4. Agentic supply-chain risk
Agents depend on more than the model.
They may use third-party tools, plug-ins, libraries, hosted APIs, remote services, models and externally maintained integrations.
OWASP’s 2026 agentic guidance includes Agentic Supply Chain Vulnerabilities as a major risk area.
Organizations should know which components an agent depends on, how those components are updated, what data they receive and what permissions they are granted.
A trusted model connected to an untrusted tool is not a trusted system.
5. Unexpected code execution
Some agent workflows can generate or run code.
This can be useful for data analysis, automation and development. It can also be dangerous.
Generated code should not automatically receive unrestricted access to the host operating system, secrets, production networks or sensitive files.
Where code execution is genuinely required, a sandboxed or otherwise strongly isolated environment is much safer than giving the agent a normal production shell.
6. Memory can become a security problem
Agents may store conversation history, preferences, summaries, task state or other memory.
That creates several questions:
- Who can write to the memory?
- Who can read it?
- How long is it kept?
- Can untrusted content become “remembered” as a trusted fact or instruction?
- Can one user’s data influence another user’s session?
- Can sensitive information be removed later?
Memory should be treated as data with a lifecycle, not as a harmless convenience feature.
7. Human trust can be exploited
People tend to trust systems that are helpful, fluent and familiar.
An agent can create a false sense of confidence because it appears to understand the task.
OWASP includes Human-Agent Trust Exploitation in its agentic risk model. This is a useful reminder that security controls should not depend on a user noticing that an AI-generated action “looks suspicious”.
Interfaces should make high-impact actions visible and understandable before they happen.
Practical controls for AI agents
The good news is that many useful controls are familiar cybersecurity practices.
Use least privilege
Give each tool and identity only the permissions required for the task.
Read-only access is preferable when write access is not necessary.
Separate reading from acting
An agent that reads untrusted external content should not automatically be able to perform high-impact actions based on that content.
A useful design is to let the agent prepare a proposed action, then pass it through another policy check or human approval step.
Require approval for sensitive actions
Examples include:
- sending external messages
- deleting or overwriting data
- changing permissions
- executing code
- modifying production systems
- financial transactions
- sharing confidential information
The exact list depends on the application.
Treat external content as untrusted
Webpages, emails, documents and user-generated content can all carry malicious instructions.
Tagging data by source and trust level can help the application enforce stronger rules outside the model.
Validate tool parameters
The model may choose a tool, but the application should still validate what the model asks the tool to do.
Check resource identifiers, destinations, file paths, URLs, commands and other high-risk parameters before execution.
Isolate code execution
If an agent must run code, use an environment designed for that purpose with strong restrictions on files, network access, credentials and persistence.
Protect secrets
Do not place raw credentials in the model context.
Use backend services and secrets-management systems so the application can authenticate without revealing the secret to the model.
See my guide on protecting sensitive data and API keys when using AI tools.
Keep useful audit logs
For important agent actions, record enough information to reconstruct what happened.
Useful events may include the user request, tool selected, identity used, target resource, policy decision, approval and final result.
Avoid logging sensitive values in plaintext.
Make actions reversible where possible
If an agent can make changes, design recovery.
Draft before send. Move to trash before permanent deletion. Use versioning. Keep rollback points for configuration changes.
Good recovery design reduces the cost of both attacks and ordinary mistakes.
Agents should not be trusted like employees
It is tempting to describe an AI agent as a digital employee.
That metaphor can be useful for explaining the idea, but it is dangerous for security design.
A human employee has judgement, accountability, social understanding and legal responsibility. An AI system does not have those qualities simply because it can follow a workflow.
Treat the agent as software with probabilistic decision-making and access to tools.
Then design controls around what the software is allowed to do.
The security question to ask before deploying an agent
Before giving an AI system a new tool, ask:
If the model makes the worst reasonable decision at the worst reasonable time, what can this tool allow it to do?
If the answer is uncomfortable, reduce the permission, add a policy check, require confirmation or redesign the workflow.
Agentic AI can be genuinely useful. Security does not require removing all autonomy. It requires making sure autonomy has boundaries.
For the wider context, read what AI security means in 2026.