Agentic AI Security: Understanding the New Attack Surface of AI Agents

The move from chat interface to agent is often described as a capability upgrade. From a security standpoint it is a change of category. A chat feature produces text that a human reads and acts on. An agent produces actions that systems execute without a human in between.

That single difference relocates the risk. The question stops being what could this thing say and becomes what could this thing do, with whose credentials, and who would notice.

Chatbot, application, agent

Each row inherits the risks of the one above and adds its own. An agent still has prompt injection and still has disclosure exposure. It also has the property that a successful influence attempt can result in a write, a transfer, a message sent on someone's behalf, or a call to a further system.

Where the surface actually expands

Five properties do most of the work in enlarging the boundary.

1. Tool access

Every tool is an API endpoint the agent may call. The agent's effective privilege is the union of all tool privileges available in the current conversation. If tools execute under one service account, that union is the same for every user, regardless of who is asking.

2. Persistent memory

Memory turns a transient influence into a durable one. Content injected in one session and stored can shape behaviour in later sessions, potentially for other users if memory is shared. This is the agentic equivalent of stored versus reflected: the persistence is what raises the severity.

3. Autonomous planning

The agent decomposes a goal into steps. Nobody wrote the intermediate steps and nobody reviewed them. A control applied at the point of user request does not necessarily apply to step seven of a plan the model generated at runtime.

4. Delegation and identity

When an agent calls a tool, which identity does that call carry? If the answer is the agent's, then user-level authorization has been lost at the first hop and every downstream check is evaluating the wrong subject.

5. Inter-agent communication

Multi-agent systems pass content between components. Output from one agent becomes input to another. Unless provenance is preserved, an agent has no way to distinguish a peer's reasoning from content that peer merely retrieved from an untrusted source.

The risk classes worth threat modelling

• Goal hijacking — injected content redirects the agent's objective while it retains the user's context
• Tool misuse — a legitimate tool invoked with parameters or frequency outside its intended use
• Excessive agency — the agent can perform actions no one intended it to have access to
• Identity and privilege abuse — actions execute with broader privilege than the requesting user holds
• Memory and context poisoning — durable influence planted for later retrieval
• Insecure inter-agent communication — unauthenticated or unattributed messages between components
• Cascading failure — one compromised step propagates through a chain of dependent actions
• Human-agent trust exploitation — a confident, well-formatted answer used to obtain approval

OWASP's agentic security work provides a useful shared vocabulary for these; the value of naming them is that it lets a threat model be reviewed rather than improvised.

A defensive model

The controls that hold up are the ones that do not depend on the model behaving well.

1. Least privilege at the tool layer. Scope each tool to the narrowest capability that satisfies its purpose. Prefer get_own_orders() over query(sql).
2. Propagate user identity. Tool calls should carry the requesting user's identity so downstream authorization evaluates the correct subject.
3. Deterministic policy enforcement. Whether an action may proceed is decided by a policy engine, not by the model's judgement. The model chooses intent; policy decides permission.
4. Human approval for high-impact actions. Irreversible, financial or externally-visible actions should require confirmation showing the concrete action and parameters.
5. Validate at both ends. Treat tool inputs as untrusted because the model produced them, and tool outputs as untrusted because an external system produced them.
6. Segment memory. Scope by user and tenant. Be explicit about what may persist and for how long.
7. Preserve provenance. Track where each piece of context originated so trust decisions can be made on the source rather than the format.
8. Audit every invocation. Log the tool, parameters, requesting identity and outcome. Without this, incident response has no reconstruction path.
9. Constrain the blast radius. Rate limits, spend caps and per-session action budgets bound the damage of a plan that goes wrong.

Testing considerations

• Inventory tools per conversation state; availability often changes as a plan progresses
• Test each tool directly, with a low-privilege account, bypassing the agent entirely
• Determine which identity reaches the downstream system on a tool call
• Establish whether memory is scoped per user, and whether it survives a session boundary
• Trace content provenance through multi-agent hops
• Confirm approval gates cannot be satisfied by the agent itself
• Review logs for whether a full action chain could be reconstructed after an incident

Conclusion

Agentic systems are worth building, and the security model for them is not mysterious. It is the same model used for any component that acts on behalf of a user: authenticate the principal, propagate the principal, authorise every action against the principal, constrain what is reachable, and log it.

What is new is the temptation to let a persuasive component make those decisions for you. The discipline is to keep the decisions deterministic and let the model do the part it is good at — understanding what was asked.

References

• OWASP GenAI Security Project — agentic security work
• OWASP Top 10 for LLM Applications
• MITRE ATLAS
• NIST AI Risk Management Framework