Mozilla's *Firefox Enterprise* lets companies block shadow AI in the browser

The problem with shadow AI

Someone in marketing pastes a draft press release into ChatGPT to tidy it up. A credit analyst feeds a customer summary into Claude to write the internal memo faster. A developer asks Copilot to review a snippet of code. Each of them saves a few minutes. None of them told IT.

That's shadow AI, and it has quietly become one of the harder problems in data governance. The tools are useful, the employees are trying to do their jobs well, and the risk is invisible until someone asks what data left the building and whether the AI's answer became the company's decision.

Mozilla's new Firefox Enterprise platform is a blunt answer to that problem. IT teams can now block employees' access to AI tools through the browser, decide which tools are allowed and limit what data those tools may see. The platform ties browser activity to existing security monitoring, so an attempt to reach a blocked service shows up in the logs.

What the platform does

Firefox Enterprise sits between the browser and the web. Administrators set policies centrally—block this tool, allow that one, redact sensitive fields before they leave the browser—and Firefox enforces them across the workforce. The policy engine can recognise personal data, contract terms and confidential material and stop them being pasted into a prompt.

The platform connects to identity and access management systems, so permissions follow the user rather than the device. A finance team member who is allowed to use an approved AI tool at the desk shouldn't be able to use it at home, and the policy can say so. Browser activity feeds into the organisation's security information and event management (SIEM) systems, where it joins the rest of the audit trail.

How it compares with a toaster

Blocking something is like unplugging the toaster: it stops the thing happening, but it doesn't tell you what happened before you pulled the plug. A prompt that went out last week is still out there, and so is the answer. The model's provider has the conversation in its logs, the employee might have a screenshot, and the organisation has neither.

That's the evidence gap. Blocking prevents new risks; it doesn't close old ones.

What this means for you

If your organisation is considering Firefox Enterprise or a similar platform, here are three questions to ask before you deploy it:

• What happens to data that already left? A policy that blocks ChatGPT today doesn't unsend yesterday's customer summary. Do you know what went out, and do you have a record of what came back?
• Can you show who asked what? If an auditor or a supervisor wants to know whether an AI tool influenced a lending decision, a personnel file or a customer interaction, can you produce the prompt and the response, with a timestamp that holds up?
• Who keeps the log of what was blocked? Firefox Enterprise will log attempts to reach blocked tools. Those logs are kept by the organisation, which means the organisation can edit them. Could you show an auditor or a regulator that a log entry from six months ago hasn't been touched since?

The AI Act and DORA

The AI Act doesn't ban employees using AI, but it does make organisations responsible for how they use it. If a high-risk system plays a role in a decision about a person—hiring, lending, immigration—Article 12 requires the organisation to log events over the system's lifetime ^[1]. From 2 December 2027, that duty applies to high-risk AI under Annex III ^[2].

A prompt to ChatGPT or Claude isn't itself a high-risk AI system, but the answer might feed into one. If the employee uses the AI's output in a decision the organisation makes, the organisation owns that decision. The log the AI Act asks for should show what happened. If the only record is a screenshot the employee kept, the organisation starts a dispute on the back foot.

For financial institutions, DORA adds another layer. The technical standard on ICT risk management requires logs to be protected against tampering, deletion and unauthorised access ^[3]. A log of who tried to reach which AI tool, and when, is part of that picture.

What a digital witness does here

This is a case where a digital witness handles part of the problem, not all of it.

Firefox Enterprise stops the prompt leaving in the first place, which is simpler than sealing it afterwards. But some organisations will decide to allow certain AI tools under controlled conditions, and in those cases a witness gives the organisation its own record.

The thing to seal is each browser interaction with an approved AI tool: the prompt the employee sent, the response the tool gave and the time. Sealing takes a fingerprint of the record, not the record itself, so the content never leaves the organisation's systems. The fingerprint is sealed on WitniumChain, where any later change would show.

If a regulator, an auditor or an affected person asks what the AI said and when, the organisation can produce the sealed record and show that it hasn't changed since it was captured. Anyone the organisation shares the record with can check the fingerprint themselves and see that it matches.

How it would work

1. The browser plugin or a logging layer captures each prompt and response as the employee interacts with the approved AI tool.
2. A fingerprint of the record is sealed via the REST API or the SDK, and a witness ID is returned.
3. When someone questions what the AI said, the organisation produces the sealed record, calculates the fingerprint again and shows that it matches.

What it doesn't do: it doesn't stop the employee using the tool, it doesn't prove the AI's answer was correct, and it doesn't seal interactions with tools the organisation doesn't know about. A witness seals what you give it; it can't seal shadow AI you haven't seen.

Get started with the REST API or the SDK. The first 2,000 witnesses a month are free.

What to watch

The AI Act's high-risk requirements for Annex III systems, including the logging duty in Article 12, apply from 2 December 2027 ^[2]. Organisations using AI in hiring, creditworthiness assessments or law enforcement should already be planning how they will log decisions and secure those logs.

DORA's technical standard on ICT risk has applied since 17 January 2025 ^[3]. Financial institutions should have logging policies in place that cover attempts to use unapproved tools, and those logs should be protected in a way an auditor can check.