Security

When your app calls your provider through Vigil, three things pass through the proxy for the length of that one request:

• —Your request: the prompt, the messages, the tool definitions, everything your app sent.
• —Your provider API key, in the same header your app put it in. Vigil forwards it to the provider and does not write it down (section 4).
• —The provider's response, including a streamed one, on its way back to your app.

The proxy runs on Cloudflare's edge network. It reads the request in memory to count tokens, work out the cost, find the part of the prompt a provider could cache, and, when you have switched an optimisation on, make the change that optimisation describes: cache markers, a shorter history, or a different model from the same provider. It reads the response in memory to count the tokens the provider billed and to look for personal data and prompt-injection patterns it can warn you about. The finding is recorded. The text it was found in is not.

Vigil's own headers (X-Vigil-Key, X-Vigil-Agent) are removed before the request is forwarded, so the provider sees the request your app made, with any optimisation you turned on applied. The one exception is Bedrock with an AWS signature: a Vigil header your signature covers is left in place so the signature stays valid, but X-Vigil-Key is removed even then. Everything travels over TLS; the proxy refuses plain HTTP.

From each call, one row in a database. It holds:

• —How many tokens went in and out, including cache reads and cache writes.
• —What the call cost, in US dollars, and what it would have cost without Vigil’s changes where that can be worked out.
• —How long it took, in milliseconds.
• —The model and provider names, the path you called (for example v1/messages), and whether the call succeeded.
• —If it failed: the provider’s error code from a fixed list (for example authentication_error), and a one-sentence reason in Vigil’s own words from a fixed list. Never the provider’s message, which can quote your prompt.
• —The agent name from your X-Vigil-Agent header, the time, and the request id Vigil returned to you.
• —Short fingerprints of the prompt’s shape: 8-character checksums of the system prompt and the tool order, and an estimated length. They say whether two calls share a prefix. They cannot be turned back into text.
• —A short one-way fingerprint of the provider credential the request carried, which can’t be turned back into the key, so one key’s cache is kept apart from another’s (section 4).
• —The names of any problems Vigil’s detectors found on the call, such as pii_leak or cost_spike. The name only, never the evidence.

The full column list, group by group, is section 4 of the Privacy Policy. The Connect page shows the short version of this section above the setup steps.

• —Your prompt text, apart from the tool names and timestamp excerpt in section 2.
• —Your message content.
• —The model’s responses.
• —Your tool call arguments, your tool results, and your tool schemas or descriptions.
• —The text of a provider’s error message.
• —Your provider API key (section 4).

Prompt and response bodies are never written to disk, by the proxy or by the dashboard. That is what bounds a database compromise: the rows described in section 2, not your users' conversations.

Your provider key (Anthropic, OpenAI, Google and the rest) is never stored. It arrives in your request, is forwarded to the provider in the same header, and is gone when the request ends. What a call record can hold is a short one-way fingerprint that can't be turned back into your key, used only to keep one credential's cache apart from another's. It is not encryption: someone who already had your key could confirm it matches, and the same key always gives the same fingerprint. On Google Vertex AI the record holds your Google Cloud project id and location in clear instead; on Bedrock, the AWS region sits beside the fingerprint.

Your Vigil key is stored as a SHA-256 digest. It is shown once, when you create it, and cannot be recovered. If you lose one, revoke it in API Keys and create another.

A habit worth having: create a separate provider key for the agents you route through Vigil, with its own spend limit at the provider. You can revoke it at any time without touching your other keys.

• —Your account, your call records and everything in section 2 are stored by Supabase in Central EU (Frankfurt) (eu-central-1). Data at rest is in the EU.
• —The proxy runs on Cloudflare’s global edge network, so a request is processed at whichever location is closest to the machine making the call, and forwarded to the provider you chose, wherever that provider runs. Processing is not EU-only.
• —The dashboard runs on Vercel. Its server functions run in Frankfurt; Vercel’s edge network is global.
• —Account emails are sent by Resend, in the United States. Payments are handled by Stripe. Card details never touch Vigil’s servers.

The sub-processor list, with each one's role and transfer basis, is section 6 of the Data Processing Addendum.

Two controls in Settings work today, immediately, on demand:

• —Delete all data clears your call and error history, including the scores you sent for calls, and keeps your account open. It does not reset your monthly usage meter, which only ever counts up within a billing period.
• —Delete account removes your account and, with it, your calls, errors, API keys, preferences, alert rules, team invitations and usage counters.

Two kinds of record outlive an account deletion: billing records, which Dutch law requires us to keep, and the sign-in entries in our database provider's service logs, for as long as that provider keeps them. If either deletion stops partway, it tells you exactly what was removed and what was not.

Automatic retention: As of 6 October 2026, automatic deletion isn’t active yet: nothing has been deleted under these windows on any plan. It starts with the new plans. Refused-request records are the exception: they are deleted once they are seven days old. Until the windows are enforced, the two controls above are how data leaves.

• —Every table is protected by row-level security keyed to your account: a signed-in customer can read, change or delete only their own rows, and the dashboard reads through that same gate. On 9 October 2026 we tested this from a second account against every table and every database function the dashboard can call. Nothing crossed.
• —The proxy writes with a server-side key that never reaches a browser. The dashboard’s client bundle was checked for every server secret on the same day; none is in it.
• —Vigil’s own logs hold status codes, counts and error messages from its own code: no API keys, no headers, no request or response bodies. There is no third-party error-tracking service.

Connecting an app to Vigil is a base URL and two headers. To undo it, remove the base URL. Your calls go direct to the provider again, with the same key, and nothing else changes. Revoking your Vigil key in API Keys has the same effect from the Vigil side: calls that still carry it are refused, not forwarded.

If you find a security problem, email sam@vigil.wtf. The same address is published at /.well-known/security.txt. We will answer with what we found and what we changed; we do not promise a response time we cannot keep.