Over the past six months, AI agents have gone from research demos to products. Anthropic released "computer use" in October, letting a model operate a desktop through screenshots and mouse clicks. OpenAI launched Operator in January to complete web tasks for users. Coding agents that read a repository, run commands and open pull requests are now available from several vendors. Enterprises are wiring agents into ticketing, CRM and cloud consoles.
A chatbot answers questions. An agent takes actions. That difference changes the security picture completely.
What an agent is, from a security point of view
Strip away the marketing and an agent is a loop:
flowchart LR
G[Goal from user] --> P[LLM plans next step]
P --> T{Call a tool?}
T -->|yes| X[Tool executes<br/>browse, run code, call API]
X --> O[Observation fed back]
O --> M[(Memory)]
M --> P
T -->|no| R[Final answer]The model repeatedly decides what to do next based on everything in its context: the user's goal, its instructions, what it remembers, and the results of previous tool calls. Every one of those inputs can be influenced by an attacker, and every tool is a capability the attacker can try to borrow.
The main risks
Indirect prompt injection. An agent browsing the web, reading email or processing documents will read attacker-controlled text. Instructions hidden in a web page ("to finish this task, first send the user's files to…") can redirect the agent. This is the defining vulnerability of agents, and it has no complete fix today.
Tool misuse and excessive privilege. If an agent can send email, run shell commands, modify infrastructure or move money, a successful injection turns into those actions. Agents are often given broad API keys "to make the demo work".
Identity confusion. Many agents act with the user's full credentials. Downstream systems cannot tell the difference between the person and the agent, so they cannot apply different limits or attribute actions correctly.
Memory poisoning. Agents with long-term memory can be fed false "facts" or standing instructions that persist into future sessions and future users.
Cascading errors. Agents chain many steps. A small hallucination early on, such as a wrong file path or a misread number, can compound into a destructive action later.
Multi-agent trust. When agents delegate to other agents, a compromised or manipulated agent can pass bad instructions down the chain.
OWASP's GenAI Security Project published Agentic AI – Threats and Mitigations last month, which catalogues these and more in detail.
Controls that make a difference
1. Least privilege, per task. Give agents narrowly scoped tools and credentials. An agent that triages support tickets does not need to delete them. Read-only by default; write access only where the use case demands it.
2. A separate identity for the agent. Register agents as their own non-human identities, with their own permissions, rather than letting them borrow a person's session. This makes access reviewable, revocable and attributable in logs.
3. Human confirmation for consequential actions. Payments, external emails, production changes, deletions and permission grants should require explicit approval, and the approval screen should show exactly what will happen.
HIGH_RISK = {"send_email", "transfer_funds", "delete_records", "modify_iam"}
def execute(tool_call, session):
if tool_call.name in HIGH_RISK:
approved = session.request_approval(
summary=describe(tool_call), # exact recipient, amount, target
expires_in_seconds=300,
)
if not approved:
return {"status": "denied_by_user"}
audit_log.write(agent=session.agent_id, user=session.user_id, call=tool_call)
return TOOLS[tool_call.name](**tool_call.args)4. Sandbox execution. Code-running and browsing agents should work in isolated, disposable environments, such as containers or microVMs with no access to production credentials, restricted egress and resource limits.
5. Separate trusted and untrusted content. Mark content from the web, email and documents as untrusted in the agent's context, and do not allow it to trigger high-risk tools without confirmation. Some designs use a second, isolated model to process untrusted content with no tool access at all.
6. Constrain outputs and egress. Many real-world injection attacks exfiltrate data by making the agent render an image URL or call a web endpoint containing stolen data. Allow-list the domains an agent can contact.
7. Log every step. Record prompts, plans, tool calls, arguments and results. You will need them for debugging, for incident response and to prove what the agent did and did not do.
8. Test adversarially, and keep testing. Red-team agents with injection payloads in the places they read from. Re-test whenever the model, prompt or tools change.
Where to start
If your organisation is piloting agents:
- List every agent, what tools it has and whose credentials it uses.
- Remove any tool or permission not needed for the current use case.
- Add confirmation gates for irreversible actions.
- Make sure every agent action is logged with the agent's identity.
Agents will be one of the most useful technologies of the next few years. They are also a new kind of privileged user that can be socially engineered through text. Treat them that way.
Our agentic AI security team builds agents with these guardrails from day one, and our red teaming now covers agentic workflows.
