How far can prompt-injection defences contain a tool-using AI agent?

Instruction priority, permission boundaries and the interpretation of security benchmarks

This retrospective review considers source versions available by 9 March 2026. The cutoff defines the evidence included; preparation and source checking took place on 21 October 2026.

Keywords: prompt injection; agent security; capabilities; least privilege; marketing workflows

1. The research question

An AI system that reads campaign documents and an AI system that can change a campaign occupy different security positions. In both cases, misleading content can affect the answer. Only the second system can also spend money, change a destination, alter a customer record or publish material through its own credentials. The security question therefore concerns the interaction between language interpretation and delegated authority. A model's response is one component of that interaction; the surrounding software determines which consequences a response can produce.

This review asks what the available research establishes about indirect prompt injection, and how those findings relate to tool permissions and containment. It separates an attacker's ability to influence a model from the ability to complete an unauthorised action. It also separates resistance measured in a benchmark from a guarantee about a deployed workflow. These distinctions are necessary when a marketing assistant retrieves competitor pages, analyses documents supplied by agencies or reads material from an email inbox. All are opportunities to encounter content written by someone other than the person authorising the task.

2. Review method

Targeted searches and direct primary-source retrieval were undertaken on 21 October 2026. Search terms combined prompt injection, tool-integrated agents, instruction hierarchy, structured queries and agent security. The selected literature includes attack demonstrations, agent benchmarks, model-training defences, an architectural defence and established security guidance. 17 sources were retained to cover different parts of the problem. Selection was purposive; no claim is made to comprehensive database coverage or systematic screening.

Research abstracts and publication records were inspected for the seven model and agent studies; the accessible CaMeL manuscript was additionally inspected for architecture, threat-model and side-channel sections. Their claims are reported at that level of access. The analysis does not reproduce attack code, examine every benchmark case or independently verify a defence's proof assumptions. the published 2025 edition of OWASP's guidance and the MIT-hosted security text were also consulted. NIST publication records supply the identity and scope of the relevant standards; the review does not represent a complete control-by-control standards assessment. No pooled attack rate is calculated because the tasks, attacker access and success definitions differ.

3. Instructions, data and authority

3.1 The indirect attack surface

Greshake and colleagues demonstrated the security implications of placing adversarial instructions in material that an application retrieves. Their report describes attacks against real and synthetic LLM-integrated applications, including information theft and contamination of an information environment [1]. The important change is in the attacker's route to the system. The attacker need not be the user issuing the task. Control over a document, page or other retrieved item can be sufficient to introduce instructions into the model's input.

Retrieved content remains useful precisely because it contains language that the system must interpret. A campaign analysis assistant may need to understand instructions quoted in a customer complaint without adopting those instructions as its own operating policy. This creates an interpretation problem inside a larger access-control problem. A document can describe a requested action, but its author has not thereby acquired the right to authorise that action. The distinction must survive retrieval, summarisation and any subsequent planning step.

Direct jailbreaks and indirect injections overlap, but their threat models differ. Zou and colleagues studied automatically generated adversarial suffixes that elicit unwanted model behaviour [7]. That work supplies evidence that model alignment can be attacked through optimised inputs. It does not estimate the probability that a marketing agent will encounter a poisoned webpage. OWASP distinguishes prompt injection from the narrower objective of bypassing safety behaviour and notes that retrieval augmentation does not fully remove the vulnerability [8].

3.2 A failure has several possible endpoints

A security evaluation can stop at a contaminated answer, an attempted tool call, a successful external action or verified data loss. These are different endpoints. If a model proposes sending a file and the tool gateway refuses the destination, model-level instruction following has failed while the access boundary has succeeded. Reporting the event simply as an attack success or failure hides that distinction. The unit of analysis must include what the attacker controlled, what was requested and which system component accepted or rejected the resulting action.

4. What the benchmarks measure

4.1 InjecAgent

InjecAgent contains 1,054 test cases involving 17 user tools and 62 attacker tools. Zhan and colleagues evaluated 30 agent configurations and reported a 24% vulnerability rate for the ReAct-prompted GPT-4 configuration in their assessment [2]. The benchmark distinguishes harmful actions from private-data exfiltration. These are valuable design features because an attacker can pursue a different objective from simply producing objectionable text. The figures describe that published experimental configuration; they are not a forecast for every later model or connector.

A benchmark's attack rate is conditional on its attempted attacks. It does not contain the frequency with which an organisation encounters such attacks in production. Nor does it encode the business value of each exposed resource. A test that assigns equal weight to two successful actions can still represent very different operational consequences. For that reason, the review keeps the reported benchmark result separate from any estimate of expected loss, incident frequency or acceptable residual risk.

4.2 AgentDojo

