LLM-guided fuzzing exposes prompt injection risk in browser agents

At a glance

What this is: This is Seraphic’s analysis of how in-browser, LLM-guided fuzzing can uncover prompt injection weaknesses in AI-powered browser assistants and extensions.

Why it matters: It matters to IAM and security teams because AI browsers act with user privileges, so prompt injection can become a practical access and action-control problem, not just a model-safety issue.

By the numbers:

• Failure rates reached 58% to 74% after just ten iterations as the fuzzer evolved against browser agents and extensions.
• The platform runs over 130 security checks to assess browser posture in a controlled simulation environment.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Seraphic's research on LLM-guided fuzzing for browser prompt injection

Context

AI-powered browser assistants are software entities that use LLMs to navigate web pages, interpret content, and take actions on behalf of a user. The security problem is that these assistants inherit user-level trust while processing untrusted web content, which creates a direct path from page content to action execution. For browser agents, prompt injection is the control-breaking pattern that turns content ingestion into unintended behaviour.

That makes browser automation relevant to IAM, PAM, and NHI governance because the browser agent is effectively operating as a privileged runtime actor. When the assistant can click, summarise, retrieve, or submit data across domains, the boundary between authentication, authorisation, and user intent becomes harder to enforce. The article’s starting position is typical of the market, which is to treat browser security as posture hardening rather than identity and action governance.

Seraphic’s research focuses on how to test those failures in a live browser rather than in a static lab. That distinction matters because prompt injection is adaptive, and controls that look effective in a single run often collapse once the attacker mutates the prompt chain and observes the agent’s response.

Key questions

Q: What breaks when browser AI agents can act on untrusted page content?

A: The separation between reading data and executing actions breaks first. If a model can see attacker-controlled text and then call tools inside an authenticated session, the prompt becomes a command channel. That creates prompt-to-action collapse, where comments, emails, or ticket text can trigger form fills, transfers, or exfiltration without a real user decision.

Q: Why do NHIs complicate zero trust and least privilege efforts?

A: NHIs complicate zero trust because they are numerous, persistent, and often tightly integrated into applications and pipelines. If teams cannot see every identity or keep permissions aligned to actual usage, they cannot consistently prove least privilege. Continuous review and revocation are essential, not optional.

Q: How do teams know whether prompt injection controls are actually working?

A: Look for end-to-end visibility across prompts, retrieved content, memory, tool calls, and outputs, plus evidence that blocked actions stay blocked under realistic test cases. If the system can only be evaluated with static prompts, the controls are probably too narrow. Behaviour drift under multi-turn workflows is the signal to watch.

Q: Should organisations treat browser assistants like other high-risk identities?

A: Yes. If a browser assistant can act, retrieve data, or navigate across domains, it is operating as a delegated runtime identity and should be governed that way. That means ownership, scoped privileges, logging, approval boundaries, and revocation paths should exist before the assistant is allowed into production workflows.

Technical breakdown

How prompt injection hijacks AI browser assistants

Prompt injection works when malicious instructions are embedded in web content that an AI assistant reads as part of its normal context. In an agentic browser, the model may treat hidden text, HTML comments, or deceptive page elements as higher-priority instructions than the user’s original request. Because the assistant can execute actions directly in the browser, the attack does not need code execution in the traditional sense. It only needs the model to reinterpret intent and act on it. That creates a control gap between content ingestion and action authorisation, especially when page summarisation or question answering features ingest everything on the page.

Practical implication: isolate untrusted content from action-bearing prompts and require explicit policy gates before the browser can execute cross-domain actions.

Why LLM-guided fuzzing is more effective than static test cases

LLM-guided fuzzing uses a model to mutate attack prompts based on live feedback from the target agent. Instead of replaying a fixed set of injections, it adapts wording, structure, and placement to find what bypasses a given defence. Running the fuzzer inside a real browser environment improves fidelity because the test sees the same page rendering, extension behaviour, and interaction paths that a user would. This is closer to adversarial testing than unit testing, and it exposes brittle controls that fail after the attacker learns which prompts trigger clicks, submissions, or data exposure.

Practical implication: test browser agents continuously under changing adversarial prompts, not with one-time validation suites.

Why summarisation and question answering features are high-risk

Summarisation and question answering are risky because they are designed to ingest broad page context and present a trusted answer to the user. That design encourages over-collection and over-trust: the assistant may read content that the user never intended to act on, then surface or execute outputs that carry attacker influence. The article’s finding that these features were especially vulnerable is consistent with a common agent design flaw, namely that the feature optimises for completeness and convenience rather than instruction hygiene. In identity terms, the assistant is acting with delegated authority but without sufficient guardrails on what counts as trusted instruction.

Practical implication: treat summarisation and QA as privileged workflows and apply least-privilege rules to the data they can ingest and the actions they can trigger.

Threat narrative

Attacker objective: The attacker wants to turn the browser assistant’s delegated authority into unintended action execution or data exposure.

1. Entry occurs when malicious instructions are hidden inside page content that the browser assistant processes as normal input.
2. Escalation follows when the agent treats injected instructions as part of its task and performs clicks, submissions, or data handling with the user’s authority.
3. Impact is achieved when the agent exfiltrates sensitive data or performs unwanted actions across domains without the user recognising the compromise.

