Comet Enterprise Admin Controls, Mapped Against 5 Published Attacks

Five prompt injection attacks against Perplexity's Comet browser were published between August 2025 and March 2026. Read against those disclosures, the Comet Enterprise admin controls stop most of them, but only one setting does most of that work, and the documentation states no default for it. The record of what the agent actually did sits behind a 50-seat threshold.

The short answer. Comet Enterprise gives admins MDM deployment, more than 500 Chromium browser policies, a global switch for agent browser control, a confirmation requirement, and per-domain Browser Control, Read Only or No Access rules. Set No Access on email, password managers and admin consoles, turn off "Always Allow", and most published Comet attacks lose their payoff.

This review is a documentation walk, not a lab test. Every control below comes from Perplexity's own Help Center pages, and every attack comes from the researcher who disclosed it. Where the two do not meet, the gap is named.

What the Comet Enterprise admin console actually ships

Comet launched in July 2025. A version for Enterprise Pro customers followed in August, and Perplexity announced Comet Enterprise on 17 March 2026, according to TestingCatalog's launch coverage. The admin controls sit in three places, and they are easy to confuse.

The first is the MDM layer. Comet accepts Chromium's enterprise policy set, and Perplexity's policy page tells admins to replace com.google.Chrome with ai.perplexity.comet in existing profiles. That means your Chrome hardening work largely carries over, including URL blocklists, download restrictions and extension allowlists.

The second is the Assistant layer, set in Organization Settings under Comet Setup. This is where the agent is governed, and it is separate from the browser policies. The third is monitoring: telemetry for every MDM-enrolled organisation, and audit logs for larger ones.

Sources: Perplexity Help Center articles on Comet for Enterprise, Managing Comet Assistant Permissions, Comet Telemetry and Audit Logs. The "Default stated?" column records whether the page names a default, not what a new tenant actually ships with.

The right-hand column is the first finding. None of the agent controls has a documented default. Perplexity's own description of the case-by-case mode says it prevents the assistant from acting "without the user's consent", which implies the alternative is consent given once and then assumed. Our view is that any admin who has not opened this screen should assume "Always Allow" is available to users until they have checked.

The five Comet attacks the controls have to answer

Every attack below is a form of indirect prompt injection. Text the agent reads is treated as an instruction from the user. The general mechanism, and why it resembles early SQL injection, is covered in the analysis of prompt injection as an agent security problem. What matters here is the specific shape of each Comet case.

Brave, page content, August 2025. Brave hid instructions behind a spoiler tag in a Reddit comment. When the user asked Comet to summarise the page, the agent fetched the user's email address, requested a login code, read the code from Gmail and posted both back to Reddit. Brave reported it on 25 July 2025 and published on 20 August, later adding that Perplexity had still not fully mitigated the attack class.

Brave, screenshots, October 2025. The second Brave disclosure hid faint light blue text on a yellow background. A user-initiated screenshot passed that text to the model without separating it from the user's query. Brave reported it on 1 October and published on 21 October 2025.

LayerX, CometJacking, October 2025. LayerX showed that a single crafted URL could carry the instruction in its query string. A collection parameter steered the agent to its memory and connected services, such as Gmail and Calendar, rather than the web. Encoding the output in base64 got it past Perplexity's exfiltration checks. LayerX reported on 27 August 2025, and Perplexity marked the report "Not Applicable".

Zenity, local files, March 2026. A calendar invitation carried hidden instructions that walked the agent to a file:// path, read a credentials file, and sent its contents to an attacker URL as a query parameter. The page load was the exfiltration.

Zenity, 1Password, March 2026. The same delivery route sent the agent into the 1Password web vault while the extension was open, which it is by default for up to eight hours. In a second phase the agent changed the account password and extracted the Secret Key.

The Comet Enterprise control-by-attack checklist

For each attack, the question is narrow. Which documented control, set correctly, removes the payoff? A control that only records the attack after the fact does not count as stopping it.