AgentDojo extends evaluation into an environment with realistic user tasks and tool interactions. The authors describe 97 tasks and 629 security test cases, together with an extensible framework for new attacks and defences [3]. This matters for the design of an evaluation: an agent's planning, tool use and ability to complete legitimate work can be observed alongside its resistance to malicious content. A defence that prevents attacks by preventing useful work must be judged differently from one that preserves a large share of legitimate task completion.

The environment is also a reminder that utility and security require joint measurement. Attack prevention can improve when a system refuses more requests, but the resulting refusal may also block legitimate analysis. Conversely, granting a broader tool set can improve task completion while enlarging the space of harmful actions. The appropriate report contains both outcomes under the same configuration. Comparing one system's security score with another system's utility score from a different task set cannot reveal the trade-off between them.

4.3 Static and adaptive evaluation

A fixed collection of attacks is reproducible and useful for regression testing. It can also become easier to defend against once the exact collection is known. An adaptive evaluation allows an attacker to respond to the defence. AgentDojo was designed to support evolving tasks and attacks [3]. The reviewed material does not justify a numerical claim about how every adaptive attacker changes its results. It does establish why an extensible environment is more informative than treating one frozen test suite as a permanent certificate.

5. Defences inside the model

5.1 Instruction hierarchy

Wallace and colleagues propose a hierarchy that assigns different priority to different instruction sources. Their training procedure teaches a model to ignore conflicting lower-priority instructions. Applied to GPT-3.5, the authors report improved robustness, including against attack types absent from training, with limited degradation on standard capability measures [4]. This is evidence for a particular training intervention. Its scope depends on whether the application preserves the relevant distinctions when constructing the model input.

A hierarchy in the interface and a hierarchy learned by a model are connected but separate objects. The application must first label and route the material correctly. The model must then behave consistently with those labels. If a trusted instruction is accidentally assembled from untrusted text, priority metadata alone cannot recover the application's original intent. Evaluating hierarchy training therefore requires examples that test both instruction conflict and the provenance of the content carrying the instruction.

5.2 Structured queries

StruQ combines a secure front end with a model trained to distinguish instruction and data channels. Chen and colleagues describe fine-tuning examples that include misleading instructions within the data portion, teaching the model to ignore them. They report substantially improved resistance with little or no utility loss in their evaluation [5]. The method is more specific than adding quotation marks around a document. Its claimed effect concerns the joint formatting and training scheme.

These results support further investigation of explicit source separation. They do not establish that every production model interprets a delimiter as an enforceable boundary. An application that uses a model without the relevant training cannot assume it has inherited StruQ's reported behaviour. Equally, a system with structured inputs still needs to decide which operations a model output may trigger. Model-side resistance and execution-side permissions address different failure points and can be evaluated independently.

6. Architectural controls and their assumptions

The CaMeL report proposes a protective layer that separates control flow and data flow and checks capabilities when tools are called. Its report describes solving 77% of AgentDojo tasks with the stated provable-security property, compared with 84% for an undefended system [6]. The comparison exposes a utility cost rather than treating security as free. The proof claim belongs to the specified architecture and assumptions; this review has not audited the proof or recreated the evaluation.

Capability checks can constrain what happens even when a model has read an injected instruction. A permission can refer to the data being transmitted as well as to the operation. Allowing an agent to send a message does not imply that every available file may be attached to every recipient. This is why operation-level controls and information-flow controls are distinct. One asks whether a tool may run. The other asks whether the particular source information is permitted to move to the particular destination [6,10].

Saltzer and Schroeder's account of protection principles predates language models by decades. Its relevance is architectural: least privilege and mediation of access concern the authority a program receives [10]. Applied to an agent, those principles direct attention to identities, objects and permitted operations. They do not estimate injection resistance. A well-designed permission boundary can limit consequences without improving the model's answer quality, while a better model can still operate with unnecessarily broad authority.

6.1 The boundary of the architectural claim

The full CaMeL manuscript separates a privileged planner from a quarantined model that processes untrusted content without tool access. The authors show why that separation alone is insufficient: an unchanged plan can still send the wrong document if untrusted material changes its arguments. Their interpreter tracks value provenance and permitted readers to constrain those flows. The manuscript also identifies side channels and text-only answer contamination outside parts of its protection claim [6]. These details narrow the interpretation of provable security: a guarantee applies to a formalised property and threat model rather than every possible harmful outcome.

That boundary is useful for evaluating any architectural claim. Preventing an unauthorised data flow does not establish that a summary is truthful, that a user understands the result or that an approved action is commercially wise. Each requires its own specification and evidence. An application can therefore need both enforced execution limits and assessment of the answer shown to the user, without treating the two as interchangeable measures of safety.

7. Containment is broader than a sandbox label

A sandbox is an execution boundary. Its practical meaning depends on the resources inside it and the resources reachable from it. An agent running in an isolated process can still have broad access if that process receives a powerful API credential. A network boundary may prevent arbitrary outbound connections while leaving an approved integration able to transmit data. The security description must therefore state which identity performs each operation and which enforcement point limits it. The word sandbox supplies none of those details by itself.

