Security
Transport, keys, isolation, and how to report a problem.
Transport
TLS 1.2 or higher, HTTPS enforced, HSTS with a long max age. Plain HTTP is refused rather than redirected for API paths, so a misconfigured client fails loudly instead of leaking a key in cleartext.
Keys
Keys are bearer credentials. The practical rules:
- One key per project, per environment and per person. Shared keys make an incident unattributable and a revocation expensive.
- A budget on every key that runs unattended.
- Revoke anything you cannot account for, and rotate on a schedule for long-lived deployments.
- Never in a repository, never in a client-side bundle, never in a screenshot.
Keys are checked on every request, and a revoked key stops working immediately rather than at the end of a cache window.
Isolation
Every request is attributed to the key that made it, and per-key limits are enforced at the gateway rather than in the client. On reserved deployments the endpoint is separated per customer, with private addressing rather than a shared hostname.
Pinning and reproducibility
Serving a fixed set of weights is the point: an evaluation you run today and repeat next week meets the same model. Where a deployment needs it in writing, reproducibility by hash is part of the reserved agreement.
Incident response
We tell affected customers what happened, what was exposed, and what to rotate. If a key may have been exposed, assume it was and rotate it; a key that has never leaked costs nothing to replace.
Reporting
Send security reports to the contact address on the main site, with enough detail to reproduce. We will confirm receipt, and we will not pursue anyone who reports in good faith and does not exfiltrate data to prove a point.