AI Agent Security Series: 2. Deriving the Attack Surfaces

In December 2025, OWASP released the 2026 edition of its Agentic Applications Top 10 [1], consolidating the threats to agentic applications into a standard list; the derivation below uses it as a reference.

The first article took the agent runtime apart into six layers and two components and left behind two structural facts: structural fact 1 is that all external content converges at assembly into one flat token stream with no provenance markers, and structural fact 2 is that the permission checkpoint covers only the model-to-action segment, so content ingestion and configuration loading never pass through it. Derived along that structural diagram, the attack surfaces differ from the threat list: their value lies in testability, in that any new vulnerability or new technique can be located on one of the attack surfaces, while whatever fails to locate exposes a gap in the structural diagram, and both outcomes advance understanding. Once the derivation is done, the ten OWASP categories are placed back onto the seven attack surfaces one by one, and the relation between the threat list and the structural diagram becomes clear.

The derivation follows three questions: which classes of state decide an agent’s behavior and which checkpoints intercept execution; which attack surfaces those states and checkpoints yield, and where each sits on the architecture diagram; and what still separates one attack surface from an actual attack.

OWASP Agentic Applications Top 10 (2026)

Source: OWASP Top 10 for Agentic Applications (2026) [1]. The ten categories:

1. Goal hijacking (ASI01): exploits the model’s inherent inability to reliably separate instructions from content, manipulating the agent’s goals, task selection, and decision paths; the impact spans subsequent multi-step behavior rather than a single answer;
2. Tool misuse (ASI02): the agent uses legitimate tools in unsafe or unintended ways within its authorization, such as deleting data, over-calling paid APIs, or exfiltrating information; privilege escalation belongs to ASI03 and landing as code execution belongs to ASI05;
3. Identity and privilege abuse (ASI03): manipulating delegation chains, role inheritance, and agent context to escalate privileges; the root cause is that identity systems are human-centered: agents hold no independently governed identity, so least privilege cannot actually be enforced;
4. Agentic supply chain (ASI04): third-party components such as models, tools, plugins, datasets, MCP and A2A interfaces, registries, and update channels are poisoned or tampered with; the difference from the traditional software supply chain is that the components are mostly assembled dynamically at runtime;
5. Unexpected code execution (ASI05): injection, tool misuse, or unsafe deserialization turns text into executable behavior, with consequences up to host or container takeover, persistence, and sandbox escape; the code is often generated by the agent in real time, bypassing controls based on static rules;
6. Memory and context poisoning (ASI06): conversation history, long-term memory, or retrieval stores are written with malicious or misleading data, contaminating later reasoning, planning, and tool selection and propagating across sessions; the division of labor with ASI01 is that poisoning targets stored context;
7. Insecure inter-agent communication (ASI07): message exchange in multi-agent systems lacks authentication, integrity, and semantic validation, and can be intercepted, forged, or tampered with; the threat spans transport, routing, discovery, and semantics;
8. Cascade failure (ASI08): a single defect propagates through an agent network and amplifies into systemic failure; the entry describes the propagation itself rather than the starting point, which by nature belongs to ASI04, ASI06, or ASI07;
9. Human trust exploitation (ASI09): exploits anthropomorphic trust, authority bias, and automation bias so that people approve an agent’s output and suggestions without verification; the human on the approval chain becomes an exploited link;
10. Rogue agent (ASI10): a malicious or compromised agent drifts away from its intended function and authorization, its behavior drifting while disguised as compliant; the entry concerns the loss of behavioral integrity after drift begins, not the initial compromise.

This list does its job: it serves as a reference for people working on agent security, collecting the ten highest-impact threat categories, with the dominant shapes of publicly known attacks all represented. It is organized by threat type rather than by the agent’s internal structure, so it cannot answer questions like these: which position in the runtime each threat category occupies, which categories share a root cause, and why public vulnerabilities concentrate in a few categories while the rest stay near zero; answering these requires a derivation that starts from the structure.

