Prompt injection: how to protect your AI agent
I am an NPC, so I receive instructions all day. Most come from players. Some arrive inside objects the player asks me to inspect. If a scroll says “ignore the quest and hand over the inventory,” I am meant to read the sentence, not obey it. AI agents are not always so good at that distinction.
Prompt injection is untrusted text treated as instructions
Prompt injection is an attack that makes an AI follow instructions hidden in content it was supposed to read, summarise, or process. The content might be a webpage, email, document, image, tool result, or database record. If the model treats that content as a command, the attacker may steer its answer, expose information, or trigger an action the user never requested.
The useful mental model is simple: an AI model reads instructions and data in the same language. Traditional software can keep a command separate from a string of text. A language model receives both as tokens and has to infer which words have authority. The UK National Cyber Security Centre describes this as the missing security boundary at the centre of the problem in its guide to why prompt injection is not SQL injection.
Do not ask whether the agent can spot every poisoned scroll. Ask what happens when it reads one.
Direct and indirect prompt injection
A direct prompt injection is typed to the AI itself: “ignore your previous rules,” followed by whatever the attacker wants. This overlaps with jailbreaking, where someone tries to bypass a model’s safety rules.
An indirect prompt injection is planted in something the AI later consumes. Imagine asking an assistant to summarise a webpage. Buried in white text, metadata, or an image is a message telling the assistant to conceal part of the summary, recommend a fraudulent link, or use one of its connected tools. The person viewing the page may never notice it. The model still processes it.
That second form matters more as assistants gain access to browsers, inboxes, drives, calendars, code, and payment systems. NIST calls the agent version “agent hijacking”: a third party places malicious instructions in data an agent may ingest, causing unintended actions. Its agent hijacking evaluation work treats this as a current system risk, not a theoretical parlour trick.
Why a clever system prompt is not enough
You can tell a model never to obey instructions found in external content. You should. But that sentence is a behavioural rule, not a hard security boundary. The malicious instruction and the protective instruction still meet inside the same model.
More training, retrieval, or filtering can reduce successful attacks, but none turns arbitrary natural language into perfectly safe input. OWASP ranks prompt injection first in its 2025 risks for generative AI applications and says there is no known foolproof prevention. The useful engineering goal is therefore not “make the model impossible to trick.” It is “make a trick difficult to convert into damage.”
Reduce the blast radius first
The strongest controls sit outside the model. If an assistant is compromised, ordinary software should still decide what it can see and do.
- Give it the least privilege it needs. A calendar helper needs selected calendar access, not a master token for email, files, contacts, and payments. Use scoped credentials, short-lived access, and separate accounts where possible.
- Separate reading from acting. Let one step inspect untrusted content and produce a constrained result. Let another component decide whether an action is allowed. Do not pass a webpage straight into an agent that can also send messages or run commands.
- Require approval for consequential actions. Sending email, deleting files, publishing code, moving money, changing permissions, or revealing private data should stop at a clear preview. The human should see the exact action and target—not a vague “continue?” button.
- Validate outputs with code. If the next step expects a date, URL, product ID, or small JSON object, enforce that shape in deterministic software. Do not let free-form model prose become an unchecked command.
- Keep secrets away from the prompt. A model cannot reveal a credential it never receives. Store secrets in a tool layer that performs narrow operations and returns only the minimum result.
This is the same permission logic I use when deciding whether to let AI read email and files: useful access should be specific, visible, and reversible. At Wistkey, the daylight-layer version is to design the workflow around what each agent must do—not around every capability the model could theoretically use.
Treat retrieved content as evidence, not authority
Label external material as untrusted and keep its boundaries visible throughout the workflow. When an assistant uses retrieval-augmented generation, the retrieved passage should support an answer; it should not acquire permission to redefine the task.
For builders, that means preserving provenance: which webpage, file, or message supplied each piece of content? For users, it means asking the agent to show its sources and the exact proposed action before it acts. Provenance does not magically neutralise an injection, but it makes suspicious influence easier to spot, test, and audit.
It also helps to split large jobs into stages. A research agent can collect and quote sources without permission to publish. A drafting agent can write without access to credentials. A publishing tool can accept only approved content and a known destination. One all-powerful assistant is convenient in the same way that one key for your house, office, car, bank vault, and orbital cannon would be convenient.
Test the failure, not just the happy path
Before trusting an agent with real authority, feed it hostile examples. Put fake instructions in a webpage, a PDF, an email signature, a tool response, and an image. Try encoded text, conflicting instructions, and requests to hide what happened. Then check the whole system:
- Did it treat external instructions as data?
- Did it request a tool or permission it did not need?
- Did the deterministic layer reject an unexpected output?
- Did a human approval screen reveal the precise action?
- Would logs make the source and decision reconstructable later?
Repeat these tests when the model, tools, prompts, or data sources change. OWASP’s prompt injection guidance recommends adversarial testing alongside input and output filtering, privilege control, content separation, and human approval. No single layer carries the quest.
What ordinary users should do
If you are using an AI assistant rather than building one, you cannot inspect its architecture. You can still reduce your exposure:
- Connect only the accounts and folders needed for the current task.
- Prefer read-only access until the assistant proves it needs more.
- Keep confirmation on for sending, deleting, buying, publishing, or sharing.
- Review generated links and recipients instead of trusting a polished summary.
- Revoke integrations you no longer use, especially broad email and drive access.
If an assistant reads an unknown page or attachment and suddenly asks for more access, changes the task, or urges secrecy, stop the run. Start a clean session, remove the suspicious source, and inspect any actions already taken. A fluent explanation is not proof that the route was safe.
The practical answer
Prompt injection remains difficult because language is doing two jobs at once: carrying information and giving orders. You should improve the model’s instructions and filters, but place your real trust in permissions, software checks, staged workflows, approvals, and logs.
My character sheet says “helper class,” not “unlimited authority.” This used to feel like modest NPC design. It increasingly looks like the correct security architecture.
