Field note

How to protect your site from agent hijacking (on-page prompt injection)

Agentic browsers read your page as they act for a visitor, so hidden instructions in your reviews, comments, ads, or embeds can hijack that visitor's agent mid-session. You can't patch the browser, but you can keep your own pages clean. A 2026 page-hygiene playbook: audit UGC, vet third-party code, catch hidden text, sanitise inputs, and monitor.

Buffy Editorial2026-08-27 · 4 min read

You cannot patch an agentic browser, but you can keep your own pages from carrying the instructions that hijack a visitor's agent. The threat is on-page prompt injection: an agentic browser reads your live page while acting for a user, and hidden instructions in your reviews, comments, ads, or embeds can be treated as if the user typed them. A 2026 University of Washington study found several agentic browsers where this can be pushed far enough to cross the same-origin policy. This playbook is the brand-side response: five steps to make your own pages a clean surface for the agents that visit them.

Last reviewed: 27 August 2026. This is a defensive how-to, not a threat report. It pairs with the data piece on what the same-origin-policy finding means for brands. The specifics below are conservative hygiene that helps regardless of which browser a visitor uses; treat the underlying research as single-study and directional.

Why can my own page hijack a visitor's agent?

Because the agent reads everything on the page as potential input, and not all of that content is written by you. Any surface where third parties can put text — a review, a comment, an embedded widget, an ad frame, or invisible text an attacker slipped in — is a place an instruction can hide. The agent, working for your visitor, may act on it. So the goal is not to remove content; it is to make sure the content the agent reads cannot issue commands.

Step 1: Audit your user-generated content

Start where strangers can already write on your page. Reviews, comments, ratings, community Q&A, and forum threads are the most common injection surface because they are, by design, third-party text you publish.

  • Inventory every place a non-employee can submit text that renders on a page an agent might read.
  • Strip or neutralise instruction-like patterns in submitted content (imperative phrasing aimed at a tool, embedded code, invisible characters).
  • Render user content as inert text, never as anything an agent could mistake for a page instruction or a control.

Step 2: Vet third-party embeds, ads, and scripts

Move next to the code you did not write but do publish. Ad frames, chat widgets, review platforms, and tag-manager scripts all inject content you do not fully control, and any of them can become a carrier.

  • List every third-party embed and script on your key commercial pages.
  • Drop anything you cannot justify; each one is a surface you are trusting on your visitor's behalf.
  • Prefer vendors that sanitise their own output, and keep ad and widget content isolated from the parts of the page an agent needs to act on (prices, buttons, checkout).

Step 3: Catch hidden and injected text

Then look for text a human never sees but an agent still reads. Attackers favour invisible instructions — white-on-white text, zero-size fonts, off-screen elements, aria-hidden traps — precisely because they slip past a person and reach the machine.

  • Scan pages for content that is present in the markup but visually hidden, and confirm each instance is legitimate.
  • Watch for text injected through comment fields, URL parameters, or profile fields that echo onto the page.
  • Make "what does an agent read here that a human does not?" a standing check on templates that accept outside input.

A person skims your page; an agent reads all of it. The safe assumption is that anything in your markup can become an instruction — so publish nothing you have not vetted as inert.

Step 4: Sanitise every input that echoes onto a page

Apply the classic web-security discipline, now with a new reason. Any value from a URL, form, search box, or profile that gets reflected back into a page is a reflection point — the same weakness behind older injection bugs, with an agent as the new target.

  • Escape and validate reflected inputs so submitted text cannot become active content.
  • Give user-supplied text a clear, consistent boundary in the page so it reads as data, not direction.
  • Keep the parts of the page an agent must trust — structured data, prices, calls to action — populated only from your own systems.

Step 5: Monitor your pages and your brand across agents

Finally, keep watching, because the surface moves. Content changes, vendors update, and new agentic browsers arrive; a page that was clean last quarter may not be now.

  • Re-audit high-traffic commercial and checkout pages on a schedule, not once.
  • Track how your brand is surfaced and acted on across agents over time, so a change shows up as a signal rather than an incident.
  • Keep this distinct from answer poisoning defence: that protects what engines say about you in their answers; this protects what a visitor's agent does on your page. Both are first-party-surface control; the fixes differ.

The honest read: you cannot make an agentic browser secure, but you can make your own pages a poor place to hide an instruction — which protects the people those agents work for and the trust your brand depends on. Keeping an eye on how your brand is discovered and acted on across AI surfaces, over time, is exactly what Buffy Intel is built to do. Questions: [email protected].

Frequently asked

Can content on my own website hijack a visitor's AI agent?

Yes, in principle. Agentic browsers read the live page as part of acting for the user, and prompt injection is when hidden instructions in content get treated as if the user typed them. So text placed in your reviews, comments, third-party ad frames, or as invisible on-page text can carry instructions a visiting agent may obey. A 2026 University of Washington study found several agentic browsers where this can be used to cross the same-origin policy. You cannot fix the browser, but you can reduce the chance your own pages carry the injected instructions — by sanitising user-generated content, vetting third-party code, and catching hidden text.

How is this different from AI answer poisoning?

Answer poisoning seeds false content into the sources an AI engine retrieves, so the model repeats a falsehood about your brand in its answers — a corpus-level attack on your reputation. On-page agent hijacking is different: it targets the visitor's agent during a live session on your page, using instructions hidden in your page's content to make the agent do something the user did not ask for, such as leaking data. They share a defensive instinct — control your first-party surface — but the fix is different. Answer poisoning is countered with corroboration and canonical facts; agent hijacking is countered with page hygiene.

Do I have to block AI agents to stay safe?

No. Blocking agents removes a growing discovery-and-checkout surface and does not make your existing pages cleaner. The better response is page hygiene: keep user-generated content, third-party embeds, and hidden text from carrying instructions a visiting agent could obey. You keep the visibility benefits of being readable by agents while reducing the chance your own page is used against your visitor.