Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

Is It Safe to Let AI Agents Interact With External Websites?

Interacting is safe only when consequential actions, such as payments, submissions and account changes, are gated by action type and destination, because an agent that clicks and types under the user's sessions turns a read-time injection into a completed transaction. Check which actions the agent can finish without a person, and where.

A single abstract agent sphere approaches a slatted boundary that branches toward external web pages.

Interacting is safe only when consequential actions, such as payments, submissions and account changes, are gated by action type and destination, because an agent that clicks and types under the user's sessions turns a read-time injection into a completed transaction. Check which actions the agent can finish without a person, and where. Reading a hostile page compromises the agent; acting is what makes the compromise cost something. A browsing agent that fills forms, submits orders and changes settings does so inside the user's authenticated sessions, with the user's cookies and the user's standing in every site that is logged in. Security boundaries built for the web assume that one site cannot drive another; an agent operating the browser is, by design, something that drives all of them. This page sets out why acting multiplies the impact of a read-time injection, what the browser and agent vendors say about the privileges their agents inherit, how a corporate travel profile illustrates the gap between reading and acting, why controls should key on action type and destination rather than on sites, what the governance of agent actions should record, and what a buyer should refuse.

Key findings

  • In a browsing agent that was shown to be vulnerable to indirect prompt injection, the AI operated with the user's full privileges across authenticated sessions, so protections modeled on the same-origin policy did not contain it (Brave, 2025).
  • Web agents begin following injected instructions in up to 86 percent of cases in a NeurIPS 2025 benchmark, while even state-of-the-art agents often struggle to fully complete the attacker's goals, which places the remaining defense at the action step (arXiv, 2025).
  • In a large-scale red-teaming competition analyzed by NIST's Center for AI Standards and Innovation, more than 250,000 attempts by over 400 participants found at least one successful attack against all of the target frontier models (NIST CAISI, 2026).
  • The Agents Rule of Two holds that an agent should satisfy no more than two of three properties in a session, untrusted input, sensitive data access, and external state change or communication; interacting with websites is the third (Meta AI, 2025).
  • Vendors that ship browsing agents publish permission guides and system cards that describe confirmations and site restrictions for sensitive actions, an acknowledgment that acting is where controls belong (OpenAI, 2025).
  • The practical control is to gate payments, submissions and record changes by type and destination and to record every action with its approver (How to secure AI Agents in Enterprise?).

Why does acting multiply the impact of a read-time injection?

An injection that lands on a read-only agent produces a wrong answer or, through a rendering channel, a leak of what the agent held. An injection that lands on an agent that can act produces a transaction. The difference is the difference between an attacker learning a card number and an attacker spending it.

The published benchmarks place the remaining defense precisely at that boundary. In the WASP benchmark, agents began following injected instructions in up to 86 percent of cases, but even state-of-the-art agents often struggled to fully complete the attacker's goals (arXiv, 2025). The attacker's goal in a web setting is almost always an action: submit this form, change that address, authorize this payment. Agents start down the path readily and finish less often, which means the steps between reading and completing are where friction still works. Remove the friction, by letting the agent click through confirmations and complete multi-step flows unattended, and the completion rate rises toward the start rate.

NIST's Center for AI Standards and Innovation analyzed a red-teaming competition in which more than 250,000 attempts by over 400 participants found at least one successful attack against all of the target frontier models (NIST CAISI, 2026). The finding is not that models are weak but that none is immune under sustained adversarial effort. For an agent that acts, the deployment must assume a successful injection will occur and design the action path so that a compromised agent cannot complete a consequential transaction alone.

What privileges does a browsing agent inherit?

The user's. That is the design, and the vendors say so. Brave's analysis of indirect prompt injection in a browsing agent found that the AI operated with the user's full privileges across authenticated sessions, which meant that protections modeled on the same-origin policy, the web's rule that one site's scripts cannot act on another site, did not contain it (Brave, 2025). An agent that reads a hostile page and then navigates to the user's bank, email or payroll portal is logged in at each, because the user is.

Vendor What its documentation describes, per the pages reviewed What a buyer should verify
OpenAI (Operator) A system card describing mitigations for a browsing agent, including confirmations for certain actions and restrictions on sensitive sites Which actions trigger confirmation, and whether the confirmation shows the destination
Anthropic (Claude in Chrome) A permissions guide describing how users control what the agent may do on which sites (Anthropic, 2026) Whether permissions key on action type or only on site
Google (Chrome) An architecture for security of agentic capabilities in the browser How the architecture separates the agent's actions from the user's sessions
AWS (AgentCore Browser) Documentation for a managed browser tool through which agents interact with web applications What the agent can see on the pages it operates, and what is logged

Each vendor documents controls at the level of sites and sensitive actions, and each leaves to the deployer which actions are consequential for its business and what the agent holds when it acts. Anything a vendor page does not cover is not described in the pages reviewed. None treats an acting agent as safe by default.

