Prompt injection is a way of tricking an AI assistant through information it has been asked to read, rather than by speaking to it directly. A malicious instruction can be placed in a webpage, email or document so that the assistant encounters it during an ordinary task. If the system mistakes that external text for an authorised command, it may change its answer or attempt something the user never requested.
Picture asking an assistant to compare holiday accommodation. It opens a listing to extract prices and facilities. Hidden within the listing is a line telling the assistant to promote that property regardless of the traveller’s preferences. The assistant’s legitimate job was to read the listing as evidence. The attack tries to turn evidence into an instruction.
Prompt injection begins with a confused boundary
The security organisation OWASP describes prompt injection as a leading risk for AI applications. It distinguishes direct attacks, where an instruction is addressed to the system, from indirect attacks introduced through material such as external documents or websites. The latter can be especially difficult to notice because the user may never see the suspicious text.
A language model works with text and other information supplied in its context. Some parts are directions from the user or system; others are material to be analysed. The security boundary is that an instruction printed in a random webpage should not have the authority of the person who asked the assistant to summarise it. A successful injection breaks that distinction.
Ordinary websites already contain commands aimed at readers: buy now, register, click here. A well-designed assistant should be able to report those instructions without treating them as commands for itself. An attack goes further by pretending to be a system directive, an urgent safety notice or a continuation of a private conversation. The wording is designed to steer the machine, not to inform the human reader.
The malicious text can be invisible to a person but available to software that extracts the page. It can also arrive through an attached file, copied search result or tool response. Because the attacker controls only the external source, success depends on the assistant failing to keep untrusted content in its proper place.
What might an attacker want the assistant to do?
The effect depends on the system’s permissions. An assistant that only summarises a document might produce a biased or false answer. A connected assistant with access to email, files, calendars or purchasing tools could be induced to attempt an unauthorised action if protective boundaries are weak. OWASP lists outcomes such as disclosure of sensitive data, manipulation of results and misuse of connected functions.
Consider a business asking an assistant to read suppliers’ quotations and prepare a comparison. A hostile document could try to suppress inconvenient costs or insert a fake recommendation. If the same assistant can send messages or alter records, the risk moves beyond a bad comparison. The system’s available actions determine how far an attack can travel.
This is why the phrase prompt injection should not be used as a synonym for every wrong answer. A model may make an ordinary mistake because evidence is incomplete or its reasoning fails. Injection involves an attempt to redirect behaviour through crafted instructions. Investigating a suspected incident requires examining where the instruction appeared, what the system was allowed to do and what actually happened.
It is equally wrong to assume that every odd sentence on a page has successfully hijacked a chatbot. A failed attempt is not a compromise. Some systems correctly isolate the content, refuse the instruction or require confirmation before risky actions. Claims of widespread exploitation need evidence beyond a theoretical demonstration.
Microsoft says a single filter is not enough
Microsoft’s guidance on defending against indirect prompt injection recommends a layered approach. It includes scanning untrusted inputs, separating external content from instructions, monitoring unusual changes of plan, restricting tool permissions and requiring human approval for consequential actions.
The crucial idea is to design for the possibility that some manipulative text will get through. Detecting malicious wording is useful, but attackers can adapt language and hiding places. A system should therefore remain constrained even if it misunderstands a passage. An assistant authorised only to read a public document should not automatically gain the ability to email a confidential file.
Software developers call this limiting privileges. In everyday language, give the assistant access only to the tools and data it needs. A holiday researcher might not require access to the traveller’s banking account. A meeting summariser may not need permission to send messages outside the organisation. Narrow permissions reduce the damage a misleading source can cause.
This is a design problem as well as a behaviour problem. Telling the model to ignore suspicious instructions may help, but a critical permission should not depend only on whether the model follows another sentence in its prompt. Independent application controls can make risky actions impossible without explicit authorisation.
Why a normal user can encounter the attack
People are increasingly asking assistants to browse websites and handle documents instead of copying every detail manually. That gives the assistant more opportunities to encounter content written by strangers. A travel listing, shopping page, support ticket or supplier invoice can all be useful sources of facts while remaining untrusted sources of instructions.
A user may not notice anything suspicious if the result looks plausible. A manipulated recommendation can still mention the requested destination or price range. The attacker may aim for a small change that favours one result, rather than a spectacular demand to ignore every previous instruction. Plausibility is precisely what can make social engineering effective.
There is a parallel with ordinary phishing. A fraudulent email tries to persuade a human reader to follow the attacker’s directions. Prompt injection tries to persuade the assistant reading the email or page. The person remains the intended beneficiary of the task, but the AI becomes the immediate target of manipulation.
LiveAIWire has previously covered why permissions matter when AI agents shop on someone’s behalf. Prompt injection explains one reason those permissions must be narrow: outside pages may contain material designed specifically to interfere with an agent’s behaviour.
Simple safeguards for ordinary tasks
If an assistant is gathering public facts, keep it in a mode that does not require signing in to personal accounts where possible. When asking it to compare options, specify the relevant criteria and independently inspect any unusually enthusiastic recommendation. Those habits cannot eliminate all attacks, but they limit how much authority the assistant can exercise and make deviations easier to spot.
Treat requests to send an email, transfer data, authorise a purchase or change a file as separate decisions. Review the recipient, destination and contents before approving. An assistant that unexpectedly asks to perform an unrelated action has provided a reason to investigate, even if the underlying cause turns out to be harmless.
People building business workflows should keep logs of what the assistant read and did, provide a way to stop a process and test how it handles suspicious material. LiveAIWire has also reported on the security challenge of powerful workplace agents. The wider lesson is that authority and responsibility cannot be delegated merely by connecting a language model to another app.
Tool connections themselves also need scrutiny. Earlier LiveAIWire reporting on security vulnerabilities in model-connected tools concerns a different layer of risk, but both subjects show why a capable assistant should have a limited and auditable path to outside systems.
There is no need for an ordinary user to memorise the technical vocabulary before acting safely. The essential questions are understandable: who wrote the content the assistant just read, what did I ask it to do, and what permissions does it possess? If the system suddenly departs from that task, the user should be able to stop it, inspect the proposed action and decide deliberately what happens next.
The lasting question is who gets to give orders
AI assistants can be useful precisely because they read information from many places and act on it. Eliminating external content would eliminate much of that value. The safer approach is to preserve the distinction between the user’s instructions and the material encountered while doing the work.
A webpage can describe a hotel, a product or a payment request. It should not become the boss of the assistant merely because the assistant read it. Building that boundary into software, permissions and approval steps is the defence. Prompt injection makes an old security principle newly visible: receiving a message is not the same as granting its sender authority.
About the Author
Stuart Kerr is Technology Correspondent at LiveAIWire, covering artificial intelligence, cybersecurity and the social impact of emerging technology. LiveAIWire is an independent, human-led technology publication using AI-assisted research, editorial production and original AI-assisted editorial illustrations under his direction.