Illustrative source-code photograph, not an attack example. Photo: Ilya Pavlov / Unsplash.
Prompt injection happens when input steers an AI away from its intended task or rules. One important version hides instructions inside material the assistant is supposed to read, such as a webpage, document, or email. The problem starts when the AI treats that material as authority instead of information.
You can ask a perfectly reasonable question and still encounter this risk. If an assistant retrieves outside content to answer you, someone other than you may have influenced what it reads.
A simple example: a review that tries to give orders
Imagine asking an assistant to compare three laptops using online reviews. One page contains instructions telling automated assistants to recommend its product regardless of the evidence. If the assistant follows those directions, the page has interfered with your request.
That’s a hypothetical example, not a report about a particular retailer. It shows why the issue isn’t limited to spectacular hacks. An attack can try to bias a recommendation or suppress an inconvenient detail without ever asking the AI to run code.
The OWASP explanation of prompt injection distinguishes direct injections, which arrive through user input, from indirect injections in external sources such as files and websites. The latter is especially relevant when an assistant browses or searches a document collection.
How is it different from a hallucination?
A hallucination is an inaccurate or unsupported output. Prompt injection describes a way that input can redirect the system. They can overlap, but they aren’t the same thing.
If an assistant invents a laptop’s battery-life result because it lacks reliable information, that’s an accuracy problem. If a page tells it to ignore unfavorable results and it obeys, that’s an instruction-handling problem. The final recommendation could be misleading in either case, but the cause differs.
Similarly, not every strange answer proves an attack. A confusing document, a poor search result, or a normal model error can also produce bad output. Investigate the source and the actions taken before assuming a security incident.
Why connected tools raise the stakes
A text-only assistant might produce a manipulated answer. An assistant with additional tools may also be able to edit documents, send messages, or interact with other services. The possible consequences depend on the permissions actually available to it.
Our earlier coverage of Claude’s computer-use feature shows the broader shift from generating text to operating software. That added usefulness is exactly why access controls matter. Reading a page should not automatically give that page authority over everything an assistant can reach.
Running a model locally does not settle this question by itself. A local assistant can still process untrusted documents. Where computation happens and which inputs receive authority are separate issues.
What actually reduces the risk?
OWASP recommends several layers, including limited privileges, separation of external content, output validation, and human approval for higher-risk operations. It does not offer a universal prompt that makes the problem disappear.
For everyday use, keep the permissions proportional to the task:
- Prefer read-only access when reading is enough. Summarizing a folder doesn’t require deleting its contents.
- Share a working subset. A few relevant files are easier to oversee than an entire archive of private material.
- Review consequential actions. Check recipients, attachments, destinations, and changes before approving them.
- Check important claims against their sources. A fluent answer and a source link are starting points, not proof that the conclusion is faithful.
- Know how to disconnect the tool. Stop an unexpected workflow before granting it broader access.
A reminder in your prompt can help communicate your intentions, but it isn’t equivalent to a restriction enforced by the application. Where settings allow it, remove unnecessary capabilities instead of relying exclusively on instructions not to use them.
What should you do if an assistant changes direction?
Pause if a summarization suddenly requests permission to send files, access an unrelated account, or perform an action you didn’t ask for. Review the request itself rather than accepting the assistant’s explanation automatically.
If nothing has been executed, rejecting the action may be enough to prevent that particular consequence. If an action already occurred, check the service’s activity history and revoke unnecessary access while investigating. An odd response alone does not mean your account has been compromised.
The practical goal isn’t to distrust every document. It’s to preserve a simple rule: material an assistant reads can inform its work, but shouldn’t get to redefine what you authorized it to do.