Security posture, without inflated claims.
LatentKit sits between your application and AI providers, so it holds credentials and sees requests. This is exactly how both are handled, and what we don't claim yet.
- 1You add a provider keyIn the console, once.
- 2Checked with the providerBefore it's stored.
- 3Encrypted in a vaultWrite-only. Never shown again.
- 4Used server-sideOnly to run your requests. Never logged.
Credentials
Keys go in. They don't come back out.
Provider keys
Stored encrypted in Supabase Vault. The connection record keeps only a reference. Keys are never logged or displayed after saving, and they are scrubbed from provider error messages.
LatentKit API keys
Random secrets shown once and stored only as a SHA-256 hash. Revoking or rotating one clears it from the edge cache, so it stops working at once.
Server-side use
The gateway decrypts a provider key only to run an authorized request. LatentKit is not a zero-knowledge credential manager, and we don't describe it as one.
Request data
You choose what gets kept.
Logs are what make routing debuggable. Workspace admins decide how much of each request they hold.
Default
Request metadata plus request and response content, with personal data scrubbed and long fields trimmed.
Strict zero retention
Metadata only: route version, model, attempts, latency, tokens, and cost. No prompt or response content, and no response caching.
PII scrubbing
Emails, phone numbers, card numbers, and SSNs are redacted from stored logs and traces. Strict mode also catches API keys.
Guardrails
Substring or regex rules block or redact prompts and responses. Response rules don't apply to streamed replies.
Export and erase
Admins can export workspace data as JSON or erase stored request data at any time.
What providers see
Scrubbing applies to what LatentKit stores. The request itself goes to the provider your route chose.
Operations
How the platform itself is run.
Least privilege
LatentKit staff work in separate viewer, operator, and administrator roles, and the operations console sits behind Cloudflare Access.
Two-person approval
Large credit adjustments and plan grants need a second administrator. Nobody can approve their own request, and approvals expire if unused.
Providers start switched off
A new provider must pass a live test and a separate approval before it can serve traffic or be offered through Platform Access.
Fail-closed media fetching
Remote image and audio URLs are fetched over HTTPS from approved domains only, with private and metadata addresses blocked and size, redirect, and time limits enforced.
Locked-down data
Database tables use row-level security and are reachable only by the backend's service role.
Checked dependencies
Every build runs dependency and container scans before it ships.
Billing integrity
Money math you can trust.
The parts of the system that touch your credits are built to fail safe.
- Exact decimal pricing, rounded once when usage is recorded, so costs can't drift.
- Held, then settled: credits are reserved before a Platform Access request and settled after it.
- No blind retries: a timed-out request is never resent to the same provider, which may already have accepted it.
- Deduplicated payments: Stripe events are processed once, with alerts for anything stuck.
What we don't claim
Said plainly.
- No compliance certifications yet. We'll list SOC 2 or ISO only once they are actually held.
- No single sign-on yet. Members sign in with email and password, Google, or GitHub.
- One hosted service. LatentKit is multi-tenant; there is no on-premises or single-tenant version.
Disclosure
Found something?
Send suspected vulnerabilities, credential exposure, account abuse, or billing issues to security@latentkit.com with enough detail to reproduce them. Please don't access, change, or destroy data that isn't yours.
Email security