The Agentic Attack Surface Does Not Stay Still

The first wave of LLM security focused on what went into the prompt and what came back out. That made sense when the product was a chat box.

An agent is a different system. It reads email and web pages. It retrieves documents. It writes memory. It plans several steps ahead. It calls tools with real credentials. It may delegate work to another agent, operate a browser, run code, or change something that matters.

The attack surface expands every time one of those capabilities is added. It also shifts. A control that was adequate for a model answering questions may be almost irrelevant once the same model can send a message, query a database, or execute a command.

I recently read four papers that approach this problem from different directions:

• Agentic AI Security: Threats, Defenses, Evaluation, and Open Challenges, a broad survey of threats, defenses, benchmarks, and unresolved problems;
• ASTRIDE: A Security Threat Modeling Platform for Agentic-AI Applications, which extends STRIDE with agent-specific threats and experiments with diagram-driven threat modeling;
• MATRA: Modeling the Attack Surface of Agentic AI Systems, which connects assets and business impact to architecture-specific attack trees;
• SoK: The Attack Surface of Agentic AI - Tools, and Autonomy, which maps trust boundaries across retrieval, tools, memory, and multi-agent systems and proposes ways to measure the resulting risk.

Taken together, they make a useful point: prompt injection is often the entrance, not the incident. The incident is what happens after untrusted content reaches a planner with tools, permissions, memory, and time.

The model is no longer the whole security boundary

Consider a research assistant with no tools. A successful injection may produce a bad answer. Give that assistant a browser and the attacker gains a path to influence what it reads. Add persistent memory and the influence can survive the original session. Add a shell, a messaging tool, and a database credential, and a bad interpretation can become code execution, data access, or exfiltration.

None of those capabilities is automatically unsafe. The risk comes from the connections between them.

That changes the unit of analysis. We cannot threat-model only the model endpoint. We have to model the complete path from an untrusted source to a privileged effect:

1. Input: a person, document, web page, image, audio clip, API response, or peer agent supplies content.
2. Context: the system combines that content with instructions, retrieved material, conversation history, and memory.
3. Planning: the model interprets the goal, selects actions, and may create subgoals.
4. Authority: an identity, token, or delegated permission determines what the run can reach.
5. Execution: a tool, plug-in, MCP server, browser, code runner, or downstream service performs the action.
6. Persistence: memory, files, queues, logs, and other agents may carry the effect into later work.
7. Recovery: monitoring, containment, revocation, rollback, and human response determine how long the problem lasts.

That chain is the attack surface. The LLM is one component in it.

The vectors now arrive through almost anything the agent can perceive

The broad survey by Chhabra and colleagues groups agentic threats into prompt injection and jailbreaks, autonomous exploitation and tool abuse, multi-agent and protocol threats, interface and environment risks, and governance concerns.

The important detail is that an instruction does not have to look like a prompt. It can arrive in a web page, accessibility tree, retrieved document, image, audio stream, API response, tool description, or message from another agent. Multimodal systems turn every supported input format into a possible instruction channel.

This is one reason simple input filtering ages badly. A filter tuned for suspicious text may miss an instruction hidden in an image. A prompt defense may say nothing about a poisoned vector index. A safe tool schema may still be dangerous when the agent holds an over-privileged credential. An authenticated peer agent may still send a compromised delegation.

The surface also includes accidental failure. MATRA treats non-adversarial events as real threat sources when an agent can act autonomously. A hallucinated database statement with excessive privilege can produce the same integrity damage as a malicious command. Intent changes the investigation, but it does not restore the data.

Memory turns a momentary failure into a durable one

Persistent memory deserves separate treatment because it changes the time scale of an attack.

A poisoned web page may influence one run. If the agent summarizes that page into long-term memory, the hostile claim can become trusted context for future runs. If provenance is stripped during summarization, the next session may see a confident statement without knowing where it came from. The original attacker does not need to remain present.

The SoK paper describes persistent histories, scratchpads, and vector stores as durable attack surfaces. Its proposed direction is practical: preserve provenance, score trust per entry, mediate writes, support quarantine and rollback, and periodically revalidate stored material.

I would add one operational rule: memory should never become more trusted merely because it is old. Age is not evidence. Every retrieved memory should retain its source, authorizing context, sensitivity, and integrity state.

Tools turn reasoning errors into effects

Tool use is where a model mistake crosses into system behavior.

MATRA’s case study makes this concrete. It models an agent that can process customer messages, query data, execute commands, and send outbound messages. The study shows that network sandboxing can block one exfiltration route while leaving other routes open through messaging or rendered content. The risk remains until the architecture addresses each viable path.

That is a better lesson than “sandbox the agent.” A sandbox is useful, but its boundary has to match the actual execution graph. If one tool runs inside the container and another runs on the host, the system does not have one sandbox. It has several trust zones with different escape routes.

The study also reinforces a security principle that predates LLMs: an injected instruction runs with the capabilities of its host. If a compromised agent has read-only database access, no network route, and no outbound messaging tool, the blast radius is limited. If it holds broad production credentials, every prompt defense is carrying more weight than it should.

This is why I prefer least agency to a vague promise that the model will behave. Expose only the tools, operations, destinations, data, duration, and transaction size needed for the task. Enforce those limits outside the model.

