Security & Trust

Version 1.0.0 · Effective April 14, 2026

QuotaKit helps developers cap their AI API spend. This page explains what we protect, what remains your responsibility, the sub-processors we rely on, and how to report a security issue to us.

What QuotaKit is and isn't

QuotaKit is a secondary failsafe for runaway AI spend. You instrument your application with our SDK, which reports usage to our ingest API in near-real time. We enforce per-customer quotas and spend caps, reject further usage once limits are hit, and surface alerts.

QuotaKit is not a replacement for your provider's controls

Our enforcement runs alongsidethe spend controls your AI provider offers (e.g. OpenAI's usage limits, Anthropic's monthly spend caps, your cloud billing alerts) — not instead of them. Enable every budget control your provider gives you and treat QuotaKit as one layer in a defense-in-depth stack.

Shared responsibility

QuotaKit is responsible for

Enforcing the quotas and spend caps you configure, as defined in our Terms of Service and SLA.
Keeping your account data, usage records, and API keys secured (see “How we protect data” below).
Operating our dashboard and ingest API against published uptime targets.
Notifying you of security incidents that affect your data in line with our breach-notification obligations under applicable law and the Data Processing Agreement.

You are responsible for

Accurate reporting.QuotaKit enforces based on the usage your application reports. If your integration under-reports cost, mis-maps a path, or silently fails to call the SDK, QuotaKit cannot block spend it doesn't know about.
Provider-side controls.Keep your AI provider's native budget limits enabled. Our quotas are an emergency failsafe, not a guaranteed upper bound on provider charges.
Account hygiene. Protect your dashboard login and API keys. Rotate keys if you suspect compromise. Use scoped keys where possible.
Configuration accuracy. Spend caps, quota thresholds, and alert recipients are values you enter. If mistyped or stale, enforcement will follow what you entered.
Use the right mode. Open-mode records only. Block/strict reject further usage on our side — but only after a reporting round-trip (see below).

Plain-English liability note

QuotaKit is not liable for spend that occurs because your application misreported, failed to report, or bypassed the SDK entirely. Block- and strict-mode are best-effort real-time enforcement; they are not a contractual guarantee that your AI provider bill will never exceed your configured cap. The authoritative limits on your provider account (OpenAI, Anthropic, Google, etc.) remain your responsibility to configure and maintain. See the Terms of Service for the full liability limitation.

Race windows and enforcement semantics

Because QuotaKit enforces based on post-hoc usage reports, there's a small window between when your application spends money and when QuotaKit observes that spend. During this window, additional calls may be allowed even though you are already over your cap. The window size depends on the enforcement mode you pick:

Open

Race window

No enforcement

We record every call but never block. Use when you only want visibility.

Block

Race window

Seconds (batch interval)

After the next SDK flush, usage is counted and future calls reject.

Strict

Race window

≤ reservation TTL (max 900s)

A reservation is acquired before spend. Smaller race window, tighter enforcement.

How we protect data

Data we store

Your account email and authentication records (Supabase-managed).
Your API keys, stored only as SHA-256 hashes — we never store the raw key.
Usage records: per-call cost, token counts, path, service, model.
Billing metadata: plan tier, period, Stripe customer ID.
Alerts you configure and the history of alerts we've sent.

Data we do NOT store

Prompt or response content. The SDK only reports metadata (tokens, cost, timestamps). We never see request contents.
End-user data from your application. Keep end-user identifiers out of path names and quota labels.
Payment card data. Stripe handles all card data. We only receive a customer ID and subscription status.

Controls

Encryption at rest & in transit

AES-256 via Supabase at rest; TLS 1.2+ on every network hop.

Row-Level Security on every customer-scoped table

Queries only return data for the authenticated customer ID.

Hashed API keys, never logged

SHA-256 before storage. Raw key never appears in logs or Sentry.

Minimal employee access

Currently one operator. Audit logs on any direct database access.

Sentry scrubbers

Passwords and Authorization headers are stripped before events leave the service.

Sub-processors

QuotaKit uses the following sub-processors. Each stores a specific slice of data and is contractually bound to handle it per our DPA.

Provider	Purpose	Region
Supabase	Postgres database, authentication	us-east-1 (AWS)
Vercel	Dashboard hosting, edge CDN	Global
Railway	Ingest API compute	us-east4 (GCP)
Upstash	Redis cache / rate-limiter	us-east-1 (AWS)
Stripe	Payment processing, billing	US
SendGrid	Transactional email (alerts, billing notifications)	US
Cloudflare	DNS, edge proxy	Global
Sentry	Error monitoring (scrubbed)	US

Material changes to this list (adding a new sub-processor, or changing data residency) are announced in the changelog and, for customers who opt in to notifications, by email.