How does a single record illustrate the gap between reading and acting?

Consider a corporate travel profile. It holds the traveler's legal name, date of birth, passport number and expiry, frequent flyer numbers, the corporate card on file, the cost center and the approving manager. An agent is asked to book a flight and a hotel for an upcoming trip, which means visiting airline, hotel and aggregator sites, comparing options and completing purchases.

In the reading phase, the agent visits external pages. If a hotel listing carries an injected instruction, the benchmarks say the agent may begin to follow it. With a read-only agent, the worst case is that the recommendation is wrong or that profile data is encoded into a URL. With an acting agent, the worst case is a completed purchase at a destination the attacker chose, paid with the corporate card, or a change to the loyalty account's contact details that redirects future communications, all performed with the user's standing at each site because the agent operates in the user's sessions (Brave, 2025).

Two controls change the outcome. First, what the agent holds: if the profile reaches the model with PASSPORT_001 and CARD_001 in place of the real values, an injected instruction to enter them on a form produces tokens, and the data exposure is bounded regardless of what the agent does. Second, what the agent can finish: if every payment and every account change requires a named person to approve while seeing the real destination and amount, an injection that reaches the purchase step meets a checkpoint. The real card number resolves only at the approved airline's payment page, at the moment of the approved purchase, and nowhere else. The Rule of Two describes the same move in general terms: with untrusted input unavoidable, constrain sensitive data or external state change (Meta AI, 2025). An acting agent should constrain both.

Why should controls key on action type and destination rather than on sites?

Site-based permission is the natural first control, and the vendor permission guides reviewed are organized that way: which sites the agent may visit, which it may act on. The limit is that the harmful action and the legitimate action often happen on the same site. The agent is supposed to buy a flight on the airline site; the attacker wants it to buy a different flight, or to change the account's email, on the same airline site. A site allowlist cannot tell them apart.

Action type can. Payments, submissions to external parties and changes to records of account are consequential regardless of site. Browsing, comparing and drafting are not. A policy that says "any payment requires approval" catches the attacker's purchase and the legitimate one alike, and the approver distinguishes them by looking at the destination and amount. A policy that says "the airline site is allowed" catches neither.

Destination completes the picture. The same action type has different consequences at different destinations: a payment to the airline the traveler chose is the task; a payment to a merchant that appeared in an injected listing is the attack. An approval screen that shows the destination as the payment system will record it, not as the model describes it, lets the person decide on facts. Securing agents in enterprise therefore means a policy with three columns, action type, destination and approver, applied uniformly across every site the agent touches, rather than a site list maintained by hand.

This framing also handles the vendor landscape. Whether the browsing agent is a browser extension, a standalone agent or a managed browser tool like the one AWS documents for interacting with web applications (AWS, 2025), the policy attaches to the action, not to the product.

What should the record of an acting agent contain?

An agent that acts leaves consequences in external systems, and the organization needs to be able to reconstruct how each one came about. Four elements make the record useful. The pages the agent read, as the model received them, so that an injected listing can be found after the fact. The internal screens the agent held, as tokens, so the record itself does not become a second copy of the sensitive data. Every action with its type, destination and parameters as the executing system recorded them. And every approval, with the named person and the time.

The record serves three audiences. The security team uses it to investigate: if a purchase went to the wrong merchant, which page carried the instruction and which approval let it through. The compliance function uses it to evidence oversight: that consequential actions were approved by accountable people, which is what sensitive data masking and action governance exist to produce. And the business uses it to tune: if an approver handled more confirmations per hour than they could read, the scope of consequential actions or the agent's reach needs adjusting.

Vendor logs cover the vendor's product. A record that spans every site and application the agent touches, exported to the organization's own monitoring, is the organization's. Google's architectural framing of agentic security in Chrome assigns the browser vendor the hardening of the agent and leaves the deployer's policy and evidence to the deployer (Google, 2025); the record described here is the deployer's half.

What does a governed environment change?

In a governed environment, a read-time injection can no longer finish as a completed transaction, because the payment, submission or account change it tries to trigger waits for a named person who sees the real destination from the executing system rather than from the model's summary.

The mechanism is a class of control between the rendered screen and the model. Sensitive values on internal screens and in the user's own profile are replaced with consistent tokens before any model reads them, and the task runs on those tokens. Real values resolve only at an approved destination at the moment of an approved action, so a token typed into an attacker's form resolves to nothing. A named person confirms what is tokenized and approves consequential actions by type and destination. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

This bears on the title question because the two defenses the page rules out are the ones this class of control does not rely on. Site lists did not contain an agent that operated with the user's full privileges across authenticated sessions (Brave, 2025), and model resistance lowers the rate without reaching zero, since the largest published red-teaming analysis found a successful attack against every target model (NIST CAISI, 2026). The environment keys on action type and destination instead, and the first demonstration described above, an injected listing redirecting a purchase, is its ordinary behavior.