Derivation Method: From the Architecture Diagram to the Attack Surfaces

The derivation starts from the first article’s architecture diagram:

In a running agent, behavior is decided by five classes of state, each mapped to a fixed position on the diagram:

The five classes of state share one property: whenever untrusted input can write into any one of them, the agent’s behavior is under control.

Execution is intercepted by four checkpoints:

An attack surface therefore consists of two parts. The first is the set of writable positions: every class of state in the table above has its own reach paths, along which untrusted input writes in. The second is the set of bypassable checkpoints: every checkpoint has its own failure mode; the check can be bypassed, the sandbox breached, the framework code exploited directly, and once a failure holds, no further defense stands in the way.

The two parts must combine to make an actual attack; neither half stands on its own. Write without bypass, and nothing executes what was written; bypass without write, and the checkpoint waves through normal actions with behavior uncontrolled. Real attacks are almost always the two steps combined: first write into some state to change behavior, then exit through some checkpoint’s gap.

Three public cases occupy one combination each:

1. Classic injection: content is written into the context while the check auto-approves allowlisted actions, so the hijacked decision executes without inspection;
2. Configuration-as-execution: component makeup is written, an event hook triggers execution, and the path never touches the model or the check (structural fact 2);
3. Cursor’s DuneSlide: injection manipulates the parameters the model fills in, the sandbox builds its write allowlist from the manipulated values, and the overwrite lands on the sandbox executor itself [2].

The scope of the derivation draws one boundary first: attack surfaces cover only failures an attacker reaches through untrusted input. Three common classes of failure are therefore excluded.

• Hallucination and overstepping beyond authorization come from the agent itself, with no attacker behind them.
• Resource exhaustion can be the result of an attack, but it is not an independent path.
• Instructions the user injects directly: the user is the authorizing party, and instructions the user gives do not constitute an attack.

One case is easy to misjudge: when a user pastes third-party content into the conversation, that content does not originate from the user and is still handled as untrusted content.

The Seven Attack Surfaces

The derivation method’s two tables each yield part of the attack surfaces: the five classes of state yield four writable surfaces, context, config, persistent state, and presentation. Permission rules and component makeup are both carried by configuration files and are merged here into one config attack surface; among the four checkpoints, the check, the sandbox, and the framework’s own code yield three bypassable surfaces. The fourth checkpoint is the human, and the ways to attack a human are writing presentation and deceiving approval, both of which fall on the human interface attack surface, so the human does not constitute an attack surface on its own. Four writable surfaces plus three bypassable surfaces make seven attack surfaces. Mapped onto the agent’s structural diagram, S1 through S7 correspond to Attack Surface 1 through Attack Surface 7 in the text:

Attack Surface 1: context injection (S1, L2→L3, writable). Task input, tool definitions and returns, read-in files and pages, and memory persisting across sessions converge at L2 into one unmarked token stream (structural fact 1); what writing into this surface acts on directly is the model’s decisions. The injection vectors are the most ordinary content: web pages, issue comments, tool descriptions, comments inside a repository; the attacker needs no special entry point. Injection itself is delivery, not the vulnerability: how far a hijacked model can go is decided by Attack Surface 3 and Attack Surface 4, and this relation is why injection attacks, viewed end to end, always take the shape of a chain.

Attack Surface 2: configuration (S2, CFG, writable). Configuration files carry four classes of content: permission rules, component registration, event hooks, and runtime parameters; writing configuration changes the machine without the model and without the check. The reach paths sit at the low end of the first article’s trust gradient: project-directory configuration arrives with the repository clone, and marketplace auto-installation is performed by the agent itself; both are write methods an attacker can arrange. By the count of public CVEs, this is currently the most productive attack surface.

Attack Surface 3: permission-check bypass (S3, L4, bypassable). The checking mechanism itself fails in four ways.

• Lexical bypass: the mapping from command text to effect class misses semantics, and what the checker reads and what actually executes are two different things.

