How should security teams handle prompt injection across multiple agent input surfaces?

How to think about prompt injection across the whole agent input surface

Prompt injection is not one control problem, because not every malicious instruction arrives through the user prompt. Security teams should model prompt, retrieval, tool output, handoffs, and memory as separate ingress paths, then assume any accepted text can still become dangerous once the agent has context and authority. The right unit of defence is the full input surface plus the runtime permissions that follow it.

That distinction matters because indirect attacks often succeed by entering through a surface teams did not classify as “the prompt”. A retrieval result, an email, a file, or a prior memory entry can influence the agent as effectively as a direct user instruction, especially when the agent is allowed to browse, call tools, or continue across turns. The control objective is therefore boundary management, not content filtering alone.

One practical way to structure the problem is to separate pre-context validation from post-context containment. Input-specific checks can reduce obvious injection patterns, but they do not solve the core issue that an agent may later act on accepted content. Runtime containment should cap what the agent can do after ingestion, including which tools it may call, which data it may touch, and which actions require explicit approval.

Why separate ingress controls from runtime containment?

Different input surfaces fail in different ways. User prompts are visible and easy to overfocus on, while retrieval, tool output, and memory can carry malicious instructions in places teams are less likely to review or sanitise. A single “prompt filter” misses the real attack path if the harmful instruction arrives through a trusted connector or is introduced after the original turn.

Shared runtime containment gives you a second line of defence when the content itself cannot be trusted. If the model accepts unsafe text, the environment still needs to constrain downstream action so the agent cannot freely exfiltrate data, invoke privileged tools, or chain a benign instruction into a high-impact operation. This is especially important when the agent operates across multiple tools or multiple turns.

For a practical starting point, treat each surface as its own trust boundary and define what can enter from that surface, what can be retained, and what action it is allowed to influence. The smaller and more explicit each boundary is, the easier it becomes to detect when a downstream agent action is inconsistent with the original trust expectation.

What security teams should test on each surface

Each surface needs its own abuse cases, because a control that works for one input path may fail on another. Retrieval should be tested for poisoned documents and hidden instructions, tool output for instruction smuggling, handoffs for inherited context confusion, and memory for stale or cross-session contamination. The point is to verify that each surface is treated as untrusted input unless it has been separately proven otherwise.

That is also where Prompt Injection Guide is useful, because it frames direct, indirect, and multimodal attacks as a single defensive problem with layered controls across inputs, tools, and exfiltration paths. Teams should use that kind of taxonomy to avoid writing test cases that only exercise the user chat box.

For agents that depend on tools or external data, the control question is not “can this text be detected as malicious?” but “what can the agent still do if malicious text is accepted?” That is the sharper test for blast radius, because a weak ingress control can still be acceptable if runtime permissions are tightly bounded, while a weak runtime model is dangerous even with good filtering.

Where prompt injection becomes an operational risk

Risk rises sharply when the agent can act on behalf of a user, access sensitive systems, or keep state across turns. In those cases, prompt injection is not just a content integrity issue, it becomes an access and action-control issue, because the injected text may steer a tool call, a lookup, a workflow, or a disclosure that the user never intended. The more connected the agent is, the more attractive the attack path becomes.

This is why teams should pay particular attention to handoff boundaries between agents, because one agent can inherit contaminated context from another without revalidating it. The same logic applies to memory: once malicious content is stored, it can survive beyond the original session and influence later behaviour in ways that are hard to trace.

A useful reference point is the OWASP LLM Top 10 LLM01 Prompt Injection Guide, which emphasises mitigations such as least privilege, grounded outputs, and human approval for sensitive actions. Those controls matter because they reduce the value of a successful injection even when prevention is imperfect.

Practitioner Guidance

What to verify: Test each surface independently, then test the full chain. A team that only probes the chat prompt will miss indirect attacks that enter through retrieval, tool output, or memory and only become dangerous at action time.

Decision rule: If accepted text can trigger data access, external communication, or state-changing action, do not rely on filtering alone. Require a runtime permission model that limits tool scope, data scope, and irreversible actions after the context window.

What good looks like: A poisoned document, tool response, or handoff message can influence the model’s reasoning, but it cannot by itself authorise a high-impact outcome. Sensitive actions should still require explicit policy checks or human confirmation.

Practitioner takeaway: Treat prompt injection as an end-to-end trust problem, not a chat moderation problem. The safest design is the one that assumes hostile input may get through and still prevents the agent from doing anything material with it.

Related resources from NHI Mgmt Group

• Guide: Agentic AI Security Guide
• Prompt Injection (Agentic)
• How should security teams handle AI agent visibility?
• How should security teams enforce prompt controls across multiple Claude surfaces without relying on scattered point solutions?
• How should security teams design agent controls to reduce prompt injection risk across tool calls and browser actions?