Security

How the platform is built to protect your keys, your spend and your data — and how to reach us about a vulnerability.

API keys

• Hashed at rest. Keys are stored only as a SHA-256 hash, never in plaintext. A database compromise does not expose usable, credit-bearing keys.
• Fingerprinted in logs. Logs contain only a short, non-reversible fingerprint of the key, never the key itself.
• Bearer transport. Keys travel as Authorization: Bearer … over TLS. Treat a key like a password — never commit it or ship it in client-side code.
• Rotation. Create, revoke and reissue keys anytime from the dashboard. Revocation stops billing immediately.

Scoped keys (least privilege)

Limit the blast radius of any single key:

• Allowed models / kinds — restrict a key to specific models or endpoint types.
• Spend caps — daily and monthly USD ceilings, enforced before each call.
• TPM — a tokens-per-minute limit per key.
• Rate limit — every key is capped at 100 requests/minute.

See Limits, caps & scopes. A leaked scoped key can do far less damage than an unscoped one — use a separate, tightly-scoped key per service.

Data handling

• Zero prompt retention — only model/token/cost metadata is stored, never prompt or response content. See Data & privacy.
• Prompts are forwarded to the upstream provider serving the call; choose models accordingly for sensitive data.

Payment integrity

Payment-gateway webhooks (Razorpay / PayPal) are verified with a constant-time signature comparison, so the expected signature can’t be discovered through response-timing analysis.

Input handling

Prompts are treated as data — including code. Sanitisation removes only NUL bytes; it does not strip code characters, so it cannot be used to smuggle anything past the provider. The upstream model and the request-size limits are the real safeguards.

Reporting a vulnerability

Please do not include real third-party data or run denial-of-service tests against production. Use your own account and minimal, synthetic payloads.