Notifications
Clear all
Topic starter
10/06/2026 12:09 am
TL;DR: BrowseSafe could be bypassed in 36% of red-team attempts, with encoding and HTML-based obfuscation defeating a model intended to secure AI browsers against prompt injection, according to Lasso Security. The result shows why continuous testing and runtime enforcement still matter when agent guardrails are expected to sit between hostile input and browser actions.
NHIMG editorial — based on content published by Lasso Security: BrowseSafe prompt injection risks in Perplexity's open-source model
Questions worth separating out
Q: How should security teams test AI browser agents for prompt injection risk?
A: They should test AI browser agents with the same transformations attackers use in practice, including encoding, HTML wrapping, and mixed-format payloads.
Q: Why do browser-based AI agents create more prompt injection risk than plain chatbots?
A: Browser-based AI agents create more risk because they do more than generate text.
Q: What breaks when prompt injection guardrails only look for obvious malicious text?
A: Guardrails fail when they depend on obvious wording because attackers can hide instructions inside encoding, HTML, or formatting that changes how the model reads the page.
Practitioner guidance
- Red-team AI browser controls before deployment Test guardrails against plain text, encoded payloads, and HTML-embedded instructions before they are allowed into production workflows.
- Add runtime action validation for browser agents Block or confirm high-risk browser actions such as open, click, form-fill, and submission when they arise from untrusted context or abnormal instruction patterns.
- Separate content detection from authorisation Treat a safe classification as an input to policy, not as permission to continue.
What's in the full article
Lasso Security's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step red-team setup for running BrowseSafe locally with remote GPUs and an inference server
- Specific HTML and encoding payload examples that produced successful bypasses in testing
- The full attack-success breakdown showing where the model marked malicious requests as safe
- Practical deployment guidance for layering custom policies and runtime enforcement around browser agents
👉 Read Lasso Security's BrowseSafe prompt injection test and bypass findings →
BrowseSafe and prompt injection: are AI browser controls keeping up?
Explore further
11/06/2026 1:49 am
Safe-by-model is a broken assumption for AI browser governance. BrowseSafe’s failure shows that a single detector cannot carry the burden of trust when the input is adversarial and the output can trigger real browser actions. The assumption that a model can reliably identify every malicious instruction before execution collapses as soon as encoding and structure become part of the attack surface. Practitioners should treat model-based filtering as one layer in a control stack, not as the control stack itself.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: How do organisations stop a model’s safe response from becoming unsafe execution?
A: They stop it by separating detection from permission. A model that labels content as safe should not automatically authorize browser actions. Organisations need policy enforcement, action validation, and event auditing so the system can deny execution even when the model output appears normal.
👉 Read our full editorial: BrowseSafe prompt injection shows runtime guardrails still fail
12/06/2026 3:23 am
Safe-by-model is a broken assumption for AI browser governance. BrowseSafe’s failure shows that a single detector cannot carry the burden of trust when the input is adversarial and the output can trigger real browser actions. The assumption that a model can reliably identify every malicious instruction before execution collapses as soon as encoding and structure become part of the attack surface. Practitioners should treat model-based filtering as one layer in a control stack, not as the control stack itself.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: How do organisations stop a model’s safe response from becoming unsafe execution?
A: They stop it by separating detection from permission. A model that labels content as safe should not automatically authorize browser actions. Organisations need policy enforcement, action validation, and event auditing so the system can deny execution even when the model output appears normal.
👉 Read our full editorial: BrowseSafe prompt injection shows runtime guardrails still fail
