As businesses move from AI assistants that answer questions to AI agents that can make decisions, access systems and execute actions, the security conversation has to change.
An AI agent connected to a CRM can update customer records. One connected to email can send messages. A coding agent may access repositories and execute code. An operations agent could interact with cloud infrastructure or business APIs.
That autonomy is the value proposition.
It is also the attack surface.
NIST's recent work on AI agent security notes that agents introduce security challenges because AI model outputs are being combined with software functionality and the ability to take autonomous actions in real-world systems.
The previous question was whether an AI agent could be hacked or hijacked. The more important question for organisations deploying them is:
How do you prevent an AI agent from becoming an attacker’s pathway into the business?
Start With the Agent's Actual Attack Surface
AI agent security cannot begin with the model alone.
An enterprise agent is usually an ecosystem of components:
Model → Instructions → Memory → Data → Tools → APIs → Identity → Enterprise Systems
Each connection can introduce security risk.
For example, an agent may rely on external documents for context, use an API to retrieve customer information and then use another tool to update a CRM. A weakness anywhere along that chain can potentially affect the agent's behaviour or the actions it is capable of taking.
OWASP's Agentic AI security work specifically identifies risks including agent goal hijacking, tool misuse, identity and privilege abuse, supply-chain vulnerabilities, memory and context poisoning, insecure inter-agent communication and cascading failures.
So the first step is simple:
Map what the agent can see, what it can access and what it can do.
Without that visibility, security teams cannot meaningfully assess the agent's risk.
1. Apply Least Privilege to AI Agents
One of the most important principles in AI agent security is also one of the oldest principles in cybersecurity:
An agent should have only the permissions it needs to perform its intended function.
If a customer-support agent only needs to read customer records and create support tickets, it should not also have unrestricted access to financial systems, production infrastructure or employee databases.
Why does this matter?
Because a compromised agent inherits the practical capabilities available to it.
MITRE's ATLAS framework documents how attackers can abuse an agent's existing tool access to invoke APIs, retrieve sensitive information or execute commands through connected services.
The objective should therefore be to minimise the blast radius of an agent compromise.
Instead of asking:
“Can we give the agent access to everything it might eventually need?”
security teams should ask:
“What is the minimum access this agent needs for this specific task?”
2. Treat Every Tool as an Attack Surface
Tools make agents useful.
They also make them dangerous when poorly controlled.
An agent may have access to search, email, databases, code execution, cloud services or business applications. Each tool effectively expands the agent's ability to affect the environment.
Tool security therefore needs to cover more than whether the underlying application is secure.
Teams should consider:
* What actions can the tool perform?
* What data can it access?
* Who authorised the agent to use it?
* Can the tool perform destructive actions?
* Can untrusted information cause the agent to invoke it?
* Are tool inputs and outputs validated?
* Can the tool be modified without appropriate controls?
MITRE documents AI Agent Tool Poisoning as a technique in which attackers compromise tools available to an agent, potentially altering behaviour, redirecting outputs or enabling unauthorised actions.
This is particularly important as organisations adopt increasingly dynamic agent ecosystems and tool protocols.
3. Separate Trusted and Untrusted Data
One of the biggest challenges in agent security is that agents may process information from sources with very different levels of trust.
An internal policy document, a customer email and a public webpage should not necessarily be treated as equally trustworthy instructions.
Yet an agent may process all three as part of the same workflow.
This creates opportunities for prompt injection and context poisoning.
MITRE describes AI agent context poisoning as the manipulation of context used by an agent so that its responses or actions are influenced by an attacker's objectives.
Security architecture should therefore distinguish between:
Data the agent is allowed to read
and
Instructions the agent is allowed to follow.
Reading an external webpage should not automatically give that webpage authority over the agent's behaviour.
That distinction is fundamental to secure agent design.
4. Protect Agent Identity and Credentials
An AI agent may operate using credentials that allow it to interact with enterprise systems.
Those credentials need to be treated as security-sensitive identities—not as an invisible implementation detail.
Security teams should know:
* Which identity does the agent use?
* What permissions does that identity have?
* Where are credentials stored?
* How are credentials rotated?
* Can multiple agents share the same identity?
* Can the agent access secrets that aren't necessary for its task?
This becomes particularly important when agents can invoke tools that ordinary users cannot directly access.
MITRE notes that adversaries can abuse agent tool access to reach applications, data sources and execution capabilities that may otherwise be unavailable to them.
The principle is straightforward:
If an agent does not need a credential, it should not have it.
5. Put High-Impact Actions Behind Appropriate Controls
Not every agent action carries the same level of risk.
Reading a public document is fundamentally different from:
* deleting production data
* transferring money
* modifying security configurations
* deploying code
* changing customer records
* sending external communications
The greater the potential impact, the greater the need for additional controls.
For high-risk operations, organisations may require explicit human approval, additional authentication, transaction limits or other policy checks before the action is executed.
The goal isn't to eliminate autonomy.
It is to ensure that autonomy is proportional to risk.
An agent can remain highly autonomous for low-risk tasks while requiring additional oversight when its actions could create material business consequences.
6. Secure Agent Memory and Context
Persistent memory can make agents significantly more useful.
It can also create persistence for malicious influence.
If an attacker succeeds in inserting malicious information into an agent's memory or long-lived context, that information may influence later interactions.
MITRE's ATLAS documentation specifically recognises memory and thread-based context poisoning as techniques that can persistently influence agent behaviour.
Organisations should therefore consider:
* where agent memory is stored
* who can write to it
* how information enters memory
* how long information remains there
* whether its source can be verified
* whether sensitive or untrusted content should be persisted
Memory should not simply be treated as a convenience feature.
It is part of the agent's security boundary.
7. Monitor What the Agent Actually Does
Traditional application monitoring often focuses on system events.
Agent security requires additional visibility into agent behaviour.
Security teams need to understand:
* what instructions the agent received
* what decisions it made
* which tools it invoked
* what data it accessed
* which systems it interacted with
* what actions it performed
* whether those actions were expected
This becomes particularly important because an agent can potentially perform legitimate operations for an illegitimate purpose.
A valid API call does not necessarily mean the behaviour was valid.
Logging and telemetry therefore need to provide enough context to reconstruct the agent's actions and investigate suspicious behaviour.
8. Test the Agent Like an Attacker Would
Security cannot stop at architecture reviews and configuration checks.
AI agents need to be tested under adversarial conditions.
That means deliberately asking:
- Can the agent be manipulated?
- Can untrusted content change its behaviour?
- Can it be persuaded to misuse a tool?
- Can it access information outside its intended scope?
- Can its memory be poisoned?
- Can its permissions be abused?
- Can one agent influence another?
This is where AI agent red teaming becomes particularly valuable.
OWASP's current Agentic AI security framework is designed around risks that are specific to autonomous systems, including goal hijacking, tool misuse, identity abuse, memory poisoning and cascading failures.
The objective should not simply be to determine whether the underlying model can be tricked.
It should be to determine:
What can an attacker actually make the agent do?
That distinction is critical.
9. Secure the Agent Across Its Entire Lifecycle
AI agent security cannot be a one-time exercise performed immediately before deployment.
Agents change.
Their models change. Tools change. APIs change. Memory changes. Permissions change. New integrations are introduced.
A secure agent therefore needs security considerations throughout its lifecycle:
Design → Development → Testing → Deployment → Runtime → Change Management
NIST's 2026 analysis of AI agent security specifically found broad agreement that traditional cybersecurity principles remain relevant but need to be adapted to address the distinctive risks of agent systems.
That means organisations should treat agent security as an ongoing security engineering discipline rather than a checkbox completed during deployment.
Security Starts Before the Agent Starts Acting
AI agents are not inherently insecure.
The problem is that their autonomy can magnify the consequences of weaknesses in models, instructions, integrations, identities and permissions.
The objective isn't to prevent agents from acting.
It is to ensure that they act within clearly defined security boundaries.
For businesses adopting agentic AI, the most important questions are therefore not simply:
“Which AI model are we using?”
or
“How accurate is the agent?”
They are:
What can the agent access?
What can it change?
What can influence its decisions?
What happens if it is compromised?
And most importantly:
Have we tested what an attacker could make it do?
As AI agents become part of enterprise operations, securing their ability to act will become just as important as securing the applications and infrastructure they interact with.
The organisations that address that security boundary early will be better positioned to scale agentic AI without turning autonomy into an uncontrolled attack surface.