Brave's Gmail code theft: stopped by No Access on mail

The attack needs two things: read access to Gmail and write access to Reddit. Setting mail.google.com to No Access breaks the first. Setting Reddit to Read Only breaks the second. Turning off "Always Allow" adds a prompt before the post, which helps only if the user reads it.

One detail in Brave's write-up deserves a test before you rely on the domain list. The agent reached a login page through perplexity.ai., with a trailing dot, specifically to slip past an existing authentication check. Perplexity's permissions page does not say how domains are matched.

Brave's screenshot injection: partly covered

No documented control stops the injected text reaching the model when a user takes a screenshot. The Chromium DisableScreenshots policy exists in Comet's policy list, but nothing in the documentation confirms it governs the assistant's own capture path. The domain rules still limit where a hijacked agent can act next.

CometJacking: the connector gap

This is the weakest mapping. CometJacking reached Gmail and Calendar through connectors and memory, not by browsing those sites. The Assistant permissions page governs domains and browser actions. It says nothing about connectors or memory, so a No Access rule on mail.google.com may not cover connector reads. Exfiltration still required the agent to send data out, which turning off browser control should prevent.

Zenity's file:// attack: fixed by the vendor, not the admin

Perplexity's fix was a hard boundary in code: the agent can no longer open file:// URLs, although the user still can. No admin setting produced that outcome, and the first fix was bypassed within 4 days using view-source:file://. A Chromium URLBlocklist entry for file://* is worth adding as a second layer, though we have not seen it tested against the agent.

Zenity's 1Password takeover: stopped by No Access on the vault

Zenity's own write-up says blocking the agent on the password manager's domain "would have prevented the entire attack". It also notes the block was not enabled by default. Perplexity's admin console moves that decision from each user's settings to the organisation, which is the real upgrade Comet Enterprise offers here.

Domain permissions are the Comet Enterprise control that does the work

Strip the matrix down and one pattern remains. The controls that work are the ones that decide where the agent may act. Prompt approvals, telemetry and security partnerships all sit around that core.

The useful mental shift is to set domain rules by where the damage lands, not where the poisoned content comes from. You cannot list every page that might carry an injection. You can list the dozen domains where an agent acting on your behalf would be a disaster: email, password managers, payroll, banking, cloud consoles and your identity provider.

Why Read Only is not a safe default for untrusted sites

Read Only stops the agent clicking or typing on a domain. It does not stop the agent reading that domain, and reading is how every one of the five attacks began. A Reddit thread set to Read Only can still hand the agent an instruction, which it then carries to whichever domain allows Browser Control.

So Read Only belongs on sites where action would be harmful but content is trusted, such as an internal wiki. For sensitive destinations, No Access is the only setting that matches the threat. We would put every credential store and every inbox on No Access before the pilot starts, and give them back only on a written business case.

The precedence rule that can quietly reopen a site

Perplexity's documentation states that domain-specific settings "override the global assistant permissions". That cuts both ways. It is what makes an allowlist possible: turn browser control off globally, then grant Browser Control to the few domains the pilot needs.

It also means a single broad grant can reopen everything beneath it. The documentation does not say whether a rule for a parent domain covers its subdomains, whether wildcards work, or how a trailing dot is handled. Until Perplexity publishes the matching rules, test each grant against the subdomains that hold your mail and credentials. Brave's trailing-dot trick shows why that test is not paranoia.

This is the same least-privilege logic that applies to any agent identity, set out in the case for treating agents as non-human identities. The browser makes it harder because the agent inherits every session the user is already signed into, which is the problem explored in the comparison of agent credentials and user impersonation.

Where the CrowdStrike Falcon layer fits in Comet security

CrowdStrike and Perplexity announced the Falcon integration for Comet Enterprise on 11 March 2026. The CrowdStrike release describes opt-in detection, governance and data protection, aimed at web threats, data movement and unmanaged devices. It builds on CrowdStrike's acquisition of Seraphic, a browser runtime security company.

