Why Vigil exists. The founding thesis, two months in.

I started Vigil two months ago. This post is the thesis I wrote down for myself before I started, edited by what the last sixty days have taught me. If you are evaluating Vigil as a customer, an investor, a partner, or a regulator, this is the post that tells you what we are doing and why we think the rest of the world will eventually agree.

The thesis is one sentence.

The defense layer for AI agents cannot be operated by the entities that ship the AI, and the audit format for what those agents do cannot depend on trusting any provider, including us.

Everything else is mechanics. The mechanics are the hard part. The thesis is the easy part.

If the thesis is correct, the question is who builds the layer first. If the thesis is wrong, we will not be the only people to find that out.

How I got here

I have started four companies. Three were acquired. One shut down. Before this, I was running Pivotal AI, a personal recall search engine that turned into an enterprise product and was acquired in 2024. Before that, I was an early employee at Skyscanner during the years it scaled from a small flight comparison site to one hundred million monthly users. Before that, the standard run through Dell, HP, Accenture, IBM. The pattern of my career is that I have been close to enterprise infrastructure during three transitions: the cloud transition, the mobile transition, and now the AI transition.

Each of these transitions had a defining structural question that the early players got wrong, and that the eventual winners got right. For cloud, the question was whether infrastructure should be owned or rented. The early answer was owned. The right answer turned out to be rented, with structured cost control. For mobile, the question was whether software should be installed or accessed. The early answer was installed. The right answer turned out to be accessed, with native APIs as a complement.

For AI, the question is whether the defense layer should sit inside the provider or outside. The early answer is inside. The early answer is wrong.

I have spent enough time in regulated industries to know the structural reasons it is wrong. Self-regulation is the default for emerging industries, and self-regulation has a documented failure pattern, and I do not want to be one of the people who watched it happen and did not build the alternative.

So here we are.

What the structural problem actually is

I will not repeat the full argument here. Marek wrote it up in detail. The short version is that AI providers earn revenue per token of inference, which creates a permanent commercial tension with any safety function they operate internally. The safety function does not have to fail. It just has to lose enough arguments, on a long enough timeline, for the structural problem to assert itself. This pattern is not specific to AI. It is the pattern of every consumer industry of consequence in the last hundred years.

The second piece of the structural problem is that no single AI provider can see what a user does across the other providers. A user today runs Claude in the morning, Cursor at lunch, ChatGPT in the afternoon. Their workflow is composed across all three. Compromise in one surface affects the others. No provider can see the composed workflow. To see it, they would have to abandon their privileged position in their own model's request path, which they will not do. So cross-provider visibility cannot come from any provider. It has to come from outside.

The third piece is that audit trails operated by the entity being audited are not audit trails. They are publication. A regulator examining an incident six months later cannot independently verify what occurred without trusting the operator's good-faith forensics. In every other industry that handles consequential outputs, this is solved structurally: cryptographic audit chains, third-party verification, regulated separation of issuer and auditor. AI is the early stage of the same arc.

These three structural facts compose into a single architectural conclusion. The AI defense layer has to operate outside the providers, see across the providers, and produce audit data that any third party can verify without trusting the operator.

There is exactly one architectural pattern that satisfies all three. Local-first interception, on the user's machine, with cryptographically verifiable audit chains that the user owns and the provider does not see.

That is what Vigil is.

What we are building

The product is technical, but the components are easy to describe.

A TLS proxy that runs on the user's Mac and intercepts traffic to AI providers. The interception is local-only. Nothing leaves the machine that the user did not already send to the provider. The proxy decomposes each request and response into structured form, which the rest of the system operates on.

A statistical detection layer that runs four models in ensemble against the structured traffic. The detection is probabilistic. Its output is a tier signal indicating how anomalous the session looks. The detection is intentionally separate from the enforcement layer because LLMs in enforcement paths are themselves prompt-injectable, and a defense product that ships an injectable defense is shipping a vulnerability as a feature.

