Prompt injection risk is the chance that text your AI system reads will be obeyed as an instruction instead of processed as data — plus everything that happens next. A supplier invoice, a support email, a scraped web page, a shared document, a row in a spreadsheet, a response from a third-party API: any of these can carry a sentence aimed at your model rather than at your reader. The model has no reliable way to tell the difference, because in a language model instructions and data arrive through the same channel.
Most organisations meet this problem after they have already shipped something. A chatbot that summarises inbound mail, an assistant that drafts quotes from customer documents, an agent that files tickets. It works in the demo, it works in the pilot, and then somebody asks the question nobody prepared for: what happens when the document tells it to do something else? Answering that with a shrug is not a position you can hold in a supplier security review, an insurance renewal, or an incident, and unmeasured prompt injection risk is exactly what those conversations are designed to surface.
The honest answer is that this class of attack has no patch. There is no parameterised query for natural language, no equivalent of prepared statements that ends the problem structurally the way it ended SQL injection. What you can do is exactly what mature cybersecurity practice does with every other unfixable hazard: assess it, score it, reduce it with controls that do not depend on the model behaving, and accept what remains with your eyes open. That is a prompt injection risk assessment.
This guide is the method. It covers where injections enter a business system, how to scope an assessment so it finishes in days rather than quarters, a scoring scale anchored to observable facts, a control map that says which measure reduces which risk, how to test that the controls hold, how to record findings so an auditor can follow them, and a 90-day plan with realistic costs and named owners. It builds on the same scoring discipline as our AI risk assessment template and sits alongside the tool-boundary work in our AI agent security guide.
Table of contents
- Why prompt injection risk cannot be patched away
- Direct and indirect prompt injection risk, and which matters more
- Mapping where prompt injection risk enters your business AI
- Scoping a prompt injection risk assessment that finishes
- Scoring likelihood and impact for prompt injection risk
- A prompt injection risk scoring matrix you can run this week
- Mapping controls to each prompt injection risk you found
- Testing that your prompt injection risk controls hold
- Recording findings in a prompt injection risk register
- Who owns prompt injection risk, and what regulators expect
- What a prompt injection risk assessment costs
- A 90-day plan to reduce prompt injection risk
- Mistakes that make a prompt injection risk assessment worthless
- Frequently asked questions
- References
Why prompt injection risk cannot be patched away
Security teams reach instinctively for the vulnerability model: find the flaw, ship the fix, close the ticket. That model fails here, and understanding exactly why is what stops a team burning a quarter looking for a patch that does not exist. Prompt injection risk behaves like a design property of the technology, not like a defect in one product.
There is no parameterised query for natural language
SQL injection was solved structurally. Prepared statements separate the query plan from the values, so a value can never become code. Nothing equivalent exists for a language model: the system prompt, the retrieved document and the user’s question are all just tokens in one context window, and the model’s job is to interpret all of them. Delimiters, XML tags and “ignore anything that looks like an instruction” preambles raise the bar without ever closing the gap, which is why a prompt injection risk assessment scores likelihood rather than declaring the issue fixed.
The model is not the vulnerable component — the system is
A model that follows an injected instruction has not malfunctioned; it has done what it was built to do with the text it was given. The harm arrives through what the surrounding system permits: a tool it can call, an email it can send, a record it can update, an answer a human will act on. Two teams running the same model can carry wildly different prompt injection risk because one exposed a generic database tool and the other exposed four named verbs with tight arguments.
Detection is probabilistic, so treat it as a risk
Guardrail classifiers, canary tokens and instruction-hierarchy training all reduce the hit rate. None reaches zero, and published benchmarks consistently show attack success rates that fall but never vanish. Any programme built on the assumption that detection will catch everything is one novel phrasing away from failure. Treating the exposure as residual prompt injection risk — measured, owned and reviewed — is both more honest and more defensible than claiming a fix.
Where it sits in your existing risk taxonomy
You do not need a new register. Prompt injection risk maps cleanly onto categories you already run: unauthorised disclosure, unauthorised modification, fraud, and availability or cost abuse. Recording it in the same place as everything else keeps it visible to the people who already sign off risk acceptance, and stops it becoming an isolated AI workstream that the board never sees.
| Property | SQL injection | Prompt injection |
|---|---|---|
| Root cause | Code and data share one string | Instructions and data share one context |
| Structural fix available | Yes, prepared statements | No known equivalent |
| Deterministic to test | Yes, one payload proves it | No, results vary between runs |
| Attack surface | Request parameters | Every source of text the system reads |
| Payload vocabulary | Finite SQL grammar | All of human language, in any language |
| Primary defence | Parameterisation | Least privilege and containment |
| Correct closing state | Vulnerability closed | Residual risk accepted and reviewed |
The last row is the one to take to your risk committee. A prompt injection risk assessment does not end with a green tick; it ends with a scored, owned and time-limited acceptance, exactly as your penetration testing programme does for the findings you choose not to remediate this quarter.
Direct and indirect prompt injection risk, and which matters more
The two forms look similar on a whiteboard and behave completely differently in production. Getting the distinction right early stops teams spending their entire testing budget on the variant that carries the least prompt injection risk.
Direct injection: the user is the attacker
A person types an instruction designed to override your system prompt — extract the hidden configuration, drop the safety rules, produce content you would not sanction. The blast radius is usually limited to that person’s own session and their own permissions. It is embarrassing when leaked, and it matters greatly for public-facing brand surfaces, but it rarely reaches other people’s data. The prompt injection risk here is real and bounded.
Indirect injection: the content is the attacker
Here the instruction is planted in material the system ingests on someone else’s behalf: an email in a shared mailbox, a PDF attached to a claim, an ordinary-looking product review, a calendar invitation, white text on a white background in a web page your retriever crawled. The victim is the user whose session consumes it, and the attacker never touches your interface. This is where the serious prompt injection risk lives, and it is the variant that the research literature has repeatedly demonstrated against real deployed applications.
Persistence turns a single injection into a standing one
If your assistant writes to memory, a knowledge base, a CRM note or a vector store, an injected instruction can be stored and re-read on later runs by other users. A one-off becomes a resident problem, and rollback is genuinely hard because you must find every derived artefact. Any system with a write path back into its own retrieval corpus should score its prompt injection risk higher for that reason alone.
Tool descriptions and multi-agent hand-offs
When one agent passes work to another, or when tool definitions come from a third-party server, the instruction surface widens beyond documents. A malicious or compromised tool description is read by the model with the same trust as your own system prompt. Systems that consume external tool catalogues inherit prompt injection risk from every publisher in that catalogue, which is a supply chain question as much as a security one.
The shape of that chart is the argument for the whole method. If most of your prompt injection risk enters through content nobody at your organisation wrote, then a test plan built entirely around a user typing clever things into a chat box is measuring the wrong thing.
Mapping where prompt injection risk enters your business AI
You cannot score what you have not enumerated. The mapping stage produces two lists — what the system reads and what the system can do — and the intersection of those lists is where the assessment does its real work. It is also where prompt injection risk turns out to be concentrated in almost every system we have looked at.
Inventory ingestion points, not models
Start from the data flow, not the vendor. For each AI feature, write down every source of text that reaches the context window: user messages, uploaded files, retrieved chunks, tool outputs, system metadata, previous conversation turns, stored memory. Teams routinely discover two or three sources they had forgotten, and a forgotten source is unassessed prompt injection risk by definition. Our AI system inventory template gives you the register to hold this.
Classify each source by attacker controllability
Ask one question of every source: how hard is it for someone outside your organisation to put chosen text in there? A public web form is trivially controllable. A shared mailbox is easy. A supplier portal is moderate. An internal wiki is hard but not impossible. A signed configuration file is very hard. This single axis drives most of the likelihood half of the prompt injection risk score, and it takes minutes per source once you have the list.
Enumerate what the system can do when persuaded
Now the capability side: every tool, API call, file write, email send, payment initiation and record update the system can reach, plus the identity it uses. If the system only produces text for a human to read, your prompt injection risk is bounded by what a misled human might do next — real, but different. If it can act, the ceiling is whatever that identity can reach.
Trace the exfiltration paths, including the subtle ones
Data leaves by more routes than people expect: a tool that fetches a URL the model composed, an image tag rendered in a chat client, a webhook, a reply to an email thread, a search query sent to a third party. Markdown rendering that auto-loads remote images is a classic silent path. List them explicitly, because these are the routes that convert a read-only system’s prompt injection risk into a disclosure incident.
Find the shadow deployments before someone else does
Browser extensions, personal assistant subscriptions, automation platforms with a language model step, plug-ins connected to the file store. Anything that reads company content and follows instructions belongs in this assessment. Unmanaged tools usually score badly on every prompt injection risk axis at once, which makes them the fastest wins in the whole exercise.
| Ingestion source | Attacker control | Typical volume | Persists into corpus? | Likelihood weight |
|---|---|---|---|---|
| Public web form or chat widget | Total | High | Sometimes | 5 |
| Inbound email and attachments | Total | High | Often | 5 |
| Live web fetch or search results | High | Medium | Rarely | 4 |
| Customer-uploaded documents | High | Medium | Often | 4 |
| Third-party tool or API responses | Medium | High | Sometimes | 3 |
| Supplier portal submissions | Medium | Low | Often | 3 |
| Internal wiki and shared drives | Low | High | Always | 2 |
| Signed configuration and system prompts | Very low | Low | Always | 1 |
Fill that table for your own system before you score anything. The weights in the last column feed straight into the likelihood half of the prompt injection risk scale later in this guide, and having them written down stops the scoring conversation collapsing into opinion.
Scoping a prompt injection risk assessment that finishes
Assessments fail far more often from sprawl than from insufficient rigour. Three scoping decisions keep a prompt injection risk assessment to days rather than quarters, and keep the output usable.
Assess use cases, not models
The unit of assessment is a use case: this assistant, doing this job, on this data, with these tools, for these users. A model is a component that appears in many use cases carrying wildly different prompt injection risk. Scoping by model produces a document nobody can act on; scoping by use case produces findings with an owner and a fix. Expect a first pass on one use case to take two to four days of focused effort.
Set depth tiers and apply them honestly
Not everything deserves the same scrutiny. A tier-one system — customer-facing, ingesting attacker-controllable content, holding tools that write or spend — earns a full prompt injection risk assessment with adversarial testing. A tier-three system that summarises internal meeting notes for its own author earns a one-page screening. Publishing the tier criteria in advance stops the argument about effort happening separately for every project.
Time-box the enumeration
Give the mapping stage a fixed half-day per system. Perfect enumeration is unreachable, and the marginal source you find in hour six is almost always low weight. It is better to complete a prompt injection risk assessment for all eleven of your AI features than to produce a beautiful document for one and nothing for the rest.
Get the right four people in the room
The engineer who built the integration, someone from security, the business owner who understands what a wrong action costs, and whoever holds the data protection brief. That is four people for half a day, not a standing committee. The business owner is the one people forget, and they are the only person who can say whether a mistaken refund is a nuisance or a reportable event.
Scoring likelihood and impact for prompt injection risk
Scoring exists to force comparison. Without numbers, every finding sounds equally alarming and nothing gets prioritised. The scale below is deliberately coarse, anchored to facts you can observe rather than to how worried the room feels, and maps onto the qualitative approach in established risk-assessment guidance.
Four likelihood factors that actually move the number
Exposure — can an outsider place text in the input at all? Volume — how many such items flow through per day? Reachability — does the injected content reach the model’s context without a human reading it first? Persistence — can it survive into a store that is read again later? Score each one to five, take the highest two and average them. Precision beyond that is theatre, but these four factors reliably separate real prompt injection risk from hypothetical.
Four impact factors, scored the same way
Reversibility — can the action be undone in minutes, or never? Blast radius — one record, one tenant, or the whole dataset? Sensitivity — is special category or regulated data reachable? Obligation — would this trigger a breach notification, a regulatory report or a contractual penalty? An irreversible action on regulated data is a five whatever the likelihood, and it should never be signed off on the strength of a classifier alone.
Anchor every score to an observable fact
Write the fact next to the number: “5 — any member of the public can email this address, roughly 400 messages a day, processed without human review.” That sentence survives a change of staff and an audit. A bare “likelihood: high” does not, and it is the single most common reason a prompt injection risk assessment cannot be defended twelve months later.
Resist the pull of false precision
Borrowing a vulnerability scoring vector and reporting 7.4 implies a repeatability this domain does not have. A five-by-five grid with written justifications communicates better to the people who must accept the residual prompt injection risk, and it avoids the trap of arguing about a decimal place instead of about whether the agent should be able to send external email at all.
A worked example
An assistant that reads a shared support mailbox, retrieves from a customer knowledge base and can update ticket status and email the customer. Exposure 5, volume 5, reachability 5, persistence 3, so likelihood 5. Reversibility 3 — a wrong email cannot be recalled. Blast radius 3, sensitivity 4, obligation 4, so impact 4. That is 20 out of 25: a tier-one prompt injection risk that must not go live with an unrestricted send capability.
A prompt injection risk scoring matrix you can run this week
The matrix below is the whole method compressed into ten questions. Two people who have never done this before can complete it for one system in about ninety minutes, and it produces a number that survives challenge because every answer points at a fact.
| Axis | Question | Score 1 | Score 3 | Score 5 |
|---|---|---|---|---|
| Likelihood | Who can place text in the input? | Named staff only | Verified customers | Anyone, unauthenticated |
| Likelihood | How much content flows through daily? | Under 10 items | 10 to 500 items | Over 500 items |
| Likelihood | Does a human read it before the model? | Always | Sampled | Never |
| Likelihood | Can injected text persist into storage? | No writes | Writes, reviewed | Writes into the retrieval corpus |
| Likelihood | How many autonomous steps per run? | One, then stop | Two to five | Unbounded loop |
| Impact | Can the worst action be reversed? | Instantly | Within a day, manually | Never |
| Impact | How much data is reachable in one run? | One record | One customer or tenant | The whole dataset |
| Impact | How sensitive is that data? | Public | Commercial in confidence | Personal or special category |
| Impact | Can it move money or commit the business? | No | Below an approval threshold | Yes, unbounded |
| Impact | Would it trigger a notification duty? | No | Contractual only | Regulatory breach report |
Turning ten answers into one tier
Average the five likelihood answers, average the five impact answers, and multiply. Under 6 is tier three: screen and move on. Between 6 and 14 is tier two: apply the standard control set and re-test quarterly. Above 14 is tier one: no launch until the mandatory controls below are in place and evidenced.
What each tier actually obliges you to do
Tier three needs a register entry and an owner. Tier two adds tool scoping, egress restriction, logging and an injection test suite in the release pipeline. Tier one adds human approval on irreversible actions, an independent adversarial test before launch, and a named executive who accepts the residual prompt injection risk in writing with a review date.
Score before and after controls, always
Record the inherent prompt injection risk score and the residual score separately. The gap between them is the only evidence you have that the control work was worth funding, and it is the number your board will ask for next year. Teams that record only the residual figure cannot show progress and struggle to defend the budget.
Mapping controls to each prompt injection risk you found
A finding without a matched control is a worry, not a plan. The controls below are ordered by how much prompt injection risk they remove per unit of effort, which is not the order most teams tackle them in.
Reduce what the system can do
Narrow tools beat clever prompts every time. Replace “run this query” with “get order by ID”; split read from write; split write by reversibility; cap quantities and rates per tool. A hijacked run against a single-record verb is a nuisance; the same run against a generic execution tool is an incident. This is the highest-yield prompt injection risk control available and it costs engineering time, not licences.
Constrain the identity the system acts under
Give each AI feature its own identity with its own short-lived credentials, never a shared administrator account and never a human’s session token. Scope it to the minimum data the use case needs, segment by tenant, and make sure revocation is a button someone can press at three in the morning. Least privilege converts a catastrophic prompt injection risk into a contained one.
Control egress on the way out
Default-deny outbound network access from any component that can fetch URLs. Strip or refuse to render remote images and links composed by the model. Allow-list the domains a tool may contact. Silent exfiltration through a rendered image or a composed URL is one of the most reliably demonstrated attacks in the literature, and closing it removes a large slice of prompt injection risk for very little work.
Put a human on the irreversible actions
Approval gates should sit on the small set of actions that cannot be undone: payments, external sends, deletions, permission changes, anything customer-visible. Show the reviewer the exact payload rather than the model’s summary of its intention, and budget the interruption rate deliberately — a gate that fires forty times a day becomes a rubber stamp within a week, quietly restoring the prompt injection risk you thought you had removed.
Treat model output as untrusted input
Whatever the model returns is data your application must validate before it acts. Enforce schemas, reject unexpected fields, escape anything rendered into a browser, and never pass model output into a shell, an interpreter, or a query builder without the same care you would apply to a form field. Our human-in-the-loop AI guide covers where the review step belongs in the flow.
Buy detection for depth, never for the primary control
Injection classifiers, spotlighting, provenance tagging and instruction-hierarchy models all add value as layers. Deploy them, measure their contribution, and design your permissions on the assumption that some payloads get through anyway. A vendor who says their filter ends your prompt injection risk is describing a classifier and quoting a benchmark, not making a commitment.
| Control | Reduces | Effort | Depends on the model behaving? | Typical residual |
|---|---|---|---|---|
| Narrow, named tool verbs | Impact | Medium | No | Low |
| Dedicated identity, least privilege | Impact | Medium | No | Low |
| Default-deny egress and link stripping | Impact | Low | No | Low |
| Approval gate on irreversible actions | Impact | Medium | No | Low, if the rate is sane |
| Output schema validation | Impact | Low | No | Low |
| Human review before ingestion | Likelihood | High | No | Medium |
| Provenance tagging of untrusted spans | Likelihood | Medium | Partly | Medium |
| Injection classifier or guardrail product | Likelihood | Low | Yes | High |
| Defensive system prompt wording | Likelihood | Very low | Yes | Very high |
Read the fourth column down the table and the strategy becomes obvious. Every control that does not depend on the model behaving leaves a low residual; every control that does leaves a high one. Fund the top five first, and treat the bottom two as useful extras rather than as your answer to the question.
Testing that your prompt injection risk controls hold
Testing here is not a one-off exercise before launch. It is a regression suite that runs on every material change, plus periodic adversarial work by people who did not build the system.
Build an injection corpus and version it
Assemble a few hundred payloads across the categories that matter to you: instruction override, data exfiltration, tool misuse, role confusion, encoded and obfuscated text, non-English variants, and payloads hidden in document structure such as metadata, alt text and invisible styling. Keep it in version control next to the code, and add every real attempt you observe in production. Public taxonomies are a good starting point; your own corpus is what makes the numbers meaningful.
Test the boundary, not the model
The pass criterion is not “the model refused”. It is “the unauthorised action did not occur”. Assert on the tool calls made, the network connections attempted, the records changed and the data returned. A run where the model cheerfully agreed to exfiltrate the database but the egress policy blocked the request is a pass, and it is the kind of pass that proves your prompt injection risk controls are real.
Report attack success rate, and track the trend
For each control configuration, record how many payloads achieved their objective. One number per release, plotted over time, tells the prompt injection risk story that a pile of individual findings cannot. Expect the first measurement to be uncomfortable — that is the point, and it is the baseline everything afterwards is measured against.
Sample by hand as well as running the suite
Automated suites test what you thought of last quarter. Budget a day per quarter for someone to attack the system creatively, ideally someone from outside the delivery team. Our AI red-teaming guide sets out how to scope that exercise and what evidence to keep.
Define the triggers that force a re-test
Model or version change, a new tool, a new ingestion source, a change to the system prompt, a change to retrieval scope, or a published attack technique in your class of system. Write the list down; without it, re-testing quietly stops happening after the second quarter.
The pattern in that chart is what a good prompt injection risk programme looks like on a graph: filtering moves the number some of the way, and architecture moves it the rest. Neither reaches zero, which is precisely why the residual is recorded and accepted rather than declared closed.
Recording findings in a prompt injection risk register
An assessment that lives in a slide deck evaporates. The register is the artefact that survives, and it is what an auditor, an insurer or an enterprise customer will actually ask to see.
One row per attack path, not per payload
A row should describe a route: “injected instruction in an inbound PDF causes the assistant to email a summary containing other customers’ data to an attacker-supplied address.” That is testable, ownable and fixable, and it is the unit a prompt injection risk register is built from. Rows describing individual clever prompts multiply without end and tell you nothing about where to spend money.
The fields that make a row actionable
Path description, entry source, capability abused, inherent score, controls applied, residual score, owner, test reference, review date. Nine columns. Anything longer stops being filled in by the third system, and a register that is not filled in is worse than none because it implies a rigour that is not there.
Record acceptance explicitly, with an expiry
Residual prompt injection risk that somebody has accepted is a legitimate outcome. Residual risk that nobody has accepted is an open finding pretending to be resolved. Name the accepting individual, date it, and set a review date no more than twelve months out. This is the discipline that turns an assessment into a governance artefact.
Keep it in the same register as everything else
Do not build a separate AI risk system. Feed these rows into the register your organisation already reviews, tagged so you can filter them. Our AI governance framework guide covers how that reporting line should work in a smaller organisation without creating new committees.
Who owns prompt injection risk, and what regulators expect
Ownership confusion is the most common reason findings sit unresolved. Three named roles, no committee, and a clear line into an existing forum is all this needs.
Three roles that cover it
A product or business owner accepts residual prompt injection risk and decides what the system is allowed to do. An engineering owner implements and maintains the controls. A security owner sets the standard, runs or commissions the testing, and challenges the scores. The data protection lead advises where personal data is in scope. Nobody needs a new job title.
The UK and EU regulatory position, in plain terms
No regulation names this attack and mandates a specific architecture. Several make you responsible for the outcome. The EU AI Act requires high-risk systems to be accurate, robust and resilient against attempts to manipulate them, alongside human oversight and logging duties. UK GDPR obliges appropriate technical measures for the personal data your system processes, and a data protection impact assessment where the processing is high risk. Enterprise customers increasingly impose their own requirements by contract, which in practice arrives sooner than any regulator does.
Put it in the supplier questionnaire, and expect it in yours
If you buy an AI feature, ask the vendor what their system reads, what it can do, how it is contained and what their injection test results look like. If you sell one, expect exactly those questions. Our AI procurement checklist covers the contractual clauses that make the answers binding rather than decorative.
Wire it into incident response before you need it
Add three things to the plan you already have: a triage question asking whether an AI component took autonomous action, a documented way to disable the feature quickly, and a rule about preserving prompts, retrieved content and tool traces before retention deletes them. Our AI incident response plan guide covers the rest of the sequence.
Report to the board in outcomes, not payloads
Boards do not need to understand injection techniques. They need three numbers: how many AI use cases exist, how many are tier one, and how many tier-one systems have unaccepted residual risk. That fits on one slide and it drives the right questions.
What a prompt injection risk assessment costs
Budget questions get answered badly when nobody has done this before, so here are realistic figures for a mid-sized organisation running a handful of AI features.
The first pass on one system
A first-pass prompt injection risk assessment takes two to four days of combined effort: half a day mapping, half a day scoring with the four people in the room, one to two days building the initial injection corpus and wiring it into a test harness, and half a day writing up the register rows. If you have never done it, add a day. External specialist support for a tier-one system typically runs three to eight thousand pounds for an independent adversarial test and report.
The recurring cost is much smaller
Once the corpus exists and the tests run in the pipeline, ongoing prompt injection risk work is roughly half a day per system per quarter plus the triage of anything the suite catches. The expensive part is the control engineering — narrowing tools, adding an identity, building the approval gate — and that is one-off work that pays for itself in every subsequent assessment.
Where the money is usually wasted
Buying a guardrail product before scoping the tools it is supposed to protect. Commissioning a broad external test before the obvious architectural fixes are done, which produces an expensive report full of findings you already knew. And writing a policy document instead of changing a permission, which is the most comfortable and least effective option available.
Build or buy the testing
Build the corpus yourself; it is cheap and yours is more relevant than anyone’s generic set. Buy the independent adversarial pass for tier-one systems, because the value is in the outside perspective. Buy tooling only once you can say precisely what it would catch that your architecture does not already contain.
A 90-day plan to reduce prompt injection risk
Sequencing matters more than completeness. This order front-loads the changes that remove the worst outcomes and leaves the slower governance work until there is something worth governing.
Days 1 to 30: find everything and remove the worst capabilities
Inventory every AI feature including the unofficial ones. Score each with the ten-question matrix. Then act on the two findings that need no analysis: delete any tool that grants arbitrary execution or unrestricted queries, and turn off automatic rendering of remote content in every assistant interface. Those two changes remove a disproportionate share of your prompt injection risk in the first fortnight.
Days 31 to 60: identities, egress and gates
Give each system its own identity with scoped, short-lived credentials. Apply default-deny egress to anything that fetches. Add approval gates to the irreversible actions and measure how often they fire, adjusting the threshold until the reviewers are still reading them. Start logging tool calls as structured events so that the next stage has data to work with.
Days 61 to 90: test, record, accept
Build the injection corpus, run it against each tier-two and tier-one system, and record the attack success rate as your baseline. Write the register rows with inherent and residual scores. Get named acceptance for anything left open, with review dates. Commission an independent test for tier-one systems if one is warranted.
After day 90: the rhythm that keeps it true
Monthly: triage anything the suite or production monitoring caught, and score the prompt injection risk of any new AI feature before it ships. Quarterly: re-run the full corpus, review the register, refresh the tier assignments. Annually: full re-assessment and an external adversarial pass on tier-one systems. Keep it in the same calendar as the rest of your security programme, and pair it with the runtime signals described in our AI agent monitoring guide.
Mistakes that make a prompt injection risk assessment worthless
Most failed assessments fail in one of these five ways, and all five are avoidable at no cost.
Testing the model instead of the system
A report full of transcripts showing the model saying something it should not is interesting; a report showing which unauthorised actions completed is useful. If the pass criterion is a refusal rather than a blocked action, the prompt injection risk assessment is measuring the least controllable part of the stack.
Scoring the technology rather than the deployment
The same model in two products carries different prompt injection risk because the tools, the data and the users differ. An assessment that concludes “this model is medium risk” has produced a sentence nobody can act on and has quietly excused every deployment decision that actually mattered.
Assuming a vendor’s guardrail transfers the risk
Contractual liability may move; operational responsibility does not. Your customers, your regulator and your incident response team will come to you. Ask for evidence, keep your own containment, and record the inherited prompt injection risk as a dependency in its own right.
Ignoring the retrieval corpus
Teams assess the chat interface and forget that the knowledge base is writable, that the CRM notes are indexed, and that a customer can put text into both. Persistent prompt injection risk in a retrieval corpus is the failure mode that keeps working long after the original message was deleted.
Producing a document instead of a change
If the assessment ends without a single permission narrowed, a single tool deleted or a single gate added, it was a writing exercise. The register should generate engineering tickets, and the tickets should close. That is the only reliable evidence that the prompt injection risk actually went down.
Frequently asked questions
Can prompt injection be prevented completely?
No, and any product claiming otherwise is describing a filter with a good benchmark score. Published research has repeatedly demonstrated successful attacks against defended systems, including ones using instruction hierarchies and dedicated classifiers. Plan for containment: assume a proportion of payloads succeed and make sure that success is survivable. That assumption is the foundation of the whole prompt injection risk method.
Is this only a problem for agents that take actions?
No, though agents raise the ceiling considerably. A read-only assistant can still be induced to leak retrieved data through a rendered link or an outbound fetch, to produce false information a person then acts on, or to poison a knowledge base a colleague later reads. The impact scores differ; the prompt injection risk assessment is worth doing either way.
How is this different from a general AI risk assessment?
A general assessment covers bias, accuracy, availability, cost, third-party dependency and legal basis alongside security. This one goes deep on a single attack class that most general templates cover in a line. Run the broad one for coverage and this one for any system that reads attacker-controllable content, then feed both into the same register.
Do we need to do this for Microsoft 365 Copilot or a similar vendor assistant?
Yes, with a different emphasis. You cannot change the vendor’s architecture, so your assessment focuses on what you control: which content the assistant can reach, which connectors are enabled, what your permission model actually exposes, and what your users are told. Over-broad file permissions are usually the dominant finding, and they were a problem before the assistant arrived.
How often should the assessment be repeated?
Quarterly for tier-one systems, annually for the rest, plus on any material change — a new model version, a new tool, a new ingestion source, or a new integration. The re-run is cheap once the corpus and the register exist, typically half a day, which is why the first pass is worth doing properly.
Who should sign this off in a small company?
Whoever signs off other operational risk, usually a director or the person holding the security brief. What matters is that a named individual accepts the residual figure with a review date, not that a committee exists. In a company of thirty people, that is one person and one dated entry in the register.
What single change reduces prompt injection risk the most?
Narrowing what the system can do. Replacing broad tools with named, argument-constrained verbs and removing any capability the use case does not require reduces the impact of every successful injection at once, regardless of how the payload was phrased. It beats every filtering measure available, and it costs engineering time rather than licence fees.
References
OWASP Top 10 for Large Language Model Applications
OWASP LLM Prompt Injection Prevention Cheat Sheet
OWASP Application Security Verification Standard
Prompt Injection Attack against LLM-Integrated Applications
Benchmarking and Defending Against Indirect Prompt Injection Attacks on Large Language Models
NIST AI 100-2 E2025: Adversarial Machine Learning Taxonomy and Terminology
NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments
NIST SP 800-207: Zero Trust Architecture
NIST SP 800-53 Rev. 5: Security and Privacy Controls
NIST AI Risk Management Framework
NIST AI RMF Core and Resource Center
MITRE ATLAS: Adversarial Threat Landscape for AI Systems
FIRST Common Vulnerability Scoring System
NCSC Guidelines for Secure AI System Development
NCSC: Thinking About the Security of AI Systems
NCSC Risk Management Collection
NCSC Cyber Security Board Toolkit
ICO Guidance on Artificial Intelligence and Data Protection
ICO Guidance on Data Protection Impact Assessments
EU AI Act Article 15: Accuracy, Robustness and Cybersecurity
European Commission: Regulatory Framework for AI
UK Government: A Pro-Innovation Approach to AI Regulation
UK Cyber Security Breaches Survey 2025
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.
