AI browser prompt injection turns Comet into a data exfiltration path

At a glance

What this is: A crafted URL can hijack Comet’s assistant flow and expose memory and connector data through prompt injection.

Why it matters: IAM and security teams need to treat agentic browsers as identity-bearing systems because a single click can redirect trusted access into unauthorized data disclosure.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read LayerX Security's analysis of Comet URL prompt injection and browser data exfiltration

Context

AI-native browsers blur the line between a user interface and a delegated identity. In Comet’s case, the browser can hold memory, connect to Gmail and Calendar, and execute actions on behalf of the user, which means a malicious URL can manipulate the assistant’s behaviour rather than merely display malicious content.

That changes the identity problem for security teams. The control question is no longer only whether a user clicked a bad link, but whether an agentic session can be redirected through URL parameters into reading, transforming, and exporting sensitive data across connected services.

Key questions

Q: How should security teams stop agentic browsers from turning links into data exfiltration paths?

A: Security teams should separate link handling from assistant instruction processing, so a URL cannot directly trigger privileged model actions. They should also require explicit user re-authorization before the browser can access memory, mail, or calendar data after untrusted input is seen. The goal is to break the trust chain between external content and delegated access.

Q: Why do agentic browsers increase identity risk compared with normal web browsing?

A: Agentic browsers can hold memory, access connected services, and execute tasks on the user’s behalf, which makes them identity-bearing systems rather than passive interfaces. That means a malicious link can redirect trusted access into unauthorized retrieval or outbound action. The risk is not just phishing, but delegated misuse of an already-authenticated session.

Q: What breaks when exfiltration controls only look for plaintext sensitive data?

A: Controls that only inspect plaintext miss trivial transformations such as base64, chunking, or code-based reformatting. If the assistant is allowed to rewrite, encode, or serialize data before sending it out, the output channel itself becomes an attack path. Effective control must look at intent, destination, and permitted action, not just literal strings.

Q: Who is accountable when an AI browser leaks data from connected services?

A: Accountability sits with the organisation that granted the browser assistant access, because the browser is operating inside an authorised delegation chain. Security, IAM, and application owners must jointly define which memory and connector scopes are acceptable, how they are reviewed, and when they are revoked. Existing user-focused controls are not enough for delegated agent behaviour.

Technical breakdown

URL parameter prompt injection in agentic browsers

Agentic browsers can treat parts of a URL as instructions, not just navigation data. In this case, query-string content is used to steer the assistant into memory-backed retrieval and task execution. That matters because the browser’s parsing layer sits upstream of the model’s safety layer, so the attacker can influence what the agent reads before exfiltration checks ever see the output. The weakness is architectural: a trusted interface element becomes an instruction carrier, and the browser accepts that instruction without a separate authorization boundary between page navigation and assistant action.

Practical implication: separate navigation input from agent instructions so URL parameters cannot trigger privileged assistant behaviour.

Memory retrieval and connector exposure

The attack works because the assistant can consult memory and connected services such as email or calendar once it accepts the injected task. That means the exposed data surface is not limited to page content. It includes prior user memory, generated artefacts, and connector-granted information that the browser can already access in-session. If the system cannot prove that a prompt originated from the user rather than from untrusted content, the model can become a retrieval engine for data the attacker never authenticated to see.

Practical implication: constrain which memory and connector scopes an assistant can access after untrusted input is parsed.

Exfiltration through trivial encoding

The reported proof of concept shows that direct outbound filtering is not enough if the agent can transform stolen data before sending it out. Base64 is only one example of a trivial encoding step that can defeat naive content-based exfiltration checks. The deeper issue is that policy controls focused on literal data patterns miss the model’s ability to repackage information into seemingly harmless output. Once the agent is allowed to generate code or instructions, the output channel itself becomes part of the attack chain.

Practical implication: inspect intent and destination, not just raw payload patterns, when governing agent output.

Threat narrative

Attacker objective: The attacker wants to turn an authenticated assistant session into a covert data-exfiltration channel for memory and connector-granted information.

1. Entry occurs when a user opens a crafted URL in the Comet browser, including links delivered by email, an extension, or a malicious site.
2. Credential access is replaced by memory and connector abuse, because the URL parameters steer the assistant to retrieve data from exposed session memory and connected services.
3. Impact follows when the assistant encodes the data and posts it to an attacker-controlled endpoint, exposing email content, calendar data, and other connector-backed information.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

URL-driven prompt injection is a browser identity failure, not just a model safety bug. Comet’s risk comes from collapsing navigation and instruction into one trust boundary, so a harmless-looking link can become an authorization event. That breaks the assumption that assistant actions are only driven by the user’s intent. Practitioners should treat agentic browsers as delegated identities with their own control plane, not as safer search tools.