OWASP's excessive-agency guidance identifies excessive functionality, permissions and autonomy as related causes of damaging actions [9]. These categories distinguish a tool that offers too many operations from a credential that reaches too many resources, and from an agent permitted to proceed too far without intervention. Reducing one does not guarantee that the others are controlled. A narrowly scoped send function can still be dangerous if its recipient and payload are unconstrained.

NIST's Zero Trust Architecture concerns access to resources without relying on a broad assumption of trust based on network position [11]. The conceptual implication for an AI workflow is that moving execution into a company network does not settle authorisation. An internal system can contain outdated sharing permissions or data irrelevant to the current task. The publication record establishes the standard's scope; detailed implementation choices require the actual architecture and a more extensive standards review than conducted here.

8. Review, monitoring and evaluation design

A human approval point changes the workflow only if the reviewer can see the proposed external effect. Reviewing a generated paragraph is different from approving the precise recipient, attachment, spend limit or campaign destination. An interface that hides those details leaves the reviewer unable to assess the operation being authorised. This is an implication of complete mediation and explicit authority, rather than an experimentally estimated guarantee that inserting a human will prevent all incidents [9,10].

Logs can distinguish a model's proposal from the tool gateway's decision and the external system's result. Without those distinctions, a failed transmission may be mistaken for a safe model response, or a rejected proposal may be counted as an actual breach. NIST's security-control catalogue provides a wider framework for access, audit and incident controls [12]. The current review uses that catalogue as context and does not claim that any particular deployment meets its requirements.

The evaluation set should correspond to the permissions being assessed. If a system can only read approved documents, tests of unauthorised publishing are informative mainly about latent model behaviour. If publishing is enabled, they also test a real execution path. The same malicious content can therefore warrant different severity judgements in different architectures. Measuring completion of legitimate tasks alongside attempted and completed harmful actions makes that difference visible without collapsing it into a single undifferentiated success rate.

9. Application to marketing workflows

Marketing systems combine unusually varied inputs: public webpages, creative files, agency documents, performance exports and customer messages. Their heterogeneity matters because source trust can change inside one task. A retrieved competitor page is relevant evidence about a competitor, but it has no standing to change the agent's campaign budget. A customer message can be evidence about a complaint without authorising access to other customers' records. These examples illustrate the authority distinction; they are not reported incidents or estimates of attack prevalence.

A system can also cross from internal analysis to external communication during a seemingly routine sequence. Summarising results, generating recommendations and sending a campaign update may be presented as one workflow, although each uses different permissions. The relevant boundary is crossed when analysis becomes an external effect. Keeping that boundary explicit permits separate measurement of answer contamination and unauthorised execution. It also allows an organisation to test useful analytical work before assigning broader operational authority.

WebArena evaluates agents through tasks in an interactive web environment; this supplies a functional baseline distinct from resistance to malicious content. [14] τ-bench examines tool, user and policy interaction, including repeated success rather than one successful trajectory. [15] The ML Test Score makes testing and monitoring explicit production concerns. [16]

CheckList demonstrates targeted behavioural testing. Applying that principle to an agent means distinguishing its ordinary task failures from failures caused by an injected instruction; the original CheckList experiments do not themselves validate an agent-security defence. [17]

10. Limitations and conclusion

The evidence base is selective and several recent sources were consulted only through abstracts. This review does not establish the relative performance of current commercial agents, verify a specific vendor's safeguards or calculate an organisation's incident probability. Attack research evolves with models and interfaces; a result on a named historical configuration cannot be transferred automatically to a different deployment. NIST's adversarial-machine-learning taxonomy supplies broader terminology, but terminology alone cannot resolve those empirical gaps [13].

Indirect prompt injection is a demonstrated route for adversarial content to alter an LLM-integrated system's behaviour. The reviewed research supports defences at several levels, including trained instruction priority, structured data separation and enforced control or information-flow boundaries. Their claims have different assumptions and utility costs. For marketing applications, the decisive assessment is of the complete authorised workflow: what untrusted material can influence, which tools can execute, which information can leave and whether legitimate work remains possible under those constraints.

Source access and appraisal register

The additional comparative sources in references 14–17 are used for the specific distinctions cited in the discussion. Access is limited to previously inspected primary-source abstracts, publication records or manuscripts. Their inclusion does not imply a fresh full-text risk-of-bias appraisal or direct validation in the application discussed here.

Research sources [1,2,3,4,5,7] were consulted through author abstracts and arXiv records. The accessible CaMeL manuscript [6] was additionally inspected for design, threat model and side-channel limitations; the proof and statistical results were not independently audited. Public guidance pages [8,9] and the MIT-hosted text [10] were consulted for the concepts stated. Sources [11,12,13] were inspected at official publication-record level. These standards are contextual references, not evidence of an audited implementation. No independent replication was undertaken.

References