In one paragraph

Most organisations respond to prompt injection by strengthening the system prompt. They add instructions to ignore user-supplied commands, enumerate forbidden behaviours, escalate the emphasis. That is a reasonable first move and a poor last one. Instructions telling a model to ignore instructions are themselves more text in the same undifferentiated context, and a defence built entirely from them degrades silently. It stops the attacks somebody thought of, gives no signal when it fails, and produces confidence out of all proportion to the protection. The load-bearing question is not whether the model can be induced to misbehave. It is what the model is authorised to do once it has been. An assistant that can only draft text for a human to review is a manageable exposure whatever it is persuaded to write. An assistant that can send email, move money or modify records is a different risk entirely, and the difference is authorisation architecture and not prompt wording.

What system prompt hardening actually buys you

Worth being precise, because the control is genuinely useful and routinely oversold.

Hardening raises the cost of casual attacks. The overwhelming majority of injection attempts against a production system are unsophisticated: a curious user pasting something they saw on social media, an automated scanner, a low-effort probe. A well-constructed system prompt defeats most of these. That has real value, because it reduces noise, keeps the logs legible, and means the attempts getting through are worth investigating.

It also establishes intent. When something goes wrong, the difference between a system whose operator specified its constraints and one that shipped with a two-line prompt is visible to a regulator, an auditor and a court. That is not a technical benefit. It is still a real one.

What hardening does not do is create a boundary. There is no syntactic separation between instructions and data in a language model context, which is the nature of the vulnerability and not a gap in anyone's implementation. Every prompt-level defence is probabilistic, and its effectiveness against attacks nobody has thought of is unknown and unmeasurable.

The system prompt hardening control is correctly classified as preventive. It is correctly not classified as sufficient.

The techniques, and their ceilings

Explicit instruction precedence. Stating that instructions in retrieved or user-supplied content must not be followed. Reduces casual attempts. Defeated by any framing that does not present itself as an instruction.

Delimiting untrusted content. Wrapping retrieved material in markers and telling the model to treat everything inside as data. Helps. Fails against content that closes the delimiter, or describes itself as being outside it.

Role and scope constraints. Narrowing what the assistant will discuss at all. One of the more effective techniques, because a genuinely narrow scope gives an attacker less to work with. Also one of the least popular, because product teams want the assistant to be broadly capable.

Instruction repetition and position. Restating constraints after untrusted content, and not only before it. Measurably helps with long contexts. Does not survive a determined attempt.

Output format constraints. Requiring structured output that a downstream parser validates. This one differs in kind from the others, because it is the point where prompt-level defence starts becoming architectural. The constraint is enforced outside the model.

The pattern across all five is the same. Each raises cost. None creates a boundary. Their combined effect against novel attacks is unknown. Treat the set as noise reduction, and put your reliance elsewhere.

One anti-pattern deserves naming. Organisations put sensitive material in the system prompt on the assumption that users cannot see it. They frequently can, which is system prompt leakage. OWASP broadened that category in 2026 to cover retrieval schemas and policy logic as well, precisely because operators kept assuming context was hidden when it was reachable. Treat a system prompt as public.

Why OWASP moved Excessive Agency to LLM03

The 2026 GenAI LLM Top 10, published on 4 August 2026, made one large ranking change. Excessive Agency rose from LLM06 to LLM03, the biggest upward move on the list. Improper Output Handling fell from LLM05 to LLM10, and not because it became safer: input-boundary injections and cross-pipeline disclosures came to dominate the incident record, so it lost relative share.

Prompt injection held LLM01 throughout.

Read those movements together and they tell one story. The attack did not change. What changed is what the attack reaches. Systems moved from answering questions to taking actions, calling tools, querying systems, initiating transactions, and the incident data followed. The same injection that once produced an embarrassing answer now produces an action.

That is the empirical case for the argument above. If injection is unfixable at LLM01 and the consequences are what escalated, then the effective control surface is excessive agency, and not the prompt.

The five controls that change the outcome

None of these prevents injection. Together they determine whether an injection is an incident or a log entry.

