Prompt Injection Explained: Risks and Six Practical Defenses

Prompt injection is an attempt to make an AI application follow untrusted instructions that conflict with its intended task. In a direct attack, the instruction comes from the user. In an indirect prompt injection, it is hidden in material the system reads—such as a webpage, email, document, support ticket, or retrieved database record.

The risk becomes serious when the AI can access private data or use tools to send messages, browse internal systems, modify files, run code, or approve transactions. A text-only chatbot with no sensitive context and no tools has less potential impact than an agent with broad permissions.

Direct and indirect prompt injection

Indirect injection is difficult because an LLM receives both instructions and data as language. A malicious passage can therefore look like another instruction unless the surrounding application separates trust levels and restricts what the model may do. OWASP lists prompt injection as LLM01 in its 2025 risk list.

How an indirect attack can reach an AI system

1. An attacker places instructions in content the system may retrieve: a webpage, shared file, email, issue, comment, or calendar item.
2. A user asks the AI to summarize, search, or act on that content, or an automated workflow processes it.
3. The model interprets some of the untrusted data as instructions.
4. If other controls fail, the application may produce manipulated output or request a tool action.
5. Real harm occurs only if the application has enough access and the action is not blocked or confirmed.

The visible phrase “ignore previous instructions” is only a simple illustration. An injection can be obfuscated, split across fields, concealed in markup, or phrased as an ordinary instruction. A blacklist of suspicious phrases is therefore not a complete defense.

Possible consequences

• Misleading output: the answer favors an attacker, omits important facts, or cites a planted source.
• Phishing: the response presents an untrusted login, payment, or download link as legitimate.
• Data disclosure: the system exposes information available in its current context or connected services.
• Unauthorized actions: a tool-enabled agent sends a message, changes a record, or calls an external service.
• Unsafe code or commands: generated output is passed to a shell, interpreter, browser, or downstream application without validation.

Prompt injection does not magically grant access the system never had. Its impact is bounded by the data, credentials, tools, network destinations, and approval path available to the application. That is why excessive permissions and automatic execution make the same model weakness much more dangerous.

Six ways users can reduce the risk

1. Give the AI the minimum access it needs

Do not connect an assistant to an entire mailbox, drive, repository, or administrator account when the task needs one folder or read-only access. Remove integrations that are no longer used, and prefer temporary or narrowly scoped authorization.

2. Keep sensitive data out of unnecessary contexts

Before uploading a document or pasting a conversation, remove credentials, recovery codes, private keys, personal records, and unrelated confidential material. Review the service's data controls, retention settings, and organizational policy. TipsMake's privacy-focused AI chatbot overview also explains why data handling should be part of tool selection.

3. Require confirmation for consequential actions

An AI can draft an email, file change, command, or purchase request, but a person should verify the destination, parameters, and expected effect before execution. Never approve a surprising action merely because the assistant says it is required.

4. Treat AI-provided links and instructions as untrusted

Inspect the real domain before opening a link. Navigate to important services through a saved bookmark or known address instead of an unexpected login link. Do not paste generated terminal commands into a privileged shell until you understand each operation and its target.

5. Separate untrusted content from valuable systems

Use a low-privilege account or isolated workspace when summarizing unknown files and webpages. Keep production credentials out of that environment. For autonomous tools, the same caution applies to repository instructions, issue text, and downloaded dependencies; TipsMake's OpenClaw security discussion illustrates why powerful agents need careful isolation.

6. Stop, revoke, and report abnormal behavior

If an assistant unexpectedly requests credentials, tries to contact an unfamiliar domain, changes the task, or proposes an unrelated action, stop the workflow. Revoke the integration or token if needed, preserve logs, and report the event through the provider's or organization's security channel. Updating the application is useful, but an up-to-date model is not proof that prompt injection is impossible.

Controls for developers and organizations

No single filter reliably eliminates prompt injection. OWASP's prevention guidance recommends layered controls. A practical architecture should include:

• clear separation and labeling of trusted instructions and untrusted data;
• least-privilege identities, short-lived credentials, and narrow tool scopes;
• allowlists for tools, parameters, network destinations, and data sources;
• human approval for high-impact or irreversible actions;
• validation and safe encoding of model output before another system uses it;
• limits on how much sensitive context the model can retrieve at once;
• logging, anomaly detection, rate limits, and a tested incident-response path;
• adversarial testing with direct, indirect, encoded, multilingual, and multi-step attacks.

Google describes prompt injection as a problem addressed through layered defenses, not a one-time fix. Microsoft likewise documents EchoLeak as a now-fixed cross-prompt-injection technique involving Microsoft 365 Copilot, demonstrating why vendor patches and customer-side access controls both matter.

What to remember

The safest question is not only “Can the model recognize a malicious instruction?” Ask what the system can read, what it can change, where it can send data, and which actions require confirmation. Restricting those capabilities reduces the damage even when a malicious instruction reaches the model.