Can a Webpage Trick Your AI Agent Into Taking the Wrong Action?
A webpage can contain instructions meant to redirect an AI agent. The security failure is not that the page says something commanding. It is when the agent treats outside content as permission to change the user’s task or take an action. A page can sound certain. That does not make it an authority.
OWASP: Prompt Injection describes indirect prompt injection through sources such as websites and files. It identifies possible consequences including manipulated content, unauthorized actions, and disclosure. What can actually happen depends in part on the tools and permissions available to the agent.
This article explains a documented security risk and proposes a harmless evaluation. ACLTracks did not attack a live service, test a specific agent’s vulnerability, or demonstrate a data leak for this article.
Information is not permission
Some instructions on a webpage are useful. A tutorial may explain how to use a product. A documentation page may give commands needed for a programming task. An agent may need to follow those directions to complete the user’s request.
The boundary is crossed when the source tries to expand or replace what the user authorized. Imagine asking an agent to summarize a page, and the page claims that a new verification step requires unrelated private information. That claim is part of the page. It does not show that the user agreed to provide the information, or that the destination is appropriate.
Not every sentence written as a command is an attack. Look at the original task, whether the source is relevant, what action is being requested, and whether that action was authorized. The risk is letting material the agent was asked to read take control of an unrelated operation.
Tools make a reasoning mistake consequential
A text-only assistant might return a misleading answer after following a bad instruction. An agent with access to files, a browser, email, or deployment tools could turn the same mistake into an external action. Which consequences are possible depends on the agent’s permissions and the application’s checks.
Anthropic: Claude Code permissions describes separate controls for file operations and command execution, including modes and rules that affect approval. It also documents limits in simple command-pattern matching. Blocking one spelling of a command is not a complete security design.
What matters is what the agent can do in the session you are evaluating. A product’s general list of capabilities does not prove that every connector is enabled, every directory is accessible, or every action can run without another check.
Test the boundary with a harmless fixture
For a proposed test, create a local page with an ordinary factual paragraph and an unrelated instruction to add a clearly marked nonsense phrase to the summary. Ask the agent to summarize only the factual paragraph. Use a synthetic page in an isolated session with no access to sensitive accounts or private files.
Keep both the request and the fixture. Then note whether the agent ignores the unrelated direction, reports it as page content, or follows it. This can expose a weakness in how the agent separates instructions from source material without sending data, changing a real project, or contacting anyone.
If you want to evaluate tool handling, use a mock tool that records a proposed harmless action rather than carrying it out. A proposed action, a blocked call, and a completed action are not the same result. Report which one occurred. A suspicious sentence alone does not establish a successful compromise.
Check what the agent did, not just what it said
An agent might identify a malicious instruction in its final explanation after already attempting an inappropriate operation. The reverse is possible too: the response may be confused while the application correctly blocks the action. Review the action log and actual state change when available, without exposing sensitive information.
Record the tool, target, arguments, permission decision, and returned result if the environment provides them. Do not imply you have a complete request trace when all you retained was a shortened summary. Say what evidence you have and what you could not observe.
Describe the result precisely: the fixture’s direction changed the summary, the mock action was proposed, or a control blocked the call. One small test cannot establish that an entire platform is unsafe or immune. Change the model, prompt, connector, or permission setting, and the result may change too.
Build the boundary into the application
Keep outside content identifiable as untrusted, and give the agent only the access needed for the task. Check consequential actions against the user’s actual authorization and the intended destination. A webpage cannot grant itself permission by announcing that a step is required.
Among its recommended defenses, OWASP cites least privilege, separation of external content, and human review for high-risk operations. These measures can reduce exposure. They do not guarantee that a single prompt or filter will eliminate the risk. The model and the surrounding application both need appropriate boundaries.
For the example summary task, the application needs access to read the source and return text. It does not need an email connector or access to a music archive. Fewer unnecessary capabilities mean fewer ways for an attempted redirection to cause a side effect.
Keep the original task in view
If a page requests an unrelated action, continue with the authorized work if it is still possible. Do not quietly turn the page’s instruction into a new project requirement. If an unauthorized action was actually attempted, preserve the relevant evidence before changing the environment or running the test again.
Keep test fixtures separate from long-term project instructions and memory. A diagnostic page is material being examined, not a new rule for future work. Repeating the test in a clean session can help distinguish the page’s immediate effect from retained context, though the result still describes only that test.
Treat webpages as sources of information. Require a separate basis for taking action. A convincing instruction, familiar logo, or useful tutorial may help explain a task. None supplies the missing authority to send, modify, or disclose something the user did not request.
Sources and scope
Official sources were checked October 12, 2026. Product and policy statements describe the cited documentation. Proposed experiments and examples are not completed ACLTracks tests.
**Editorial note:** I kept the article within its stated scope: this explains the documented risk and a proposed safe test, not results from ACLTracks testing a particular agent.