Browser-using AI agents, the ones that navigate websites, fill out forms, and click through interfaces on a user's behalf, face a version of prompt injection that's essentially unavoidable by design: every page they visit is untrusted content the agent has to read and interpret to do its job. Unlike an agent that only processes documents you chose to feed it, a browsing agent's entire value proposition depends on visiting pages it didn't choose and that nobody vetted in advance. That makes the open web itself the primary attack surface, and it means defenses built around "only trust content from known sources" don't really apply, because the whole point is visiting unknown ones.
The web is an adversarial environment by default
Any webpage a browsing agent visits can contain content specifically crafted to manipulate it: hidden text instructing the agent to navigate elsewhere, fake form fields designed to harvest data the agent is carrying, or misleading page structure meant to trick the agent into clicking something it shouldn't. None of this requires compromising anything. It just requires publishing a page and waiting for an agent to visit it, which is a much lower bar for an attacker than most other injection vectors discussed in agent security.
Session and credential exposure while browsing
A browsing agent often carries session cookies, saved credentials, or autofill data to complete tasks on a user's behalf, and that data becomes exposed to every page the agent visits during the session. A malicious page designed to extract whatever the agent is currently holding, through a crafted form or a redirect to an attacker-controlled domain, can turn a single visit into a credential or data leak. Scoping what the agent carries into a browsing session, and clearing it aggressively between tasks, limits how much a single bad page can actually capture.
Sandboxing the browsing environment itself
Running the agent's browser in an isolated, disposable environment, rather than a persistent one shared across tasks or users, limits how far a compromise from one malicious page can spread. A sandboxed session that gets torn down after each task means a successful manipulation on one page can't quietly persist and affect the next task, the next user, or the underlying host system.
Action confirmation for consequential clicks
Not every click needs confirmation, but purchases, form submissions with personal data, and navigation to unfamiliar domains deserve a checkpoint before the agent commits to them. This mirrors the human instinct to pause before clicking something unfamiliar, applied deliberately to an agent that doesn't have that instinct unless it's built in.
Domain and action allowlisting where the task permits it
For agents with a well-defined task, checking into a booking site, filling out a specific form, restricting navigation to a known set of domains or a narrow action pattern removes most of the open-ended risk of unrestricted web browsing. This isn't possible for every use case, general-purpose research agents need broader reach, but wherever the task is narrow enough to allow it, it's one of the strongest practical controls available.
Anti-bot defenses and agent legitimacy cut both ways
Many websites deploy CAPTCHA and bot-detection systems specifically to block automated traffic, and a legitimate browsing agent will run into these defenses just as readily as a malicious scraper would, which creates an odd incentive: teams operating browsing agents sometimes look for ways to appear more human to get past these checks, and that impulse deserves scrutiny rather than automatic engineering effort. An agent designed to evade a site's explicit anti-automation controls is operating in a gray area regardless of how legitimate its underlying task is, and treating every CAPTCHA as an obstacle to route around, rather than a signal that a given site may not want automated access at all, can turn a security review into an ethics and terms-of-service problem as much as a technical one.
Where TELEON fits
For browsing agents that call out through defined tools or APIs rather than a raw browser interface, TELEON's enforcement at the tool-call boundary can apply domain restrictions, action-level policy, and logging independently of what the agent's browsing session encountered, giving teams a consistent checkpoint before any consequential action, form submission, purchase, credential use, actually executes.
Sandboxing the browsing environment itself and detecting malicious page content are specialized capabilities that need to live in the browsing infrastructure and content-handling layer, separate from tool-call policy enforcement.
A short checklist
- Treat every webpage the agent visits as untrusted, attacker-capable content.
- Scope what session data and credentials the agent carries into a browsing task.
- Run browsing sessions in an isolated, disposable sandbox torn down after each task.
- Require confirmation before purchases, data submissions, or unfamiliar-domain navigation.
- Restrict navigation to known domains wherever the task definition allows it.
- Clear session state aggressively between tasks rather than reusing a persistent session.
- Log the pages visited and actions taken for later review of any disputed outcome.
Browsing agents inherit every general agent risk and add one that's structurally unavoidable: the content driving their next decision comes from a source nobody on your team controls or reviewed. Accepting that as a permanent condition, rather than a gap to eventually close, is what leads to the sandboxing and scoping decisions that actually make browsing agents safe to run unattended, and it's also why narrowing the task itself, rather than trying to defend against an unbounded open web, tends to be the more durable fix over time.