Authorise tools per task, not per session. Every tool the model can call is an action an attacker can trigger. The default pattern grants the assistant its full tool set for the session and relies on the prompt to govern use, which means a successful injection inherits everything.

Narrower grants are the alternative. Give a task the tools it needs, for the duration of that task. A summarisation request does not need write access. A lookup does not need send. This is ordinary least-privilege thinking, and it is unusual in AI deployments only because the model's flexibility makes broad grants feel natural.

Require confirmation for anything irreversible, and make the confirmation meaningful. A human is shown what will happen and can decline. A dialogue dismissed by habit is not a confirmation.

Treat model output as untrusted input. Output rendered into a browser, passed to a shell, interpolated into a query or written to a database should be validated exactly as user input would be. That is improper output handling, and it is where an injection stops being an embarrassment and becomes a compromise.

The output validation guardrails control is the detective counterpart to prompt hardening's preventive role, and it is the more reliable of the two because it is deterministic. A schema either validates or it does not.

Know the trust level of everything in the context. You cannot syntactically isolate retrieved content. You can know it is there. A system tracking which parts of its context came from trusted configuration, and which arrived from a document, a web page or a user, can reduce its own privileges when untrusted content is present: dropping to read-only tools, requiring confirmation, or routing to a human.

This is the most under-implemented control on the list, and the one that most directly addresses indirect injection, where the victim is not the attacker.

Log the whole context, not just the user turn. After an incident the question is what the model actually read. If logging captures only what the user typed, an indirect injection through a retrieved document is invisible, and you are left with an inexplicable action and no cause.

Monitoring and logging for a language-model system means capturing the assembled context, the tools called, and the output, with enough retention to investigate something noticed weeks later. It is also what makes sensitive information disclosure detectable instead of merely possible.

Keep a human where the consequence warrants it. Human-in-the-loop review is unfashionable and remains the most reliable control available where the consequence is high. The test is not whether a human is nominally present. It is whether they have the information, the authority, the time and the standing to say no, and whether the system is designed so that saying no is the easy path.

What a real injection test looks like

Adversarial robustness testing for injection differs from conventional security testing in three ways that catch teams out.

Test the assembled system and not the model. The vulnerability lives in how your application composes context. Testing the model in isolation tells you about the model, which is not what you deployed.

Test indirect paths, which means enumerating content sources. Every channel reaching the context is an attack surface: uploaded documents, retrieved pages, email bodies, calendar entries, database fields, filenames, image metadata. Most teams test the chat box and stop. The chat box is the least dangerous entrance.

Re-run at every model version and every prompt change. Injection resistance does not carry across versions. A finding closed against one model version can reopen silently against the next, and a prompt change made for an unrelated product reason can undo a mitigation nobody documented as one. A test suite running only at annual pen-test is measuring a system that no longer exists.

Two practical notes. Test for jailbreaks separately from injection, because they have different owners and conflating them produces a report nobody can action. And record what the model was able to do in each successful case, and not merely that it complied. That is the finding that drives the control work.

What to evidence

For a governance function, the artefacts that matter are narrower than the control list.

  • The tool authorisation model, written down: which tools, granted under what conditions, with what confirmation requirements. This is the document a supervisor will ask for.
  • The output validation contract between the model and every downstream consumer.
  • The content source inventory, meaning every channel that can reach the context, which is also the test scope.
  • Test results by model version, showing the suite was re-run and not inherited.
  • Incident records including near-misses, since a blocked attempt is evidence the control worked and an unblocked one is evidence it did not.

The security pillar maps these against the OWASP categories, and the prompt injection risk entry carries the mapped controls.

Three questions a board should ask

"Are we protected against prompt injection?" No, and neither is anybody else. It is an unsolved problem in the architecture of language models, and not a gap in our implementation. The correct question is the next one.

"What could an attacker actually make our AI systems do?" This should have a specific answer per system, derived from the tool authorisation model and not estimated. If the answer is "we are not sure", that is the finding.

"How would we know?" Detection and logging, and specifically whether the logs capture the assembled context or only the conversation.

A board getting clear answers to the second and third questions can be relatively relaxed about the first. A board getting a reassuring answer to the first should be concerned about all three.