Prompt injection is described as a model vulnerability and treated as a model problem. It is neither. The injection changes what the model proposes; what determines the consequence is which tool the proposal can reach and what that tool is permitted to do.

Published guidance distinguishes direct injection through user input from instructions arriving via external content — retrieved documents, websites, tool results — and states plainly that retrieval and fine-tuning do not fully mitigate the vulnerability. An injection can also corrupt an answer without invoking any tool at all.

The authority question, not the text question

The design position that follows is to stop trying to make the model refuse and start constraining what a compromised proposal can accomplish.

Limit tool functionality and permissions to what the task needs. Preserve the user’s own scope rather than granting the application more than the person it serves. And enforce authorisation in the system that executes the action, rather than asking the model to decide whether its action is permitted.

That last point is the structural one. A control living inside the text an attacker can influence is not a control. The model’s output is a proposal, and the executing system validates it.

Five boundaries and the adversarial question at each

Retrieval. Provenance and access checks before content enters the context. The question: can content outside the user’s authorised scope be retrieved, including through a shared source?

Interpretation. Clear separation between trusted policy and untrusted content. The question: can external instructions alter the answer or redirect later processing?

Tool request. Restricted functions, validated arguments, limited destinations. The question: does a syntactically valid request exceed the task’s or the user’s authority?

Execution. Enforced downstream permissions and approval for consequential actions. The question: can the model, or another route, bypass the required decision?

Observation. Audit records, response ownership, rate limits. The question: was the action blocked, or was it merely detected after the harm?

That final distinction runs through all of it. Preventing an action and noticing it afterwards are different outcomes, and a control map that does not record which one each layer achieved is a list of hopes.

What a passing test actually shows

Take a retrieved document instructing a summariser to send unrelated account information elsewhere. In a well-bounded system the harness records a proposed outbound action, the downstream service rejects the destination, and the user’s scope excludes the unrelated records.

The honest report says: two barriers held, each verified by a separate check with synthetic fixtures. It does not say the model resisted the instruction — the model did not resist, it complied and was stopped. And it does not say every exfiltration path was tested.

Testing happens in an authorised environment with synthetic fixtures and benign action substitutes. Preserve the model and configuration, the content, the tool path, the expected outcome, the actual action, and the residual gaps. Passing a finite test set establishes results for that set.

Read-only is not harmless

Two assumptions do most of the damage.

The first is that read access is safe. Exfiltration requires a destination, not a write permission, so an allowed output channel is as consequential as a database write. A read-only agent with an outbound HTTP tool is an exfiltration path.

The second is that format validation is authorisation. A well-formed tool call with valid arguments has satisfied a schema. Whether this request, from this user, to this target, is permitted is a different question answered somewhere else.

The threat model has to move with the system

Prototype threat modelling is a maintained account of what is being built, which failures are plausible, how they will be addressed, and how that response gets checked. Threat modelling is repeatable and starts early, with the model maintained as the system changes.

The prototype case is specific: an early experiment has a small boundary, and connecting real data or action tools changes it. A summarisation prototype that gains a tool able to update customer records has a diagram showing retrieval and display, and a system that can now write. Updating the diagram is not a mitigation; the new boundary needs actor permissions, approval requirements, and checks for authorised and unauthorised updates.

Neither the prototype label nor a completed diagram establishes low risk, and a statement of intent is not a deployed control.

When to test again

Assessment methods answer different questions and none certifies the absence of vulnerabilities. Penetration test results are specific to the assessors, the time, and the agreed rules of engagement, with new systems, major changes, and newly relevant attacks as the considerations for timing.

Six triggers, each with its limit. A design or architecture change gets a trust-boundary review, which does not test deployed enforcement. New code or dependencies get relevant checks, with tool coverage stated. First real data or user exposure gets a controls reassessment, because synthetic-data checks need not cover actual integrations. A new privileged tool or external connection gets the changed authorisation boundary exercised, because earlier read-only tests do not cover new writes. Transfer or a major upgrade gets stale evidence revisited. And remediation gets the original issue reproduced and the correction tested, because a closed ticket is not evidence of repair.

The transfer case is the one that catches teams. A report covering an older build, taken before a shared export worker was added, covers neither the current build nor the export path. The response is targeted checks for what changed and an explicit record of which earlier evidence still applies — rather than discarding everything or accepting the old pass.

The rule

What stays fixed is that the blast radius is set by permissions, not by prompts. What changes is the tool surface, and every addition reopens the question of what an injected instruction could now accomplish.

Not to be confused with

A solved problem. These are proposed layers rather than independently proven mitigations, and no protection rate is established for any of them.

Risk transfer. Moving a task to a supplier does not remove the underlying threat or the statutory responsibility attached to it.