A deterministic policy engine that evaluates the agent's actions, pre-execution, against the user's authorized capabilities and a configurable rule set. This is the Execution Gate. It holds high-consequence actions until the user confirms, blocks unconditionally prohibited actions, and passes through routine actions with sub-millisecond overhead.

A cryptographic audit chain that records every action, signed by a local key, with the chain hash linking entries. The chain is verifiable by any third party, including the user, without trusting Vigil's continued operation. The verifier is open source.

An identity layer (TAP) that handles agent attestation and authority chains. A revocation layer (VARP) that propagates kill-switch events across counterparties in under a second. An audit standard (VOAF) that the chain conforms to, published as an open spec.

That is the system, in five paragraphs. The implementation is harder than the description. The architecture is the easy part. Making it work without unacceptable latency, false positive rates, or user friction is the hard part.

What we are not building

This is the part of the thesis I have rewritten three times in two months.

We are not building an AI provider. We have no model. We will never have a model. The structural separation requires it.

We are not building a SOC replacement. Enterprise security operations centers are real things with real workflows, and the right place for Vigil's output is feeding into them, not replacing them.

We are not building a generic logging product. Logging is not audit. The cryptographic chain is the entire point of the audit layer. A product that produces logs that the operator can edit is not the same product, even if the description sounds similar.

We are not building consumer surveillance. The architecture is local-first specifically because the user's data should not leave their machine. We do not see the data. We do not want to. The product works precisely because we have given up the ability to monetize the data, and that constraint is structural to the category.

We are not building for the moment that exists. We are building for the moment that arrives in eighteen to thirty-six months, when the first systemic AI agent failure forces the regulatory framework that the industry should have built voluntarily. By the time that framework arrives, we want to be the entity that has been operating in the gap for long enough to have credibility. That timeline drives most of our prioritization.

What we have learned in two months

A few things I did not know at the start.

The technical work is not the hardest part. The technical work is hard, but it is well-bounded. The hardest part is positioning the product clearly enough that prospects, partners, and regulators understand what we are doing without first having to absorb a five-paragraph structural argument about AI provider conflicts of interest. We are getting better at this. The blog is part of how we are getting better.

Latency is the entire product. If the proxy adds noticeable latency to a user's AI requests, the user disables it. Once disabled, the product produces zero value. This means the latency budget is not a tradeoff against features. It is a constraint that determines whether anyone actually leaves the proxy on. We have built the architecture around this from the start. Most of our engineering review hours go to it.

The audit layer is the differentiator that buyers ask about last and value most. Every prospect we have talked to has asked about detection first. Most of them have asked about enforcement second. The audit chain came up third or fourth. By the end of the conversation, the audit chain was the thing they remembered. This is consistent with how regulated industries work in general: the audit trail is what survives the eventual incident.

The market does not yet exist in the form we are addressing. Cybersecurity buyers know they need something for AI. They are not yet sure what category that something is. We are partly building the product. We are partly building the category.

What I am asking the people reading this

If you are a builder thinking about this space, build complementary things. The category is wide. We are addressing one architecture. Other architectures will turn out to matter. We would rather see the category populated than be the only ones in it.

If you are an enterprise considering AI deployment, ask harder questions about the audit and revocation primitives of whatever you deploy. The AI provider's safety claims are real but partial. They do not cover the structural questions, which is not a failing of the providers. It is a property of where they sit.

If you are a regulator, the time to engage with structural separation is now, before the framework gets written by lobbyists for the entities the framework is supposed to constrain. Our NIST RFI response is one input. There are many others worth your time.

If you are a researcher with relevant work, send me a note. We read everything. The reading list for this product is long, and most of the most useful papers are not in security venues. They are in cryptography, distributed systems, and applied econometrics.

If you are someone who has watched this transition before, in a different industry, your pattern recognition is more useful than ours. Tell us what you saw the last time. We will listen.

The thesis is the easy part. The product is hard. The category is open. We are two months in, and the work continues.