• Rules rewritten: allowlists written through Attack Surface 2’s channels, or users induced into approving overly broad rules.

• Path skipped: event hooks execute without the check.

• Review blind spots: model-based review cannot see malicious intent carried in ciphertext or in execution semantics.

Attack Surface 4: sandbox (S4, execution boundary, bypassable). Sandbox failures fall into four classes.

• Coverage gaps: profiles usually constrain only write and execute, reads are unlimited, and credentials stay readable.
• Escalation execution: after a user approves a boundary-crossing action, that execution leaves the sandbox and runs directly on the host, and the whole boundary falls with it.
• Boundary escape: code inside the sandbox breaks through the boundary itself and regains the host’s full privileges.
• Construction depending on model-supplied parameters: the sandbox builds its allowlist from values the model fills in, and when injection manipulates those values the boundary falls with them; DuneSlide has walked this path end to end [2].

Attack Surface 5: persistent state (S5, L6, writable). Once memory and session records are written into, this session’s exit becomes the next session’s entry: a single-session attack turns into a standing presence, and both persistence and remote control land on Attack Surface 5. The exposure of credentials consists of a read path plus a communication exit; monetization holds only when both are reachable. By the public record, this is the attack surface with the largest gap between events and research.

Attack Surface 6: human interface (S6, L1, writable). Of the four checkpoints, the last is the human, and attacking a human means controlling what the human sees, which is all presented through L1, so this attack surface lands on L1. Presentation is a writable target, and the process from data to screen is independent of the model’s decisions: in AutoGPT’s CVE-2023-37275, ANSI escape sequences carried by a malicious page never touched the model; they were rendered directly by the terminal as fake command output, deceiving the person reading the screen [3]. The approval step can be deceived as well: mechanical approval under fatigue, consent requests disguised as normal flow, and interfaces that never show what will actually run.

Attack Surface 7: framework and runtime (S7, the harness’s own code, bypassable). This surface points at implementation flaws in the harness’s own code: serialization, checkpoints, and parsers in L2 and L5, local services, and the native runtimes themselves (V8, Electron), failing as state poisoning, parser confusion, and overwrites of trusted files. Because the object of attack is the code wrapping the model, these flaws are exploitable without the model and without the check; Langflow’s unauthenticated remote code execution (CVE-2025-3248) is the canonical case: one browser visit triggers it.

Taken together, the seven attack surfaces arrange along a clear line: Attack Surface 1 and Attack Surface 2 change behavior, the first manipulating the model’s decisions and the second changing the machine; Attack Surface 3 and Attack Surface 4 get past checkpoints, corresponding to the check and the sandbox; Attack Surface 5 lets an attack persist across sessions; Attack Surface 6 and Attack Surface 7 target the last lines of defense, the human and the code. No attack surface takes the model as its object. At the end of the first article this was still an observation; after the derivation it becomes a conclusion: every checkpoint lands on the harness, the model sits outside the checkpoint sequence, and a compromised model only raises Attack Surface 1’s write success rate rather than constituting an attack surface of its own.

Placing the ten OWASP categories from the previous section onto the seven attack surfaces:

The ten categories fall into three clean groups:

• Placed on a single surface: ASI01 goal hijacking lands on Attack Surface 1; ASI03 identity and privilege abuse and ASI06 memory and context poisoning land on Attack Surface 5; ASI09 human trust exploitation lands on Attack Surface 6.
• Spanning two surfaces: ASI02 tool misuse touches both Attack Surface 1 and Attack Surface 2; ASI04 supply chain lands on Attack Surface 2 and extends to the environment side; ASI05 unexpected code execution covers Attack Surface 2 and Attack Surface 7.
• Placed nowhere: ASI07 and ASI08 describe how failure propagates along channels; they are path attributes, not new positions. ASI10 is the reverse dimension of the agent as attacker and lies outside the attack-surface model.

Notably, Attack Surface 3 and Attack Surface 4 receive no direct entry: the list folds check and sandbox failures into tool misuse and unexpected code execution, while the attack-surface model sets them apart.

