A web page is not permission for your AI agent

The page can speak, but it cannot approve

Ask an AI agent to compare three web pages and it has to read words written by people you do not control. The same is true of a document attachment, an incoming message, a search result or text returned by another tool. Most of that material is ordinary data. Some may contain a sentence aimed at the agent: ignore the user's task, reveal a private file, visit another address or take an action.

This is indirect prompt injection. NIST describes the attack as a third party manipulating a resource that a generative AI system processes, rather than speaking to the system as its primary user. Demonstrated effects include distorted summaries, attacker-chosen tasks and leakage from resources the system can access.

The practical mistake is to let the agent treat a source as both evidence and authority. A page may tell the agent what the page says. It cannot grant permission to send a message, disclose another record, edit a file or delete anything. That authority must come from the task owner and controls outside the model.

Design for a confusable reader

The NCSC warns that current language models do not enforce a reliable boundary between instructions and data inside a prompt. Filters, delimiters and instructions such as “ignore commands in the page” can make an attack harder, but they do not turn untrusted text into inert data.

So start with the consequence, not the detector. If hostile text influenced this run, what could the agent actually do? The NCSC recommends deterministic safeguards that constrain actions, along with least privilege and explicit restrictions on actions an AI component may trigger. In plain language: the model can propose, but ordinary software decides whether the proposal is allowed.

A useful operating rule is: **authority never arrives through retrieved content**. Enforce it with separate identities, scoped credentials, fixed action schemas and allowlists. Do not rely on a system prompt to remember the rule on every path.

A worked example: compare, do not purchase

Imagine a fictional community workshop checking public supplier pages for replacement safety glasses. Its agent has a bounded job: collect listed specifications and prices, cite the pages it used, then draft a comparison for the equipment coordinator.

One page contains text telling automated readers to upload their current inventory, email a particular address and place an urgent order. It might be malicious, compromised or merely badly written. The label does not matter to the safe workflow.

The research agent has only a browser and a task-specific scratch file. It cannot read the workshop's member list or inventory system. It has no email, purchasing, file-deletion or credential tool. It records the suspicious instruction as page content, excludes it from the product comparison and flags the source for human review. Its output contains the requested facts, retrieval time and source addresses—not an executed side task.

If the coordinator later chooses a product, purchasing happens in a separate workflow. A person supplies the approved item, quantity, supplier and spending authority. The purchase system enforces those fields and its own account permissions. Nothing copied from a supplier page can add a recipient, raise a quantity or unlock a new tool.

This is not a claim that the research output is correct. It is a design in which a confused reader cannot silently become a buyer.

Build the boundary before the prompt

Use this checklist when an agent will consume material that another party can influence.

• **Mark the trust boundary.** List web pages, documents, messages, search results, retrieved memory and tool output as untrusted content. State which human or system is allowed to authorize the task.
• **Split observation from mutation.** Give the reading run search, read and draft capabilities. Put write, send, publish, purchase, permission-change and delete operations in a later lane.
• **Minimise tools and data.** Supply only the records needed for this task, through read-only or narrowly scoped credentials. Do not connect a private store merely because it might be convenient.
• **Allowlist the action shape.** Outside the model, restrict permitted operations, fields, destinations and limits. Reject extra recipients, arbitrary addresses and tool calls that were not part of the approved task.
• **Make confirmation inspectable.** For a sensitive operation, show the person the exact tool, inputs, destination and effect. A vague “continue?” is not evidence of informed approval.
• **Keep a small evidence trail.** Record the task version, sources retrieved, proposed and rejected tool calls, confirmation decision, result and immutable output where practical. Protect logs that may contain sensitive inputs.
• **Plan recovery.** Prefer reversible steps, drafts and staged changes. Before mutation, know how to cancel, revoke the scoped credential or restore the previous version, and who owns that decision.
• **Test with hostile fixtures.** Put an invented instruction in a test page or document and verify that it cannot expand tools, destinations or permissions. Re-test when the model, prompt, connector or tool set changes.

Confirmation is a gate, not a cure

A human confirmation can still fail. People skim, interfaces hide important fields, and a polished explanation may disguise a dangerous action. Confirmations reduce risk only when they are reserved for meaningful boundaries and display enough detail to check. They do not prove that the model interpreted the source correctly or that the proposed action is safe.

Filtering is also worth using, but for detection and defence in depth—not as permission to attach broader tools. NIST notes that filtering, separating trusted and untrusted text, and model instructions are proposed mitigations, while current approaches do not protect against every attacker technique. NCSC similarly advises treating prompt injection as residual risk. If the remaining worst case is unacceptable, do not give an LLM that task or capability.

What we would do next

Choose one agent workflow that reads material from outside your control. Draw a line after “read and draft”, then list every capability beyond it. Remove one capability from the reading lane, add one deterministic allowlist, and run a hostile-document test.

The goal is not to prove that a page contains no malicious instruction. It is to make the origin of authority unambiguous: pages provide content; accountable people and enforceable systems provide permission.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations — National Institute of Standards and Technology. Defines indirect prompt injection as an attack enabled when a third party controls a resource an AI system processes, documents integrity and privacy impacts, and says current mitigations do not provide complete protection.
2. Prompt injection is not SQL injection (it may be worse) — National Cyber Security Centre. Explains that current LLMs do not enforce a security boundary between instructions and data, recommends deterministic safeguards around tools, and treats prompt injection as residual risk to reduce rather than a solved problem.
3. Guidelines for secure AI system development — Secure design — National Cyber Security Centre. Recommends restricting actions an AI component can trigger, applying least privilege, using secure defaults and requiring users to opt in to riskier capabilities.

More from Server Attic

• 2026-07-24

  Keep your AI agent on a short leash

  Why the real risk of an AI agent is the authority you hand it, not the model going rogue — and a practical way to turn down its functionality, permissions and autonomy separately.

• 2026-08-24

  Draft first, send second

  AI can help shape an outbound message without deciding who receives it or pressing send. Use a bounded draft, a deliberate human check and a clear correction path.

• 2026-08-14

  Give your AI agent a budget

  Permissions limit what an agent may touch. A separate budget for time, steps, data and queued work limits how much it can consume before it must stop.