Virgil → Trust & security

Where your record lives

You're deciding whether to put real work - maybe your whole client book - into a memory built by a small company. That decision deserves specifics, not a badge wall. This page is the specifics: where the record sits, what's encrypted, how records are kept apart, what delete actually does, and how you leave. Everything here describes the product as built. Where something is a gap, it says so.

The short version

• Your record lives in a database on a dedicated customer engine in the United States - a separate machine from our own operations.
• Every hop is TLS. The engine's disks are encrypted at rest.
• Isolation is enforced in the database, not just the app: your rows are sealed to your credential.
• Saving and recall run zero LLM. No model reads your record in the serving path, and nothing trains on it.
• Forget a fact and it's retired on the spot. Ask, and the whole record closes.
• The whole record exports anytime as memvelope - open format, plain JSON, readable without Virgil.
• No SOC 2 yet. We say so, and we show you the walls instead.

Who holds what

The record itself - your facts, pages, and their history - lives in a Postgres database on an engine that exists for customer records and nothing else. Our own working systems run on a different machine entirely; customer data never shares a box with operations. The engine is backed up nightly, with daily disk snapshots on top, so a crash restores your record to the most recent nightly backup - the last day, not the exact moment it stopped. Only an export or a deletion takes your record out for good.

The full list of companies whose infrastructure touches your data, and what each one holds:

• AWS Runs the customer engine where the record lives, in the United States. Disks encrypted.
• Cloudflare Runs the connection layer your AI apps talk to. Holds your registry entry, your credential bundle, and short-lived working data - like an export waiting for pickup. Encrypts stored data at rest.
• GitHub Holds each record's private repository of working files, created at setup. Private, one per record.
• Stripe Payments. Checkout happens on Stripe's pages - your card details never touch Virgil.
• Resend Delivers Virgil's email: pickup codes, briefs.
• ZeroEntropy Turns each saved fact into a search vector so recall can find it later. Sees the fact text once, at save. An embedding model, not a chat model - it cannot summarize, answer, or rewrite anything.
• OpenRouter Import only - the one-time distillation pass described below. Not in the serving path.

That's the whole list - every company whose infrastructure touches your record. None of them profiles you, and no ad tech sits anywhere in that path. The website is a separate matter, and an ordinary one: virgilknows.com measures which pages get read, and our setup pages embed a walkthrough video and a hosted web font. None of that reaches your record, and none of it is what this page is about.

Encryption

In transit: every hop is TLS - from your AI app to Virgil, from Virgil to the engine, and to every provider above. There is no plaintext leg.

At rest: the engine's disks are encrypted with AWS-managed keys, and Cloudflare encrypts stored data at rest. Credentials get a second layer: your record's client secret is stored sealed - encrypted, and opened only at the moment Virgil mints your record's own engine token. Your export passphrase is stored only as a hash - Virgil can't show it back to anyone, including you.

What we don't claim: end-to-end encryption. Virgil's job is to hand the right piece of your record to whichever model you're talking to, which means the engine has to read the record to serve it. A memory service that answers recall on the server can't also be end-to-end encrypted - so we don't claim it.

Sealed to you

Isolation here isn't a policy document. It's how the system is built.

• Virgil fails closed. A request that doesn't resolve to a known record is refused before it reaches anything. There is no default account to fall into.
• Every record has its own credential. Each one gets its own client with a sealed secret - encrypted, opened only to mint that record's own token - and every call to the engine rides that token, never a shared service account.
• The database enforces the seal. Row-level security scopes every read and write to the record it belongs to. The database itself refuses to show your rows to anyone else - even if a bug upstream were to ask.
• Exports inherit it. Your export is assembled under your own credential, so the file is structurally incapable of containing another record's rows.

Walls between clients

For work with real confidentiality lines - a client book, deal work - Virgil Pro adds walls inside your own record. A lens fences one client or project. Inside Client A's lens, Client B doesn't leak: if an answer would need Client B's material, Virgil refuses and says so, instead of quietly blending the two. Lenses and their walls are a Pro feature - on Core, your record is one open room.