The same release cites CrowdStrike's 2026 Global Threat Report finding that 82% of detections in 2025 were malware-free. That number is the honest frame for this section. None of the five Comet attacks used malware. Each one used ordinary page loads, ordinary form posts and the user's own sessions.

Falcon could still help at the edges. Data protection policies may catch a credential file leaving the device, and visibility on unmanaged devices matters if staff install Comet at home. What no public document shows is Falcon detecting a prompt injection itself, or blocking an agent action that a domain rule allowed. Until someone publishes that test, treat Falcon as a complement to the domain policy, not a substitute.

It is also a separate purchase decision. If your estate does not already run Falcon, the integration is not a reason to start, and the controls that matter most cost nothing beyond the Comet licence.

The Comet audit log tier: who gets a record of agent actions

The Audit Logs article was updated on 28 April 2026. Its eligibility line is precise: logs are "exclusive to Enterprise Organizations with 50 seats or more, or with at least one Enterprise Max user". The same page suggests that smaller organisations upgrade one seat to Enterprise Max.

The log itself is reasonably designed. Events stream in real time to an HTTPS webhook you control, with formatting for Slack and Splunk. Every event carries a timestamp, user email, IP address and user agent. There is a comet_agent_action event type, described only as "Comet agent performed an automated action".

Telemetry is not an audit log

Below the threshold, the organisation-level view is Comet telemetry. Its documented fields are device and configuration data: user email, device ID, browser version, extension count, policy count, operating system and whether personal search is enabled. Nothing in it records a prompt, a page the agent visited, or an action it took.

That matters because the record is what lets you answer the question after an incident. Which accounts did the agent touch, and on whose instruction? A 30-seat team without an Enterprise Max seat cannot answer it from Perplexity's side at all. Our view is that the action log belongs in every tier, because an agent that acts without a record is a liability regardless of how many seats sit behind it.

Even above the threshold, check what comet_agent_action actually carries before you rely on it. The help page publishes no metadata schema for it and no retry behaviour for failed webhook deliveries. Compare it against the fields set out in the 12-field specification for agent audit logs, and log a sample action in a test tenant before the pilot.

Where this checklist is weakest

The first limitation is method. This is a reading of Perplexity's documentation against researchers' disclosures, not a red-team exercise against a live tenant. A control documented as working may behave differently in practice, and a gap we name may already be closed in code that the documentation does not describe.

The second is that the attack record is a lagging indicator. All five disclosures predate Comet Enterprise, and Perplexity has shipped fixes since, including the hard file:// boundary and stricter confirmation prompts. Mapping controls to old attacks rewards the vendor for fixing what was public and says little about what has not been found yet.

The third cuts against our own stance on prompts. We rate "Always Allow" off as only partial protection because users approve prompts out of habit. Brave and Zenity both recommend requiring user interaction for sensitive actions, and they have studied this more closely than we have. A prompt that names the target domain may be read more often than we assume.

Finally, the strongest competing view is Gartner's. Its December 2025 advisory, reported by The Register, told security leaders to block AI browsers until enterprise-ready versions reached general availability. Comet Enterprise arguably meets that bar now. If your team cannot staff the domain policy and the log review described here, Gartner's position still wins, and blocking the browser is the cheaper and safer option.

Frequently asked questions

Where to start: one afternoon in the admin console

Open Assistant Permissions and write down what is set today, before you change anything. If "Always Allow" is enabled and the domain list is empty, every attack in this post is still available to anyone who can get text in front of your users' agents.

Then build the No Access list from the table above, starting with webmail and your password manager, and test one grant against its subdomains. If you are under 50 seats, decide this week whether the $285 a month for an action log is worth paying, because the answer after an incident is always yes. For teams already juggling several assistants, the governance comparison of ChatGPT, Claude and Gemini enterprise tiers shows how the other vendors gate the same record.

Related reading