All posts

What on-device inference actually costs you

Running detection in the browser instead of a server has real privacy and latency advantages — and real limits on model size and accuracy. Both sides, honestly.

PromptSec Engineering3 min read
Share:

We run prompt detection in the browser rather than on a server. That decision buys some genuine things and costs some genuine things, and vendors are usually vague about the second half. Here's both.

What it buys

Prompt content doesn't leave the machine. This is the big one, and for a security product it's close to existential. A tool that inspects every prompt your staff writes is a tool that could become the largest single collection of your company's sensitive text. Running detection locally means we never hold that. It isn't a policy commitment we're asking you to trust — it's an architectural property.

No latency in the typing path. A server round trip on every prompt would add 50–200ms depending on where the user is. Local regex and heuristics complete in single-digit milliseconds. The person notices nothing, which matters more than it sounds: a security control people notice is a security control people work around.

It works offline and on any network. No dependency on our uptime for the enforcement path. If our control plane is down, detection keeps running — telemetry queues, policy stays whatever it last was, and nobody is blocked.

No per-prompt inference cost. Server-side inference on every prompt across a fleet is a per-seat cost that scales with usage. On-device, that's zero, which is why per-user pricing works at mid-market levels.

What it costs

Model size is bounded by what you can ship. A browser extension that downloads a multi-gigabyte model is not deployable. Realistically you're looking at a quantised model in the tens of megabytes — which means a small distilled transformer, not a frontier model. Small models are meaningfully worse at nuance than large ones. Anyone claiming frontier-quality classification purely on-device is describing something else.

Compute is the user's, and it varies enormously. A developer's workstation and a five-year-old shared machine in a branch office are both "the fleet". Inference has to be fast on the slow one, which caps sequence length and model complexity further.

Updates ship at extension-release cadence. A server-side model can be swapped in an afternoon. A client-side one propagates as fast as your browser fleet updates. For a threat landscape that moves weekly, that's a real disadvantage.

Everything is inspectable by the adversary. The detection logic runs on the attacker's machine if the attacker is an insider. They can read the patterns and craft around them. Server-side detection at least keeps the rules opaque.

How we split the difference

The pipeline is layered so that each layer runs only when cheaper ones haven't settled the question.

Normalisation and regex handle structured identifiers — emails, card numbers, AWS keys. These are exactly the cases where deterministic matching beats a model: a Luhn check is more accurate about credit card numbers than any classifier, and it's free.

Heuristics handle known attack shapes: instruction override, injection carriers, encoding evasion.

The ML layer exists for the genuinely ambiguous residue. It's implemented, tested, and currently disabled, because we don't have a model we're willing to stand behind. Shipping a classifier that returns a plausible-looking constant would be worse than shipping nothing — it would manufacture confidence that isn't there.

Optional cloud escalation is the release valve. For the small tail of prompts local layers can't resolve, you can enable a call to a hosted model. It's off by default, it fails open, and when it's on, that ambiguous content does go to the provider. That's the trade, stated plainly so you can decide whether it's one you want.

The general principle

Put the deterministic work where it's cheap and private. Reserve the expensive, uncertain work for the cases that actually need it, and let the customer decide whether it leaves the machine.

The failure mode we're most trying to avoid isn't a missed detection. It's a control that adds enough friction, or enough perceived surveillance, that people route around it. Local-first is partly a privacy argument and partly a much more boring one: it's the version people leave installed.

Design Partner Program

See what your own team is sending to AI — free for 30 days.

PromptSec is taking on 3–5 Indian teams as design partners: the full product, up to 50 seats, and a direct line to the founders. See the terms.

Apply now