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 keeps point-in-time recovery on, so a crash restores your record - only an export or a deletion moves it out.

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.
• OpenRouter Import only - the one-time distillation pass described below. Not in the serving path.

That's the whole list. No analytics vendors, no ad tech - this site runs no third-party trackers at all.

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 that fails without it, and mutation checks prove the tests actually bite. 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.

No model reads your record

Saving and recall run zero LLM. When Virgil stores a fact or hands one back, it moves as plain data - no model reads, summarizes, or "improves" your record in the serving path. That's not a promise buried in a policy - the product's own tests pin it.

One deliberate exception, disclosed: 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.

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 is always open: export and deletion don't depend on our goodwill, or on our still being in business.

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.