On-device classification, explained.

Why on-device, not cloud

The obvious cloud-classifier design would have the browser extension forward every prompt to a Northbeams API, run a model server-side, and return a verdict. That design is wrong for three reasons.

Blast radius. If we never receive prompt content, a Northbeams compromise cannot leak prompts. Prompt content is the most sensitive thing your team types into AI tools. Storing it would make Northbeams a high-value target. Not storing it makes us a low-value target.

Latency. A 50-person team types into an AI tool roughly 4,000 times a day. Adding a network round-trip to every keystroke window would be felt by the user, and would push Northbeams toward batching, which loses precision. Local classification finishes in single-digit milliseconds and does not slow the page.

Cost and incentive alignment. Server-side classification scales linearly with the number of prompts. On-device classification scales linearly with the number of seats. The seat-based pricing model lines up with the seat-based cost structure, so we do not have a hidden incentive to weaken classification to save inference dollars.

What runs in your browser

The Northbeams browser extension is a Manifest V3 Chrome extension that runs three things on the device:

1. A tool-visit detector. A background service worker matches the active tab's hostname against the bundled catalogue of recognized AI tools (chat.openai.com, claude.ai, gemini.google.com, and so on). When there is a match, it records the hostname, page title (truncated to 80 characters), tool identifier, and timestamp.
2. A prompt classifier. A content script attaches a submit-event listener to recognized prompt input fields on supported AI tool sites. When the user submits, the script reads the text, runs a deterministic pattern-match classifier across roughly 40 sensitive-content categories (credentials, customer PII, source code, contracts, financial records, regulated health and education data), and produces a verdict structure: which categories matched, how many patterns inside each category fired, and a redacted snippet.
3. A redactor. Before any snippet leaves the page, secrets are masked: API tokens become [REDACTED:apiKey], email addresses become [REDACTED:email], and so on. The redactor uses the same regex set as the classifier, so a secret that triggered a match is the same secret that gets masked.

The classifier itself is a regex-and-rule engine, not a model. We chose this deliberately. A model in a content script costs you 5 to 50 MB of WASM at install time and adds variance to every page-load. A 200 KB rule engine evaluates in 2 ms and fits inside the extension bundle.

What runs on your Mac and PC

The desktop app for Mac and PC does a different job. It does not watch what the user types, because there is no sane way to do that without becoming a keylogger. Instead, it watches two signals the OS already exposes:

Process events

A short list of recognized AI desktop apps and CLI tools (Claude Desktop, ChatGPT Desktop, Cursor, Granola, claude, aider) is matched against running process names. When one of these processes starts, the desktop app records the process name, the matched tool identifier, the user label, and a timestamp.

The full command line is not recorded. claude --resume some/path is captured as claude, which is what the dashboard shows. Anything you type after that, including file paths and prompts passed via flags, is invisible to Northbeams.

Outbound connection events

The desktop app reads outbound TCP and TLS connection metadata from the OS networking stack. When the laptop opens a connection to a hostname in the bundled AI service catalogue (currently 21 hosts, refreshed quarterly), the app records the destination hostname, the matched tool identifier, the originating process name, and a timestamp.

It does not read the contents of those connections. There is no proxy, no MITM certificate, no DNS rewrite. The connection still goes wherever it was going to go, encrypted, and Northbeams just notes that it happened.

What runs for the CLI

"CLI" is not a separate install. The desktop app already watches process events on the laptop, and the recognized-tools list includes coding agents like claude, aider, and similar. So the same install that catches Cursor running as a desktop app also catches Claude Code running in your terminal.

This matters because coding agents are the channel through which source code most often leaks. A developer who types claude "refactor this auth module" is sending the contents of that module to Anthropic, often without realizing it. Northbeams cannot stop that submission, and it cannot read the prompt or the response. What it does is record that claude ran, and how often. That alone tells the IT lead that coding-agent traffic is a category they need a policy for.

What gets sent to the dashboard

Both surfaces send the same shape of event to the dashboard's ingestion endpoint:

{
  "surface": "browser" | "desktop",
  "tool_id": "chatgpt-web",
  "tool_kind": "browser_chat" | "desktop_app" | "cli_agent",
  "event_type": "tool_visit" | "sensitive_finding" | "process_seen" | "connection_seen",
  "categories": ["credentials", "sourceCode"],
  "match_counts": { "apiKey": 2, "privateKey": 1 },
  "redacted_snippet": "...curl -H 'Authorization: Bearer [REDACTED:apiKey]'...",
  "user_label": "alice",
  "workspace_id": "ws_19f...",
  "timestamp": "2026-05-08T14:22:11Z"
}

Three fields are worth calling out:

