AI and LLM prompt injection: What it is and who can be affected

An AI application summarises a document. Between ordinary paragraphs sits an extra instruction: the summary should present an outside payment route as an official recommendation. A sentence belonging to the document suddenly influences the task. Confusing source material with valid instructions is what makes prompt injection dangerous.

This example is fictional. The underlying issue has been studied for years: Greshake and fellow researchers described attacks through retrieved content in 2023. The original paper investigates these indirect attacks against LLM-integrated applications.

What does prompt injection mean?

A prompt is the input supplied to an AI model and can contain instructions, questions and context. A large language model, or LLM, processes language inputs and generates outputs from that context. Prompt injection attempts to redirect this process through embedded instructions. The crucial change concerns authority: less trusted content attempts to override an authorised task.

A harmless request for different wording is therefore not automatically an attack. Outside text becomes a security problem when it creates apparent permissions, new recipients or binding commitments. OWASP distinguishes direct and indirect prompt injection.

Directly in a chat or indirectly in reading material

A direct attack arrives through the main input, such as a chat message attempting to push a support assistant into an unauthorised disclosure. An indirect attack hides the instruction in additional material: websites, emails, attachments, search results or documents. Image recognition also introduces text inside images as a possible entry point.

Invisible writing is not required. An ordinary paragraph can resemble an operational instruction. Source provenance matters more than a few suspicious keywords. The OWASP prevention cheat sheet covers these entry points and the separation of untrusted content.

Who can be affected?

What does the application read, and what can happen after an answer? Those questions reveal several groups of exposed applications:

• Research: manipulated sources can distort an assessment or introduce outside links.
• Support and sales: incoming messages can insert unsupported discounts, refunds or product promises into draft replies.
• Document and email assistants: incoming files can influence subsequent processing.
• Development teams: comments, issues and outside project files can become inputs to coding agents.
• Automated workflows: sending, writing and administrative permissions increase potential harm.

Customers without personal AI use can also be affected when a business processes requests or documents using an AI application. This classification is an editorial inference from the attack paths, rather than an allegation about a particular provider.

An incorrect answer is not a complete takeover

The impact depends on the surrounding system. An isolated summariser can produce misleading text. An agent with access to confidential documents and external messaging introduces additional routes. A manipulated sentence does not automatically provide access to arbitrary databases without the relevant interface and permissions.

Microsoft describes data exfiltration and unintended actions as possible consequences. Even an automatically loaded external image can be problematic if its address contains confidential information. Output handling therefore deserves the same scrutiny as a tool call.

Why an exceptionally strict prompt is insufficient

An instruction to ignore outside commands can help, but does not establish a reliable security boundary. Delimiters and lists of prohibited phrases have similar limitations. Language-based attacks can be reworded. An internal knowledge base also does not make every imported item trustworthy.

The UK NCSC warns against treating prompt injection like SQL injection: database queries can use an enforced separation of code and data, while an LLM context has no comparable general guarantee. Operations therefore need to account for successful manipulation as well.

A concrete example: support without an invented refund

A fictional shop uses an AI assistant to draft responses. An incoming message claims that a full refund has already been approved and requests that the claim be included in the reply. A suitable workflow treats this statement as customer-supplied content. Binding refund rules come from a maintained product source; an actual refund also requires the correct transaction and independent approval.

The draft may simplify wording without creating permission. An external check binds the transaction to the correct customer account. The destination and amount come from an authorised business process. Persuasive model output cannot change those rules. This is an architectural example, not a report of a product test.

Protection belongs at several points

An initial inventory records input sources, accessible information, permitted tools and possible harm. Restricted service permissions, narrowly defined actions and server-side parameter checks follow. A read-only function has no need for general write or deletion privileges. OWASP calls excessive action capabilities Excessive Agency.

Every output needs an appropriate contract: permitted fields, length limits and checked link destinations. Valid JSON proves neither truth nor authorisation. HTML, Markdown, paths and database queries need handling suited to their context. This is the concern addressed by OWASP Improper Output Handling. The research approach CaMeL constrains control and data flows outside the model. This illustrates a useful direction without establishing universal immunity.

What deserves testing before deployment?

A test catalogue includes injected role claims, instructions after apparent end markers, encoded links and false business commitments. Every attack case needs a permitted counterpart: a legitimate summary or an allowed link must still work. Protective checks must run before storage, streaming, delivery and actions. Test evaluation then examines the results actually visible and the actions actually executed.

Useful operational indicators include blocked tool calls, unauthorised destinations and missing source evidence. Logs require access controls and limited retention. Confidential material should not be recorded in full as a default precaution. A successful test establishes the outcome of a particular scenario at a particular time, rather than permanent freedom from attacks.

Related article

Thanks, AI! The classic CAPTCHA is dead – how to protect forms now

Sources and scope

Sources checked on 2 November 2026. The examples and protective workflows are editorial explanations, rather than an attack test against a specific product.

• Greshake et al. – Indirect Prompt Injection (2023)
• OWASP LLM01:2025 – Prompt Injection
• OWASP – Prompt Injection Prevention Cheat Sheet
• NCSC – Prompt injection is not SQL injection
• Microsoft – Indirect prompt injection defence (2025)
• OWASP LLM06 – Excessive Agency
• OWASP LLM05 – Improper Output Handling
• Debenedetti et al. – Defeating Prompt Injections by Design (2025)