Local-first AI security. Why none of your data leaves your Mac.

Vigil's defense layer runs on the user's Mac. The TLS proxy intercepts traffic locally. The detection ensemble processes feature vectors locally. The policy engine evaluates actions locally. The audit chain is written to the local disk. The Chrome extension sends nothing to a server. There is no cloud component that holds user content. There is no off-machine telemetry stream that contains cleartext.

This is not a privacy posture. It is the architecture. The product would not work any other way, and several of the structural advantages that distinguish Vigil from cloud-based AI security depend on the architecture staying this way. This post explains the reasoning, the implementation specifics, and the constraints that follow from the choice.

Privacy by configuration is a promise. Privacy by architecture is a property. The two are not the same thing, and only one survives a determined adversary.

Why local-first is not a marketing decision

The conventional pattern for AI security products is cloud-hosted analysis with on-device collectors. The collectors capture user activity, send it to the cloud, and the analysis runs on the vendor's infrastructure. This pattern dominates because it produces three commercial advantages: the vendor accumulates a useful corpus of user behavior across customers, the analysis can use larger models than fit on user devices, and the operational cost is amortized across the customer base.

The pattern has three structural problems for the AI defense category specifically.

Problem one: the cloud component is a target. A vendor's centralized cleartext store of customer AI activity is a high-value target. Compromise of the vendor compromises every customer. The conventional mitigation is rigorous operational security at the vendor, which is necessary but not sufficient. The structural mitigation is to not have the centralized store at all.

Problem two: the customer cannot independently verify what the vendor sees. Cloud-hosted analysis produces a trust dependency: the customer trusts the vendor to handle their data appropriately. Trust is a reasonable thing for vendors to ask for and customers to extend, but it is not the same as architectural impossibility. A customer who wants the property "no one outside my organization can see my AI activity" cannot get that property from a cloud-hosted vendor. They can get a contractual promise. They cannot get a structural guarantee.

Problem three: the regulatory exposure of the cleartext store grows monotonically. Every customer interaction adds to the corpus. Every regulatory inquiry, lawful intercept request, or government data demand applies to the corpus. A vendor with a centralized cleartext store carries an exposure that compounds over time and that they cannot fully control.

Local-first architecture eliminates all three problems by structure. There is no centralized store to compromise, to verify against, or to be served. The customer's data stays on their machine.

What runs locally, specifically

The full processing pipeline:

The TLS proxy is a Rust process that runs on the user's Mac. It listens on a local port. The Mac's network configuration routes AI provider traffic through the proxy. The proxy terminates the upstream TLS connection, processes the request, and re-originates it on the upstream side. The processing happens in the proxy's memory. The processed bytes are written to the upstream connection. The processed bytes are also fed to the analysis pipeline, which runs in a separate thread of the same process.

The analysis pipeline runs the four-model detection ensemble, the action decomposition, and the policy engine. All four detection models are loaded from disk at startup and run inference locally. The Isolation Forest, LSTM, and Bayesian models are small enough to fit in memory comfortably on consumer hardware. The CUSUM is a deterministic algorithm with no model weights. None of the inference makes network calls.

The Chrome extension is a JavaScript bundle that runs inside the browser's content script context. It captures DOM events that the proxy cannot see (because the proxy operates at the network layer and some interactions happen entirely in the browser's local state). The extension sends what it captures to the local proxy, on the same machine, over a local socket. There is no path from the extension to a remote server.

The audit chain is written to a SQLite database in the user's home directory, in a directory protected by Mac file permissions. The chain entries are signed by a key that lives in the Mac's keychain. The verifier reads the chain from disk and confirms each entry's signature against the user's public key. The verifier is a separate binary that the user can run independently of the rest of Vigil.

The dashboard is a Tauri app that renders a local web view. The view fetches data from the local proxy's localhost API. The dashboard makes no remote calls.

What does leave the machine

Three classes of data leave the machine, all small, all opt-in, all documented.