• redacted_snippet is at most 200 characters and is the only piece of "content-shaped" data the dashboard ever sees. It exists so an admin can tell a real finding from a false positive at a glance.
• user_label is configured by the user. On the free Beam tier this is anonymous (every event is attributed to the workspace, not to a person). On Lighthouse and Sentinel it is set to the SSO email or a chosen alias.
• workspace_id is the only identifier that ties events to a customer. We do not collect device serial numbers, MAC addresses, or OS account names.

What we deliberately do not do

A short list, because the absence of these is the point:

• No prompt content leaves the device. Not the original text, not a hash of the original text, not a vector embedding of the original text. The dashboard never receives anything from which the prompt can be reconstructed.
• No keystroke logging. The browser extension reads the prompt only at submit time, from the input field's value, the same way the AI tool itself reads it. There is no global key listener.
• No screen capture. Neither the extension nor the desktop app takes screenshots, reads window contents, or uses accessibility APIs to scrape on-screen text.
• No clipboard reading. The desktop app does not have clipboard permission. The browser extension reads only the prompt input element, not the clipboard.
• No browsing history outside AI tools. The extension only fires on hostnames in the recognized-AI-tools list. It does not see your bank, your email, or your internal apps.
• No network proxy and no TLS interception. The desktop app does not install a root certificate. Connection contents stay encrypted end-to-end between your laptop and the AI host.
• No model training on customer data. The classifier is a regex-and-rule engine, not a model, so there is nothing to train. We also do not train any other model on customer data, full stop.

How precision and recall work in a rule engine

We chose a rule engine over a model because rules are debuggable. When a finding fires, the dashboard can show you exactly which pattern matched, on which substring, with what context. When a finding does not fire on something it should have, you can grep the rules for the missing case and add it. Models are great at fuzzy categories ("does this look like an angry email?"). Rules are great at sharp categories ("is there a Stripe live key in this string?"). Sensitive-content categories are sharp.

The current rule set has roughly 220 patterns across 40 categories. About 60% of the patterns are deterministic (Stripe live keys, AWS access keys, JWTs, RSA private keys, credit-card numbers in PAN format with Luhn check). The remaining 40% are heuristic but bounded (PII patterns like "my SSN is X" with a numeric Luhn, source-code patterns like a function definition followed by an obvious secret variable name). Each pattern carries a confidence score; the dashboard shows confidence so admins can triage triagee mode at low confidence and block at high confidence.

What changes when we ship the model-assist tier

The roadmap includes a "model-assist" tier that runs a small classification model in the browser via WebAssembly. It will not replace the rule engine. It will run alongside it, giving a second-opinion verdict on cases the rules call low-confidence. The model will be small (under 5 MB compressed), will run fully on-device, and will be off by default. We will publish the model card and the training-data provenance before we ship it. Subscribe to the changelog to be on the list when that lands.

FAQ

Does Northbeams send my prompts to a server?

No. The browser extension classifies prompt text locally inside the browser via a content script. The original text never leaves the device. Only category labels, per-pattern match counts, and a redacted snippet are transmitted to the dashboard.

Does the desktop app see my prompts?

No. The Northbeams desktop apps for Mac and PC never inspect prompt content, keystrokes, screen contents, or file contents. They watch outbound connection metadata (which AI hosts your laptop talks to) and process names (which AI desktop apps and CLI tools are running).

Why run classification on the device instead of in the cloud?

Three reasons. Blast radius (a Northbeams compromise cannot leak prompts because we never have them). Latency (no round-trip on every prompt). Cost-and-incentive alignment (we are not tempted to weaken classification to save inference dollars).

Does Northbeams act as a network proxy or install a TLS interception certificate?

No. No proxy, no MITM certificate, no DNS rewrite, no on-prem appliance. The desktop app reads outbound connection metadata from the OS networking stack, which gives us the destination hostname and the originating process. It cannot read connection contents.

What does Northbeams do with the redacted snippet?

The redacted snippet is at most 200 characters with detected secrets replaced by [REDACTED:type] tokens. It is shown to the workspace admin so they can decide whether the finding is a real risk or a false positive. It is retained for 365 days by default. Workspace owners can request shorter retention by email to privacy@northbeams.com.

Can I block Northbeams from collecting sensitive-content findings entirely?

Yes. In the browser extension, right-click the toolbar icon, open Options, and uncheck "Detect when sensitive content is pasted into AI tools." Tool-visit detection (the lighter check that records which AI tools are open) continues unless you uninstall the extension. The desktop app never inspects content, so there is no equivalent toggle on Mac or PC; quit the menu-bar or system-tray app to pause it.

How is this different from a DLP product?

Traditional DLP intercepts traffic at a network choke point (a proxy, a CASB, a network appliance) and inspects connection contents using a TLS interception certificate. That model assumes there is a choke point, which is broken in a distributed-laptop world, and it requires you to put a vendor in the middle of every TLS handshake. Northbeams runs on the endpoint, classifies before the network, and never needs to see encrypted traffic.

← Resources Coverage scorecard Why Northbeams Features Pricing Contact What's new