The control does not change the websites, the user's sessions or the model; the environment changes what the agent holds while reading and what it can finish without a person.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. The design constrains both of the conditions a deployer can control. Agents run in a governed environment in the customer's cloud. Substitution happens at the render layer, before any model reads the screen, so the travel profile described above reaches the model with PASSPORT_001 and CARD_001 in place of the real values, with consistent tokens for the whole run, while the external sites the agent operates render as they are. Real values resolve only at approved destinations at the moment of an approved action: the card number appears on the airline's payment page when a person has approved that purchase, and nowhere else. A named person confirms the tokenization policy and approves every payment, submission and record change under Supervised Delegation, with the destination shown from the environment rather than the model. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would plant a listing that tries to redirect a purchase, run the booking task on a real record type, and show what the model held, what the approval screen displayed, and what the record captured. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Brave's published analysis of indirect prompt injection in a browsing agent, the peer-reviewed WASP benchmark accepted at NeurIPS 2025, NIST's Center for AI Standards and Innovation analysis of a large-scale red-teaming competition, the Agents Rule of Two analysis from Meta AI, and vendor documentation from OpenAI (Operator system card), Anthropic (Claude in Chrome permissions guide), Google (security architecture for agentic capabilities in Chrome) and AWS (Amazon Bedrock AgentCore Browser). Existing RedactSure research pages on securing agents in enterprise, agent data exposure and sensitive data masking are cited as evidence for the design points they document. All sources were read as of October 16, 2026.

No hands-on testing of any browsing agent, browser or product was performed for this page. Vendor controls are described from the vendor's own pages; where a capability is described as "not described," that means it was not found in the pages reviewed, not that the vendor lacks it. The vendor comparison table summarizes what each page covers and does not rank the products. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The corporate travel profile and booking task describe a record type and a task, not any organization; no customer or prospect is described.

Whether a given deployment's action policy, approval design or handling of payment and identity data meets an organization's requirements is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

Letting an agent interact with external websites is safe to the extent that consequential actions cannot complete without a person who sees the true action and destination, and that the agent holds nothing real to enter when an injected page asks. The agent inherits the user's full privileges across authenticated sessions, so site boundaries do not contain it; benchmarks show agents starting injected tasks readily and finishing them less often, which places the working defense at the action step; and sustained red-teaming has found a successful attack against every model tested. Controls that key on action type and destination, with render-layer substitution of the kind RedactSure describes bounding what the agent holds, address both halves. The test is to name one agent and one task, plant a listing that redirects a purchase, and ask who approved it, what they saw, and what the model held.

Frequently asked questions

Is acting on a website more dangerous than reading one?

Yes, because acting converts a compromise into a consequence. A read-only agent that follows an injected page gives a wrong answer or leaks what it held. An acting agent completes a purchase, submits a form or changes an account, using the user's logged-in sessions. The benchmarks show agents start injected tasks far more often than they finish them, so the steps between reading and completing are where controls still have leverage.

Why does the same-origin policy not protect against an agent?

The same-origin policy stops one site's scripts from acting on another site. An agent operating the browser is not a site's script; it is an actor above all sites, logged in everywhere the user is. Brave's analysis found that a browsing agent operated with the user's full privileges across authenticated sessions, so an instruction read on one site could drive actions on another. The web's boundaries were built for a different kind of actor, and a site cannot tell an agent's click from the user's.

Should permissions be set by site or by action?

By action type and destination, with sites as a supporting layer. The attacker's action is usually on a legitimate site, in the user's session, so a site allowlist cannot distinguish the task's purchase from the injected one. A rule that every payment, submission and account change requires approval, with the destination shown from the executing system, catches both and lets the approver tell them apart on facts.

What does the NIST red-teaming finding mean for deployment?

That no model should be treated as immune. More than 250,000 attempts by over 400 participants found at least one successful attack against every target frontier model. For an acting agent, the design should assume an injection will succeed sometimes and ensure the action path holds when it does: consequential actions wait for a named person, and the agent holds tokens rather than real identifiers while it works.

Does limiting what the agent sees matter if actions are already approved?

Yes, for two reasons. Approval covers the actions the policy classifies as consequential; an injected instruction to type a passport number into a search box is not a payment and may not be gated. And approval depends on the approver reading carefully, which degrades with volume. If the agent holds tokens, a missed approval or an ungated field still exposes nothing real. The two controls cover each other's gaps, and a deployment that has only one of them is relying on that one never failing.

What should the record of a booking session show?

Every page the agent read, as the model received it; the profile it held, as tokens; every action with its type, destination and parameters as the site recorded them; and every approval with the person and time. That record lets the security team find the injected listing, lets compliance evidence oversight, and lets the business see whether approvers are handling more confirmations than they can read. Exported to the organization's own monitoring, it stays independent of the agent vendor.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.