Crash reports if the user opts into crash reporting at install time. The reports are anonymized. They contain no user content. They contain stack traces and process state at the time of crash. The default is opt-in disabled.

Telemetry pings if the user opts into telemetry. The pings are aggregate counters: number of requests processed, average latency, model warm status. No content. No request bodies. No response bodies. The default is opt-in disabled.

Update checks to confirm the running build is current. The check is a request to our update endpoint with the current version number. The endpoint returns the latest version number. No user data is included.

That is the complete list. There is nothing else. We will not add anything else without versioning the privacy disclosure and giving every user the explicit option to remain on the previous version. The architecture stays local-first.

What this enables that cloud-first does not

A short list, in order of importance.

Lawful intercept resilience. Vigil cannot turn over user content in response to a subpoena, because we do not have the content. The user has the content. A subpoena directed at Vigil produces nothing useful. A subpoena directed at the user is the appropriate venue for compelled disclosure, with the protections users in any given jurisdiction have for that scenario.

Cryptographic audit ownership. The user owns the chain. The verification key is local. A regulator examining the chain authenticates against the user's key, not against a vendor's. The chain outlives Vigil if Vigil shuts down tomorrow. The user's audit is intact regardless of our continued existence.

No cross-customer correlation surface. Some cloud-based AI security products advertise "learning from threats observed across customers." This is a real benefit when it works and a real liability when it leaks. We do not have this benefit, by structure. We also do not have the liability. Each customer's data stays on their machine. There is no aggregate corpus that an attacker, regulator, or compromised employee could access.

Future-proof against personal model fine-tuning. The local audit chain accumulates over time into a corpus that the user can fine-tune a personal model on, without surrendering the corpus to a cloud provider. VOAF-M is the format that makes this practical. Cloud-first architectures cannot offer this property without inventing complex zero-knowledge schemes that they do not currently have.

The constraints that follow

Local-first is not free. The constraints are real.

We cannot ship a feature that depends on cross-customer pattern recognition. We can ship a per-user model that learns from the user's own chain. We cannot ship a model that learns from everyone's chains together. The category of features that work this way is closed to us. We are not pretending it is not.

We cannot offer cloud-hosted dashboards. The dashboard runs locally. Enterprise customers who want a centralized view across their workforce get it through Gateway, which aggregates audit chain summaries with the customer's explicit configuration. The summaries are on the customer's infrastructure, not on ours.

We cannot run analysis that requires hardware larger than the user's machine. Detection runs in real-time on Apple Silicon at acceptable latency. Future model upgrades are constrained by what fits on consumer hardware. We are willing to live with this constraint because the alternative architecture requires giving up the local-first property, which we are not willing to do.

We cannot ship a feature that secretly does something we said we would not. The architecture is auditable. The source is open enough that a determined customer can verify our claims. The build is reproducible. The sum of these properties means that if we ever did add an off-machine telemetry path, customers would be able to detect it. The constraint is enforceable from outside our company, not just inside it.

Why this matters more than it looks

The local-first decision was the first architectural decision we made, before we wrote any code. Once it was made, every subsequent decision was either consistent with it or rejected because of it. The product that exists today is the version that survived this filter.

I think this filter is the right filter for the AI defense category. The structural argument for an independent defense layer (which I have written about in the founding thesis post) extends to a structural argument for a local-first one. Both arguments end in the same place: the user's data should be inspectable by the defense layer, but the defense layer should not be able to take the data anywhere else, even if it wanted to. Architecture, not policy, is what produces this property.

If you are building a competing product in this space, my advice is to make this decision early. Local-first is hard to retrofit. It is much easier to build the system this way from the start than to graduate from cloud-first to local-first later. We did it from the start. We are glad we did. Most of what makes the product defensible against an enterprise security review traces back to this one constraint.

That is why the data does not leave your Mac. Not because we promised. Because the architecture has no path that lets it.