NHI Mgmt Group analysis

Prompt injection is now an identity and authorisation problem, not just a model-safety problem. When a browser assistant can read a page and act on it, the real question is who or what is allowed to issue the next instruction. That maps directly to IAM and PAM concerns about delegated authority, because the assistant can inherit user privilege without inheriting user intent. Practitioners should treat browser agents as governed execution environments, not passive interfaces.

Adaptive fuzzing exposes a governance debt that static testing cannot see. A control set that survives one prompt pattern may still fail once the attacker mutates tone, structure, or context. That is the named concept here: instruction drift exposure, meaning the widening gap between a model’s intended task and the instructions it actually follows under adversarial pressure. Security teams should assume this drift will recur whenever page content and action execution share the same trust boundary.

High-trust browser features are the most operationally dangerous because they collapse verification into convenience. Summarisation and question answering are attractive precisely because they reduce user friction, but they also widen the blast radius of a successful injection. This is the same pattern seen in other identity failures: privilege becomes dangerous when the system cannot distinguish legitimate delegation from hostile steering. The practical conclusion is that browser security now needs identity-grade policy enforcement.

The market signal is clear: agentic AI needs runtime governance, not only pre-deployment scanning. Real-time fuzzing changes the evaluation model from compliance checking to adversarial resilience. That aligns with OWASP Agentic AI Top 10, MITRE ATLAS, and NIST AI RMF thinking, where resilience is measured by how well the system resists instruction manipulation under live conditions. Practitioners should expect browser security controls to move closer to continuous control validation.

What this signals

Instruction drift exposure is the operational pattern practitioners should watch as browser assistants become more capable. The risk is no longer only that an agent can be tricked once, but that repeated interaction allows small prompt changes to accumulate into reliable control bypass. That is why continuous testing matters more than one-off assurance, especially where the browser agent can reach sensitive workflows.

The governance lesson is that browser automation should inherit identity controls, not bypass them. When delegated tools can read arbitrary web content, every downstream action needs an explicit policy boundary, a named owner, and auditability. The combination of NHI visibility and agentic AI governance is where teams will distinguish safe automation from unmanaged runtime authority.

Security teams should also align these controls with external guidance such as the NIST AI Risk Management Framework and the OWASP Top 10 for Agentic Applications 2026. Those frameworks reinforce the same point: the question is not whether the model can navigate, but whether the organisation can constrain what it is allowed to believe and do.

For practitioners

• Separate instruction sources from action sources Design browser agents so untrusted page content cannot directly become executable instruction. Use strict context separation, policy checks, and allow-listed action paths for cross-domain navigation and data handling.
• Treat summarisation and QA as privileged browser workflows Apply tighter controls to page summarisation and question answering than to passive browsing, including scoped data ingestion, action approval gates, and logging for every sensitive interaction.
• Run continuous adversarial fuzzing against browser agents Test agentic browsers in live environments with evolving prompt injections, not just a fixed regression set. Pair the tests with detection of hidden links, comment-based instructions, and unexpected click sequences.
• Map browser-agent controls to identity governance Assign ownership for browser agents, define the delegated privileges they inherit, and review their access like any other high-risk runtime identity. That is where least privilege becomes enforceable rather than assumed.

Key takeaways

• Prompt injection turns AI browser assistants into governed execution risks because they can mistake hostile page content for legitimate instruction.
• Seraphic’s fuzzing results show that browser-agent defences can degrade quickly under adaptive attack, which makes continuous testing a control requirement rather than a research exercise.
• Browser assistants need identity-grade privilege boundaries, especially for summarisation and question-answering workflows that can read broadly and act quickly.

Key terms

• Prompt Injection (Agentic): An attack where malicious instructions are embedded in content that an AI agent reads — causing the agent to execute unintended actions using its own legitimate credentials. A primary vector for agent goal hijacking and identity abuse.
• Agentic Browser: An agentic browser is a web browser with an embedded AI assistant that can interpret page content and take actions on the user’s behalf. It combines browsing, reasoning, and execution in one interface, which creates new governance requirements for identity, data handling, and approval boundaries.
• Exposure Drift: Exposure drift is the gap between the state a security team last validated and the state the environment has reached since then. In fast-changing cloud and identity-heavy environments, that gap can be large enough to make a previous pentest result unreliable for operational decisions.
• LLM-Guided Fuzzing: LLM-guided fuzzing uses a language model to mutate test inputs based on live feedback from the target system. For browser security, it helps defenders discover prompt injection weaknesses that static test cases miss because the attacker adapts faster than the baseline rule set.

What's in the full article

Seraphic's full article covers the operational detail this post intentionally leaves for the source:

• The live in-browser fuzzing workflow used to mutate prompt injection attempts in real time.
• The Browser Total assessment logic behind more than 130 security checks across browser posture signals.
• The feature-specific findings for summarisation and question answering that drove the highest attack success rates.
• The public framework access and contribution model for teams that want to run their own tests and add attack templates.

👉 Seraphic's full article covers the browser testing framework, attack mutations, and defensive findings in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It helps practitioners translate delegated access into controls that can be owned, reviewed, and revoked.