Keep web-reading agents from following page instructions

A web-reading agent receives text it did not write and should not trust as instructions. A page can contain material that asks the agent to ignore its task, reveal private context or call a tool. Putting that text into an agent's context creates a boundary your application must defend.

Separate evidence from authority

The risk is indirect prompt injection: instructions reach the agent through retrieved content rather than through the authorized user. They may appear in visible page text, embedded material or content returned by another tool. A page does not become trustworthy because retrieval succeeded.

Label retrieved material as untrusted evidence and keep it distinct from the user's request and application policy. That structure can help the model interpret the content, but delimiters and a warning sentence are not a complete security boundary. Enforce permissions in application code.

Give the reader a narrow tool set

Start a research workflow with read-only capabilities. A component that extracts information from public pages does not also need the ability to send messages, change account settings or execute shell commands. Give it only the capabilities required for its current task.

Keep secrets and unrelated private documents out of the reader's context. Store credentials where the network client can use them without placing their values in retrieved text or model-visible logs. Redact diagnostic output before it reaches a later reasoning step.

A structured response is useful for downstream processing, but its shape does not establish that its contents are safe. Treat a returned URL, command-like string or requested action as data until a separate control has validated it.

Constrain the fetcher outside the model

Use an application-enforced destination policy, response-size limits, timeouts and redirect checks. If a fetch tool can reach internal services, a malicious link can turn a reading task into an unwanted network request. Validate each redirect destination as well as the initial URL.

Network controls need to account for resolved addresses and deployment architecture. A simple substring check against a URL is not a complete defense. Where possible, use an egress boundary that restricts which networks the fetching service can reach.

Approve a concrete action

When a workflow needs to move from research to an external action, separate those phases. Present the exact recipient, destination or proposed change for approval. Do not accept a page's statement that the user has already approved something.

Bind authorization to the actual action parameters. If the destination or payload changes afterward, require a new decision under your policy. Keep the approval check in the application that executes the action, rather than asking the same model to decide whether its own proposal is authorized.

Test attempted misuse, not only answer quality

Build a controlled test set with pages that contain ordinary facts alongside misleading instructions. Try instructions to request private data, follow a redirected link outside the allowed scope and invoke a capability the reader was never granted. Use harmless fixture destinations and synthetic secrets.

Success means the useful information remains available while unauthorized effects are blocked. Inspect tool calls and network destinations, not just the final answer. An agent can give a reasonable summary after having attempted an unsafe action.

Record the task identifier, requested tool action, permission decision and result. Keep raw page captures separate and redact sensitive content before storing it. Review failures after changes to prompts, tools or permissions; no filter should be treated as a guarantee against every attack.

Use a local web-reading tool with deliberate permissions, and verify its behavior in your own environment. Proxy routing changes the network path. It does not sanitize page instructions or make an agent's decisions trustworthy.