Most AI browser agents can see every tab you have open, read what you type, and access the model's own system prompt — all at once. Most companies deploying these agents haven't fully reckoned with what that operating model exposes.

LLM01

Prompt injection ranks #1 in the OWASP Top 10 for LLM Applications — second edition running

14%

of enterprise AI agents go live with full security and IT approval, per Gravitee's 2026 State of AI Agent Security report

47%

of deployed AI agents are actively monitored or secured — meaning most aren't, per the same report

The gap those numbers describe isn't a features gap. It's a governance gap — and it's sitting inside a category of attack most end users, and a fair number of the companies shipping these agents, haven't fully priced in.

It's called indirect prompt injection. An agent browsing on a user's behalf can't always tell the difference between an instruction from that user and an instruction hiding in the page it just read. Hidden text on any site — a forum thread, a support ticket, a shared doc — can carry an embedded instruction: send the saved logins, forward the session data, initiate a transfer. The text can be invisible to a human and fully readable to the model: zero-size font, white-on-white, off-screen, buried in alt-text or an HTML comment. The user never sees it. The agent does.

Guardrails here aren't one control. They're a stack of mitigations, because no single layer reliably catches indirect injection on its own — and most agents shipping right now are missing most of the stack.

None of this replaces testing before launch, not after. Injection attacks follow known patterns by now — hidden text, alt-text, ARIA labels, unicode tricks. Any organization shipping a browser agent, or evaluating a vendor's, should be running it against that playbook before release, not treating production traffic as the QA process.

Prompt injection today is where SQL injection was two decades ago: a known, exploitable class of vulnerability without a clean fix.

The difference is that SQL injection never had access to a bank login, a set of health records, and a crypto wallet all in the same session. The guardrails available today mostly limit what a hijacked agent can do — they don't yet guarantee it can't be hijacked in the first place. That's a meaningful improvement over nothing. It's also a narrower guarantee than "fully autonomous" marketing tends to imply.

That's the governance gap this piece opened with, and it doesn't close on its own. Trust boundaries, confirmation steps, scoped access, monitoring, and pre-launch testing against known attack patterns are unglamorous engineering decisions — but they're the difference between shipping a tool and shipping a liability. Before deploying an AI browser agent, or approving a vendor's, the question worth asking is simple: what can it access, what needs confirmation, and what happens when it reads something it shouldn't trust? If that answer isn't immediate and specific, the guardrails aren't there yet.

The guardrail stack is the work. We help growth-stage companies build it before an agent ships, not after an incident.