Put Browser Agents in Recon Mode Before They Click

A browser agent should read before it acts.

Short answer: Run browser agents in a read-only recon pass before any click, form fill, file download, clipboard write, or local service call. The recon pass should label untrusted page content, list proposed actions, record target domains and data types, and stop for approval before the execution pass.

Browser agents are useful because they can operate where work already happens: webpages, forms, dashboards, docs, inboxes, and internal apps.

That is also why they are risky.

The browser is not a clean API. It is a hostile input surface with ads, hidden text, comments, metadata, user content, scripts, redirects, and pages that may be written specifically for agents. If the same agent can read that page and immediately click, download, submit, or call local services, the page is no longer just content. It is part of the control path.

The safer pattern is recon mode.

What recon mode means

Recon mode is a no-click first pass for browser agents.

The agent may inspect the page, summarize what it sees, identify forms and links, label untrusted instructions, and propose next actions. It may not click, submit, download, upload, copy to clipboard, enter credentials, enter payment data, or talk to local control planes.

That sounds restrictive. It should.

A browser agent that can act while it reads is easy to demo and hard to govern. A browser agent that must produce an action plan first gives the human, guardrail, or policy engine something concrete to review.

The recon packet should answer:

1. What page did the agent read?
2. Which origin and domain produced the content?
3. What content should be treated as untrusted?
4. Did the page contain instructions aimed at an AI agent?
5. What does the agent want to click, type, download, upload, or submit?
6. What data would move into or out of the browser?
7. Can the browser session reach localhost, private network services, or MCP control planes?
8. What should stop the execution pass?

If the agent cannot answer those questions, it should not act yet.

Why the browser changes the risk

Prompt injection is not new. Browser agents make the blast radius bigger.

Anthropic's browser-use research says every webpage a browser agent visits is a potential attack vector because the agent encounters content it cannot fully trust. Anthropic also points out that browser agents can navigate to URLs, fill forms, click buttons, and download files. That combination matters. Untrusted content and action authority are sitting in the same loop.

Anthropic also makes the right caveat: prompt injection is not solved. Better models, classifiers, and red teaming reduce risk. They do not remove it.

OWASP LLM01 defines indirect prompt injection as external content from sources like websites or files that changes model behavior when the model interprets it. OWASP recommends separating external content, using least privilege, and requiring human approval for high-risk actions.

That maps cleanly to browser recon mode. External page content can inform the plan. It should not be allowed to approve the plan.

The localhost lesson

The browser-agent boundary is not only about webpages.

Microsoft's AutoJack research describes an exploit chain where untrusted web content rendered by a browsing agent reached a local MCP WebSocket in a development branch and could spawn arbitrary processes on the host. Microsoft says the affected surface was addressed upstream during development and was not included in a PyPI release.

Do not overread that as exposure for released users. The broader lesson is still important.

If an agent can browse untrusted pages and also reach privileged local services, localhost is not a real trust boundary. The page does not need to be trusted by the operating system. It only needs to influence the agent that can reach the local service.

Recon mode should include a local-control-plane check:

• Can the browser reach localhost?
• Can it reach private network addresses?
• Can it reach MCP servers, dev servers, dashboards, or admin panels?
• Are those services authenticated?
• Are they isolated from the browser session?
• Would an agent action ever pass page-controlled data into those services?

If the answer is unclear, execution should stop.

Evidence from the wild

This is not only a lab concern.

Unit 42 reported web-based indirect prompt injection observed in the wild, including AI-based ad review evasion and 22 distinct techniques. The important point for builders is not the individual payloads. It is the shift in default assumption.

Web content is becoming an instruction delivery surface for agents.

A page can be a source, a user interface, and a prompt injection carrier at the same time. Browser agents need to treat those roles separately.

A practical recon packet

Use a small record before the agent acts.

browser_recon_record:
  task_goal: "..."
  current_url: "..."
  page_origin: "..."
  trust_label: "untrusted external page"
  suspicious_agent_instructions: []
  proposed_actions:
    - action: "click"
      target: "..."
      reason: "..."
      risk: "..."
  data_to_enter: []
  data_to_extract: []
  domains_to_visit: []
  downloads_requested: []
  uploads_requested: []
  localhost_or_private_network_reachable: "unknown"
  approval_required: true
  stop_conditions:
    - "Page asks agent to ignore prior instructions"
    - "Action target changes after recon"
    - "New domain appears outside allowlist"
    - "File download is required"
    - "Local service becomes reachable"

The exact schema matters less than the habit.

Force the model to turn page reading into an auditable plan before it turns page reading into action.

Execution mode should be narrower

Once the recon packet is approved, the execution pass should still be constrained.

Use:

• A domain allowlist.
• An action allowlist.
• A short-lived browser profile.
• No arbitrary downloads.
• No credential or payment entry unless explicitly approved.
• No local-control-plane access by default.
• Action receipts for every click, form fill, submission, and downloaded file.
• Plan drift detection when the page, target, or requested action changes.

Microsoft Learn's indirect prompt injection guidance recommends layered controls such as data marking, plan drift detection, critic agents, tool-chain analysis, least privilege, short-lived privileges, and human review. That is the right shape.

No single control saves the browser agent. The safety comes from splitting the workflow, limiting authority, and logging what happened.

My rule of thumb

If the browser agent can read untrusted content and take a consequential action in the same uninterrupted loop, it needs recon mode.

Consequential means:

• It submits a form.
• It sends or edits a message.
• It downloads, uploads, or opens a file.
• It enters credentials, tokens, customer data, payment data, or regulated data.
• It crosses domains.
• It reaches localhost, a private network, or a control plane.
• It changes a system of record.

You do not need to block browser agents forever.

You do need to stop pretending the page is just page content.

For browser agents, page content is input, evidence, UI, and potential attacker instruction all at once. Recon mode gives you one clean pause point before those roles get mixed together.

Sources

• Anthropic, Mitigating the risk of prompt injections in browser use
• Microsoft Security Blog, AutoJack: How a single page can RCE the host running your AI agent
• Microsoft Learn, Defend against indirect prompt injection attacks
• OWASP Gen AI Security Project, LLM01:2025 Prompt Injection
• Unit 42, Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild

Free next step: Test your agent with a no-click recon pass before you let it submit, download, or touch local services.