What to do

Reducing prompt injection risk: a plan for UK organisations

You cannot patch prompt injection away, so you contain it. Limit what AI tools can read and do, keep a person or a fixed rule in front of risky actions, and watch for misuse.

Last reviewed against NCSC (UK), OWASP Gen AI Security Project and UK Government (DSIT). Sources

The aim

Reduce, do not expect to remove

The NCSC states that the best to hope for is reducing the likelihood or impact of attacks [1]. It also says that if the system's security cannot tolerate the remaining risk, it may not be a good use case for a language model [1]. That is a design decision for leaders, and it comes before any tooling.

Beware of the word "stop"

The NCSC challenges claims that prompt injections can be stopped, and advises favouring suppliers who explain how they reduce the risk [1] [2].

Four areas

How the NCSC organises its advice

The NCSC maps its advice to four areas [1]. Use them as the structure for your own plan.

Cloud above a green shield with a padlock beside a stack of blue servers

Awareness

Make sure developers know prompt injection is a class of vulnerability, since many experienced web developers do not [1]. Make security teams and risk owners aware that no single product removes it [1].

Factory buildings linked through a hub to a phone showing a fingerprint and shield

Secure design

Assume the system can be confused, and prefer fixed, non-model controls that constrain which actions are possible at all [1]. Do not give privileged tools to a model that handles content from untrusted parties [1].

Two server towers, one on fire, linked by a cycle of arrows to a laptop

Make it harder

Marking external content, for example with delimiters, can make injection harder, but deny-listing known phrases is unreliable because attackers can rephrase [1]. OWASP adds that output formats can be validated with deterministic code [4].

Businessman with empty pockets imagining stacks of coins and banknotes

Monitor

Keep enough of a record to see odd behaviour [1]. A run of failed calls can mean someone is refining an attack [1]. The monitoring page says what to capture.

The order

What a sensible rollout looks like

  1. 1

    Inventory the tools and what they can reach, using the exposure checklist.
  2. 2

    Remove the riskiest combinations of data, outside content and outbound routes [6].
  3. 3

    Add approval for high-risk actions [4].
  4. 4

    Turn on logging and decide who reviews it [1].
  5. 5

    Test with adversarial prompts and rehearse the response [4].
Dark blue arched badge with a large green and blue tick across it

Controls

What each one can and cannot do

ControlHelps withLimit
Least privilegeCaps what a misled tool can do [4]Does not stop the model being misled
Human approvalCatches high-risk actions [4]People can approve by habit
Output validationRejects unexpected formats [4]Cannot judge intent
FilteringBlocks some known patterns [4]Attackers can rephrase around it [1]
LoggingShows misuse and probing [1]Detects, does not prevent

Controls on this scale belong in your supplier questions too: see what to ask AI suppliers and how to monitor AI tools.

Fixed versions

Which versions fix it

Find your product and line, then compare your full version number with the fixed release. Anything below it on the same line is still exposed.

ProductLineFixed inNote
Microsoft 365 Copilot (EchoLeak, CVE-2025-32711) Cloud service Fixed by Microsoft; no customer action required[7] A fix for one flaw does not remove the wider weakness in how models handle instructions and data.

What to do

Eight steps, in order

  1. Step 1

    List every AI tool and what it can reach[6]

    Record each chatbot, assistant and agent in use, including those staff adopted themselves. For each, note what content it reads, what data it can see and what actions it can take.

    Who: IT and security leads

  2. Step 2

    Never combine private data, untrusted content and an exit route[6]

    Where an AI tool reads content you do not control, remove its access to private data or its ability to send anything out. Willison's advice is to avoid the combination entirely.

    Who: IT, development and security teams

  3. Step 3

    Cut the privileges of tools that read outside content[1]

    Do not give privileged tools to a model that processes content from untrusted parties such as inbound email. The NCSC cites the principle that when a model processes information from a party, its privileges drop to those of that party.

    Who: Development and security teams

  4. Step 4

    Put a person or a fixed rule in front of risky actions[4]

    Require human approval for high-risk actions and use deterministic code, not the model, to enforce limits and validate output formats.

    Who: Product owners and development teams

  5. Step 5

    Do not rely on filters and phrase blocking[1]

    The NCSC warns against deny-listing phrases such as 'ignore previous instructions', because attackers can rephrase endlessly. Treat filters as one partial layer.

    Who: Security architects

  6. Step 6

    Log inputs, outputs and tool calls[1]

    Keep enough records to spot suspicious activity, and treat repeated failed tool or API calls as a possible sign of an attacker refining an attack.

    Who: Security operations and IT

  7. Step 7

    Ask suppliers how they reduce prompt injection[2]

    Be sceptical of products that claim to stop prompt injection and favour suppliers who can explain how they reduce its likelihood and impact. Ask about the data, model and software supply chain behind the product.

    Who: Procurement and security leads

  8. Step 8

    Test with adversarial inputs and plan a response[4]

    Treat the model as an untrusted user and test it with adversarial prompts. Agree who acts if an AI system's integrity, availability or confidentiality is compromised.

    Who: Security leads and incident owners

How CyPro can help

Need a hand with any of this?

Patching is one job. Keeping a vulnerable system safe until it is patched, and proving it, is several more. CyPro's consultants, testers and SOC analysts can take any of them off your plate.

Scanner checking internet-facing systems for weaknesses

Vulnerability scanning

Find every internet-facing system you run, including the forgotten ones, and see which are still on a vulnerable build.

See the scanning service
Cyber security consultants planning hardening work

Hardening and segmentation

Our consultants put the controls in place that limit the damage when something is missed: firewall rules, network isolation and tighter admin access.

More on cypro.co.uk
Security analysts monitoring systems around the clock

24/7 security monitoring

Our SOC analysts watch your systems day and night for the signs of an attack in progress: unexpected processes, new outbound connections, logins that do not fit.

More on cypro.co.uk
Penetration tester probing an application for weaknesses

Penetration testing

A focused test of your systems and the controls around them, so you know they hold before an attacker finds out for you.

More on cypro.co.uk
Incident responders containing an attack

Incident response

If you may already be compromised, our responders contain it, preserve the evidence, find out what was touched and get you running again safely.

More on cypro.co.uk
Security lead advising a board

Fractional CISO for the board

A senior security lead who advises the board on what to fix first, what to accept and what to tell customers, and owns the decision record.

More on cypro.co.uk
Rocket launching from a cloud

Know your exposure

Not sure you are protected?

Prompt injection cannot be patched away, so the useful question is how far a manipulated tool could reach. Testing your AI-connected systems the way an attacker would shows where the limits on data and actions need tightening.