Protection
How Veqen catches stolen keys and spend nobody on your team made, what each rule means, how to read an incident, shut a key off, file a refund claim, and get overcharges back.
Protection compares what each provider reports, key by key and hour by hour, with what your code, your gateway and your people actually did. Spend nobody on your team made opens an incident with the reason, owners, admins and security members hear about it, and the key can be shut off from the alert. It comes with every paid plan; on Free, the free audit reads the last 30 days once a month.
What Veqen reads
Connect each provider's billing with a read-only admin key under Settings › Connections. What a provider reports decides which rules can run, and the integrations page shows it for each one:
- Usage per key by the hour (OpenAI, Anthropic, Fireworks, fal and Baseten today): every rule below runs.
- Running totals or only the key list: the rules about the keys themselves run, so a key unused for 30 days, one whose owner left, or one open to any API is still caught.
- The bill alone: spend and the bill check, without per-key rules.
On paid plans the per-key usage is read every fifteen minutes. Providers report an hour from a few minutes to about an hour after it ends.
Your own calls, matched by key
Calls your code makes through the SDK carry the last four characters of the provider key they used, never the key itself: a wrapped client sends its own key's hint, and record() takes provider_key. Veqen matches each key's billed hours with the tracked calls that carry its hint, so spend no call explains stands out. It waits two hours for tracked calls to arrive before it judges an hour this way, which is why a key with no SDK traffic is flagged only by the rules below. OpenTelemetry spans carry no key hint.
The rules
| Rule | What it means |
|---|---|
| A key nobody used for 30 days was used | A dormant key woke up. It stays suspect until a person settles its incident. |
| A key whose owner has left was used | The key's owner left your directory, and the key is still spending. |
| A model the key has never run | Stolen keys are usually spent on models their owners never use, often image and video models. |
| Spend far above the key's usual hour | A runaway agent, a loop, or someone else's traffic. |
| Spend at an hour of the day the key is never used | A key whose traffic keeps to the working day, spending at night. Only keys whose last two weeks leave at least eight hours of the day quiet are judged this way. |
| Spend no tracked call explains | The provider billed hours your SDK calls with that key's hint don't account for. |
| A model keys stolen at other companies ran | Pooled from confirmed incidents at other organizations that share them (see below). |
Reading an incident
Findings that belong together become one incident: a possible stolen key, unexplained spend, runaway spend, unusual spend, or an overcharge. An incident about a stolen key absorbs every later hit on that key. The incident page shows the reasons, the hours it covers with what the provider reported against what your code made, the key and its owner, every action taken, and its claims.
Owners, admins and security members get an alert by email, and in Slack and your webhook where they're set up, within minutes of the flag. An open incident alerts again when it grows to ten times its last alert, or after a day. Slack's Shut off key and This was us buttons open the incident with that confirmation ready; nothing acts until a person confirms it in Veqen.
Settle an incident as resolved, or as expected ("this was us"), which keeps that key's rules quiet for a week. Shutting its key off moves it to contained.
Shut-off access
Reading never changes anything. To shut keys off from Veqen, add a separate credential for each provider under Settings › Protection. Veqen checks it with a harmless read, encrypts it, never shows it again, and uses it only to turn a key off or back on. Owners, admins and security members can use it; Veqen's support staff can't.
- Providers that can only delete keys (OpenAI, fal, Baseten, the Vercel AI Gateway, Deepgram and xAI): Veqen asks before each one, and never deletes by policy.
- Two-person shut-off: turn it on under Settings › Protection, and a second owner, admin or security member confirms each shut-off within a day.
- Automatic shut-off: only the two rules that are almost never wrong, a dormant key waking up and a departed owner's key spending, can shut a key off by themselves, only where the provider can turn it back on, and only when you choose that for the rule. Set a rule to a dry run first, and each incident it fires on notes once when the policy would have shut the key off, without touching it or needing shut-off access.
- Turning it back on: from Keys or the incident, at providers that support it, on any plan.
Without shut-off access, the incident says where to do it in the provider's console.
Refund claims
Start a claim from the incident. Evidence on the incident lays out what a provider's refund process asks for: the key, every action on it and any key made since in the same project, and hour by hour what the provider billed for the key against what your own code made, over the incident and the day before. Print it or save it as a PDF, or download the same rows as CSV. Send it with your request through the provider's support, then mark the claim submitted, and credited with what the provider gave back, or denied. A credited claim becomes a credit in Provider credits from the day you record it, which the month-end close counts against spend from then on.
Overcharges
Wherever a provider reports both its bill and its usage per key, Veqen prices the usage at the provider's own rate card, cache, batch, long-context and priority rules included, and compares it with what it billed for the same day and model. It looks at the last week of whole days every hour, so a bill that lands late is still checked. A model's day billed at least $10 above its usage, and at least 10% above it, counts, and a provider's overcharged days become an overcharge incident with the model-by-model evidence for a claim.
Pooled patterns
With Settings › Protection › share patterns on, a confirmed stolen key adds the models it first ran during the incident to a pool other companies are warned with. Only public model names in the price book are shared, kept under a keyed hash of your organization, and a model counts once two companies have confirmed it.
Without the dashboard
GET /v1/incidents, GET /v1/incidents/{id}, POST /v1/incidents/{id}/settle, claims, GET /v1/provider-keys and POST /v1/provider-keys/{id}/shut-off are in the API reference. Over MCP, assistants can list and read incidents and keys, but no tool shuts a key off.