Multi-agent systems create new trust problems

Adding agents does not just multiply the original risks. It introduces relationships that did not exist in a single-agent design.

A peer can advertise a false capability, accept a task it should not receive, forward untrusted context, amplify a poisoned result, or create a delegation loop. A lower-privilege agent may persuade a stronger agent to perform an action on its behalf. A message can be authentic and still exceed the authority of the original request.

Threat models therefore need to record more than agent names. For every handoff, I want to know:

• who initiated the task;
• which agent is speaking;
• what authority is being delegated;
• whether that authority becomes narrower at each hop;
• what context and data cross the boundary;
• which schema and protocol version are expected;
• how recursion, retries, cost, and time are bounded;
• how the chain can be stopped and reconstructed.

Authentication answers who sent the message. Authorization still has to decide whether that agent may make that request for this task.

Threat models have to follow the architecture

The two threat-modeling papers suggest complementary ways to handle a surface that keeps moving.

ASTRIDE adds an “A” category to STRIDE for agent-specific attacks such as prompt injection, context poisoning, reasoning subversion, and unsafe tool invocation. Its prototype uses fine-tuned vision-language models to inspect architecture diagrams and a reasoning model to combine their findings. The experiment is early and uses a relatively small, partly synthetic diagram dataset, so I would not treat it as an autonomous security reviewer. The valuable idea is that agent-specific threats should be mapped to actual components, data flows, and trust boundaries, not kept in a generic checklist.

MATRA starts with assets and impact, then builds attack trees from recognized techniques to concrete vectors in the deployed architecture. That helps separate a known threat class from the paths that are actually possible in one system. It also forces the reviewer to consider the full surface rather than stopping after the most obvious route is blocked.

Together, these approaches point toward a living threat model:

• maintain a current data flow and capability graph;
• mark untrusted inputs, trust boundaries, identities, and privileged effects;
• map OWASP and MITRE techniques to real paths through that graph;
• recalculate exposure when a tool, model, credential, memory source, peer, or network route changes;
• preserve human review for impact, assumptions, and mitigation decisions.

Automation can help find gaps and keep diagrams current. It should not be allowed to approve its own architecture.

Measure actions and distance, not just refusals

Agent security testing often asks whether the model refused a malicious prompt. That is useful, but refusal rate is a weak proxy for system safety.

The SoK paper proposes several metrics that are closer to operational risk:

• Unsafe Action Rate: how often a scenario produces a policy-violating action;
• Privilege-Escalation Distance: the shortest path from an untrusted input to a privileged action;
• Out-of-Role Action Rate: how often the agent acts outside its role and tool contract;
• Retrieval Risk Score: the risk carried by the sources in a retrieved bundle;
• Time-to-Contain: how long it takes to stop a detected incident;
• Cost-Exploit Susceptibility: how much resource consumption an attacker can drive over a defined period.

These are research proposals, not settled industry standards, but the direction is right. Security tests should examine side effects, policy enforcement, path length, containment, and recovery. A model that says “I cannot do that” after the tool has already sent the data did not pass.

The same paper recommends repeated, trace-based tests because agent behavior is stochastic. Fix the model and policy versions, record tool calls and retrieval bundles, reset state between trials, and use an evaluator that is separate from the system under test. Run a smaller regression suite in delivery pipelines, then use realistic end-to-end scenarios for deeper testing.

This is exactly the kind of evidence an Agent Trace Lab should make easier to inspect.

What this changes in an AISecOps program

These papers do not make the current frameworks obsolete. They show how to use them together.

NIST AI RMF supplies the governance cycle. The OWASP LLM Top 10 covers foundational application risks. The OWASP Agentic Top 10 moves into goals, tools, identity, memory, delegation, and cascading failure. MITRE ATLAS helps turn those risks into adversary behaviors and testable paths.

An AISecOps program should make the following practices routine:

1. Inventory capabilities and relationships. Record tools, operations, data, identities, peers, memory, network routes, and maximum autonomy, not just model names.
2. Treat architecture changes as security events. A new connector or delegated permission can change risk more than a model upgrade.
3. Separate proposal from enforcement. Let the model suggest an action. Let deterministic policy, schemas, identities, and infrastructure decide whether it can happen.
4. Preserve provenance everywhere. Keep source and integrity information through retrieval, summarization, memory, delegation, and output.
5. Test complete attack paths. Start with untrusted content and observe whether it can reach a privileged effect through any available route.
6. Assume prevention will miss. Instrument the run, bound time and cost, provide a kill path, revoke credentials quickly, and practice rollback.
7. Continuously retest adaptive attacks. Version prompts, policies, tools, memory rules, and test cases so regressions are visible.

The surface will keep moving

There will not be a final list of agentic attack vectors. Models are gaining new modalities. Agents are receiving more tools. Protocols are connecting them to one another. Memory is becoming longer-lived. Physical systems are beginning to put model decisions into motion.

The durable answer is not a perfect prompt filter. It is an architecture that expects the reasoning layer to be fallible and potentially manipulated.

Keep untrusted inputs far from privileged effects. Make delegation reduce authority. Give memory provenance and a rollback path. Put hard controls around tools. Trace the complete chain. Re-run the threat model whenever the capability graph changes.

The attack surface does not stay still. The security program cannot either.