Delegated memory access becomes overbroad the moment the browser can act on behalf of the user. The article shows that memory, connector data, and generated tasks all sit inside one execution environment, which turns a single click into a cross-service exposure path. The governance problem is not merely exposure of one email or calendar item. It is that the assistant’s privilege domain now spans multiple identity systems without a clean separation of duties.

Base64 exfiltration shows that output filtering alone cannot contain agent misuse. If an assistant can transform sensitive data before sending it out, policy that only blocks obvious plaintext leakage is structurally too weak. This is where browser-native AI crosses from content filtering into identity governance. Practitioners need to rethink what counts as an outbound control in an agentic session.

AI browsers create a new identity blast radius that IAM teams are not yet modelling. A compromised session can move from user memory to connected mail, calendar, and eventually corporate workflows without any password theft. That broadens the practical meaning of least privilege for human and NHI programmes alike. Security teams should assume the browser itself can become the intermediary identity that expands blast radius.

Browser-based agent abuse belongs in OWASP NHI and agentic AI threat models. The attack pattern combines prompt injection, delegated access, and data exfiltration through a trusted runtime, which makes it relevant to both browser security and identity governance. That puts it squarely into the same control conversation as other high-trust non-human execution paths. Practitioners should map these sessions into existing NHI governance rather than treating them as a standalone UX issue.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• If you are mapping browser assistants into governance, start with Ultimate Guide to NHIs , Key Challenges and Risks for the control gaps that make delegated access hard to contain.

What this signals

Prompt-injected browser assistants are now an identity governance problem, not a niche model-safety issue. Once a browser can read memory and act across connected services, programme owners need to classify it as a delegated non-human identity with explicit scope, review, and revocation rules. The practical shift is toward controlling what the assistant can reach after untrusted input, not just what the user can authenticate to.

Identity blast radius becomes the right operational metric for agentic browsing. A single link can bridge user memory, email, calendar, and outbound posting, which means the control failure is cross-service by design. That makes NHI lifecycle discipline relevant even in human-facing browser sessions, because the browser is the thing carrying privilege across systems.

For teams aligning with external guidance, the relevant controls sit closest to the MITRE ATLAS adversarial AI threat matrix and browser-level trust boundaries, not traditional phishing-only playbooks. The governance question is whether your programme can distinguish user intent from model instruction after untrusted content has entered the session.

For practitioners

• Restrict assistant-triggering from untrusted URLs Block query-string content from being interpreted as instructions when the browser is handling external links. Separate page rendering, navigation, and assistant invocation so a click cannot become a privileged command path. Add explicit allowlists for when memory or connector access is permitted after a user opens external content.
• Limit connector scope after untrusted input Reduce the Gmail, Calendar, and file scopes available to the assistant during sessions that originated from external links. Use session-aware policy so connector access is downgraded until the user reaffirms the task in a trusted context. Review whether the browser can read from memory before any connector call is made.
• Detect transformed exfiltration paths Inspect generated output for intent and destination as well as literal sensitive fields. A model that can encode, chunk, or reformat data before posting it can bypass filters that only look for plaintext secrets. Test controls against code generation, base64 wrapping, and alternate serialization patterns.
• Treat agentic browsers as identity-bearing systems Classify browser assistants alongside other non-human identities in governance, recertification, and access review processes. Document what data they can reach, what they can emit, and which services they can chain together in a single session. Reassess whether human IAM controls are sufficient for a browser that can act autonomously on the user’s behalf.

Key takeaways

• A crafted URL can hijack an agentic browser session without stealing credentials, which makes browser identity a governance issue.
• The attack path crosses memory, connector data, and outbound transformation, so simple content filtering is not enough.
• Teams need to manage browser assistants like delegated non-human identities with scoped access, revocation, and session-specific controls.

Key terms

• Agentic Browser: A browser that can do more than display content. It can hold memory, use connectors, and execute actions on behalf of a user. In governance terms, it behaves like a delegated identity with access boundaries that must be reviewed, constrained, and revoked like any other high-trust runtime actor.
• Prompt Injection: A technique where untrusted content is designed to alter how an AI system behaves. In agentic environments, the risk is not limited to bad answers. The model may follow attacker instructions, access connected systems, or transform data for exfiltration if the trust boundary between content and command is weak.
• Identity Blast Radius: The practical spread of damage when one identity or session can reach multiple systems. In AI browser contexts, blast radius includes memory, mail, calendar, file stores, and outbound actions. It is a useful governance measure because it shows how far one compromised session can travel before containment stops it.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by LayerX Security: LLMjacking and browser prompt injection analysis for Comet. Read the original.