Browsers Are Shipping On-Device AI: What It Means for Text You Type at Work

In June 2026 Microsoft expanded the on-device AI models and APIs available to web developers in Edge, including a small instruct model aimed at summarization, rewriting, and intent handling, exposed to pages through browser APIs. Chrome has been shipping comparable built-in model APIs.

The pitch is reasonable: a web page can offer AI features without the site operator paying for inference or seeing your input, because the model runs in your browser on your machine.

For anyone who writes at work, this is a genuine improvement and also a new source of ambiguity, because “AI in the browser” now covers two architectures with opposite privacy properties and no visual difference between them.

Two Things That Look Identical

On-device. The page calls a browser API, the browser runs a small model locally, the text never leaves your machine. The site operator sees nothing.

Server-side, in a page. The page sends your text to the site’s backend, which calls a model provider, and returns the result. Your text has been transmitted to at least two companies.

From the user’s side these are the same experience: you type, you click a button, better text appears. There is no indicator, no permission prompt in most flows, and no obligation on the site to tell you which one it used.

That ambiguity is the practical problem. Every argument about AI privacy in a browser depends on which of these is happening, and the interface does not say.

The Rule That Actually Protects You

Do not try to determine the architecture. Assume anything you type into a web page has been transmitted, and decide based on that.

This sounds unhelpfully conservative and it is the only rule that survives contact with real browsing. You cannot inspect a site’s implementation, the implementation can change between visits, and a page that runs a model locally today can add a server-side fallback tomorrow without telling you.

The corollary: for text that would matter if it leaked, use an application whose behavior you can verify rather than a web page whose behavior you cannot. That is not a browser-specific point. It is the same reasoning behind is it safe to paste work emails into ChatGPT, applied to a surface where the ambiguity is worse.

Where This Genuinely Helps

Two places, and they are real.

Low-stakes text on sites you do not control. A comment, a form, a support message. On-device summarization or rewriting here is a small win with a small downside, and if the site implemented it locally, you got a free improvement.

Reducing the number of vendors. Historically a site adding AI features meant your text went to the site plus a model provider plus whatever subprocessors sat between. A browser-native model removes those hops when it is used. That is a structural reduction in exposure, even if you cannot verify it case by case.

Neither of those changes the calculation for the confidential paragraph in your client email. That text should not be in a browser text box on a third-party site regardless of what the browser can do locally.

Browser Extensions Are The Bigger Exposure

While on-device model APIs get the attention, the more common failure in practice is the extension.

Security reporting through 2026 has repeatedly found large fractions of enterprise users running unapproved AI browser extensions, many of which read page content by design. An extension with permission to read and modify all pages has broader access than a page-level model API ever will, and its data handling is governed by whatever its developer wrote in a policy nobody read.

If you are auditing AI exposure in an organization, the extension inventory is a higher-yield place to look than the browser’s model APIs. There is more on that surface in AI browser agents and your clipboard and shadow AI in the workplace.

The Question To Ask

For any AI feature, in a browser or an application, one question does most of the work:

During this operation, is a network request made, and what does it contain?

That is answerable, verifiable, and not satisfied by “we take privacy seriously”. A vendor that runs inference locally can say so precisely. A vendor that does not will produce a paragraph about encryption instead, which answers a different question.

Encryption in transit protects text from interception. It does not stop the recipient from having it. Those get conflated constantly and the conflation is usually the point.

Writing The Policy Line

If you are drafting an AI policy for a team, browser AI needs one sentence and most policies do not have it.

Before:

Employees should be careful when using AI tools and avoid sharing confidential information.

After:

Client-confidential text may be entered only into approved applications running an on-device model. It may not be entered into a web page, a browser AI feature, or a browser extension, because we cannot verify where a page sends it.

Non-confidential text may be entered into any approved tool.

The second version is enforceable because it names the surface and gives a reason. “Be careful” is not a rule, and people who are trying to comply cannot apply it.

A Wrivio Context for policy drafting could say:

Rewrite this as a clear internal policy statement. Neutral register, complete sentences. Each rule must name the surface it applies to and be enforceable as written. Keep every system name and category exactly as written. Do not add vague guidance such as “be careful” or “use good judgment”, and do not soften a prohibition into a recommendation.

Press Ctrl+Shift+Space, paste the draft, and check the diff. The specific thing to watch for is a rewrite converting “may not” into “should avoid”, which quietly turns a rule into advice. There is more on the shape of a workable policy in how to write an AI use policy for a small team.

Common Questions

If a browser runs the model locally, is my text private?

For that operation, yes: it does not leave your machine. The problem is you usually cannot tell whether a given page used the local API or sent your text to its own backend.

Should I use browser AI features for work email?

For low-stakes text, it is fine. For anything client-confidential, use an application whose local behavior you can verify rather than a web page whose behavior you cannot.

Are AI browser extensions riskier than built-in browser AI?

Generally yes. An extension with permission to read all pages has far broader access than a page-level model API, and its data handling depends entirely on the developer.

How do I check what an AI feature does with my text?

Ask whether a network request is made during the operation and what it contains. That question has a factual answer, unlike “is it secure”.

Download Wrivio for Windows to rewrite in an overlay over any application, with a local mode that makes no network call during the rewrite.