We treat the wall as the product's hardest promise, so it gets the harshest testing we know how to run: adversarial rounds whose only job is to breach it. When a round finds a crack - and rounds have - the fix lands with a test written red first: it fails against the unfixed code, so we have watched it catch the bug before we trusted it. The wall's failure mode is refusal, not leakage: malformed state reads as empty, never as someone else's rows.

No wall is beyond breach, ours included. The claims we'll stand behind are narrower and true: it's enforced in code rather than by etiquette, it fails closed, and we attack it ourselves before you rely on it.

What runs on your record

No model summarizes, answers from, or rewrites your record. When Virgil stores a fact or hands one back, it moves as plain data. That is structural rather than a policy: on the customer plane the tools that could reach a chat model are never registered at all.

Two deliberate exceptions, both disclosed. Saving a fact sends its text once to ZeroEntropy, which turns it into a search vector so recall can find it later - an embedding model, so it cannot summarize, answer, or rewrite. And bulk import: when you import years of chat history, a one-time distillation pass uses a model (Mistral, via OpenRouter) to turn that text into dated facts. It reads the imported text once, at import, and is never in the loop again.

That is the whole of it. The thinking rides your ship, not ours - Virgil carries no inference bill, so it has no reason to grow one.

And the standing rules: Virgil trains no models on your record, and nothing you store is sold or shared. You pay for Virgil - that's the whole business. There's no ad model and no data business behind it.

Who at Indistinct can see your record

The first question a careful buyer asks a memory company: can the people who run it read what I store? Straight answer, in three parts.

• The admin surface can't serve your record. The operator routes that exist provision records, reissue sign-in codes, seat plans, and read signup-funnel timestamps. None of them return facts, notes, or messages - there is no admin screen that shows record content.
• Two break-glass paths exist, and we name them. Whoever administers the engine can read its database directly - true of any hosted service that isn't end-to-end encrypted, ours included. And the support tool that reissues a sign-in code grants the same access your own AI has - it exists so you can get back in, and it would work in our hands too. Both are treated as break-glass: touched for support you asked for, never routine, never for browsing.
• No end-to-end encryption means trust is the honest frame. As above - the engine has to read your record to serve it. So we don't ask you to believe access is impossible. We show you it's structurally narrow, disclosed, and off the routine path - and the exit stays open if that's not enough.

Delete

A fact: tell Virgil to forget it, and it's retired on the spot - dated, no longer surfaced. The record keeps a dated trail of what changed rather than pretending it never happened; that trail is what makes the record auditable. Deleted notes stay recoverable for 72 hours in case you change your mind.

The whole record: reply to any email Virgil has sent you and ask. We close the record completely. Today that's a request a human handles, not a button.

Leave anytime

The whole record exports as memvelope - an open format we steward in the open. The file is plain JSON: every fact with its source, its date, and its full revision history, active and superseded rows both. It reads in a text editor without Virgil, and it re-imports through our own front door.

The pickup takes two proofs: a one-time code to your verified email, and a passphrase only you know. The download link is single-use. The full walkthrough is in the export doc.

Export anytime, including the day Virgil turns the lights off. Ownership you can't test at the exit isn't ownership.

And if something happens to the one person running Indistinct: a sealed continuity kit puts a designated person in a position to notify every customer, hold the engine up for 90 days, refund unused time, and get everyone their export.

What we don't have

No SOC 2. No ISO 27001. Those audits measure an organization's processes over time, and we're early and small - a fast-tracked badge at this size would tell you less than this page does. When certification becomes the honest spend, we'll do it for real.

What stands in for it today is structure, not paperwork: the seal lives in the database, the refusal lives in code, and the tests that guard both run on every change. The surface is deliberately small - one engine, a short list of providers, no trackers. And the exit stays open on your own terms: you can export your whole record yourself, anytime, in a format that reads without us, so leaving never waits on our goodwill. Closing a whole record is still a request a human handles today, not a button.

We'd rather show you walls than badges.

Questions

Ask us anything about this page - reply to any email Virgil has sent you, and a human answers. Broader questions start at the FAQ.