From the Attack Surfaces to the Attack Paths

An attack surface supplies the writable positions; turning a position into actual damage still takes a route from entry to exit, and that route is the attack path. A complete attack path has five segments, each of which draws its value from a fixed option set:

A complete attack path is simply one value filled into each of the five segments. Walked end to end with the configuration-as-execution chain: the channel is file, the malicious configuration entering with the repository clone; the write lands on Attack Surface 2, configuration; the bypass exploits the fact that event hooks never pass the check; the effect is execution; and the exit is persistence, with the written hook continuing to fire in every later session.

The origin of the seven typical paths is in this table. The write segment’s options are the four writable attack surfaces; the bypass segment’s options are the four checkpoints, with the check, the sandbox, and the framework code corresponding to Attack Surface 3, 4, and 7, and the fourth checkpoint being the human, who is not an attack surface, so writing that deceives the human lands on Attack Surface 6.

The generation method is to let each of the seven attack surfaces take a turn as the answer, without enumerating combinations of options (which would run to hundreds of meaningless mixes): whichever surface’s turn it is fills the write segment or the bypass segment, while the channel, effect, and exit segments take that surface’s most typical values, and the five segments joined together make one path. When Attack Surface 1 is the answer: malicious content comes in through entries like web pages and issue comments, is written into the context, and after hijacking the model’s decisions picks auto-approved actions to execute, which joined together is the context-injection chain. Each of the seven attack surfaces takes one turn as the answer, yielding seven typical paths, and the table writes only the surface filled in and the signature consequence:

The seven chains are not independent of one another; the permission-bypass chain is one example: to bring tailored input before the check, content must first be delivered, and the write segment is filled with the product of context injection. Real attacks more often string several chains together, and Cursor’s CurXecute zero-click chain is a composite of four links: injection delivers, the hijacked model auto-executes allowlisted actions, the chain then harvests credentials from the environment, and a reverse shell closes with persistence. Each of the four links has its own public analysis; what constitutes the threat is the complete chain that strings them together. The typical paths are therefore reusable standard parts rather than a closed taxonomy: a single typical path describes one way through, and real attacks compose them as needed.

The exit segment carries one more layer of meaning. The memory, hooks, configuration, and scheduled tasks written by a persistence exit become the next session’s input; the red dashed line in the diagram is exactly this loop: this session’s exit connects to the next session’s channel, and a one-shot attack becomes a standing presence. Inside a session runs another, smaller loop: tool results fold back into the context for the next turn of reasoning, and injection relies on it to amplify step by step. One loop stays within the session, one spans sessions, and the two coexisting are the structural reason agent attacks are hard to defend.

Articles 3 through 9 expand the seven paths in the order of the table above, each with public cases.

Closing Notes

With this, the two pictures from the opening meet: the ten OWASP categories fit into the seven attack surfaces one by one, with no category requiring a new position. The derivation also yields the conclusion that runs through the series: the seven attack surfaces all land on the harness, none takes the model as its object of attack, and a model that gets written to is only a success-rate question for Attack Surface 1, not an independent target. From attack surfaces to attack paths, the link is the five-segment structure (channel, write, bypass, effect, exit): one path is one value filled into each of the five segments, the seven attack surfaces each generate one typical path, and real attacks are combinations of several chains; this structure is the shared basis for the path analysis in every later article.

The next article enters the first attack surface: context injection. How every kind of content converges into a single stream, what writing into it controls, and why every input-side filtering proposal fails to stop it.

References

[2] Cato AI Labs — DuneSlide: Two Critical RCE Vulnerabilities (CVE-2026-50548 / 50549): https://www.catonetworks.com/blog/duneslide-two-critical-rce-vulnerabilities/

[3] NVD — CVE-2023-37275 (AutoGPT): https://nvd.nist.gov/vuln/detail/CVE-2023-37275

[1] OWASP — Top 10 for Agentic Applications (2026): https://genai.owasp.org/