Security

• Keys are 32 bytes from a cryptographic RNG, prefixed knot_live_. They are shown once, at creation, and never again.
• Only a SHA-256 hash is stored. A database dump does not let anyone spend your credit. There is no recovery path for a lost key — you mint a new one.
• Revocation is immediate. Requests authenticate against a short-lived in-process cache, so a revoked key stops working within seconds rather than at the end of any session.

• Upstream provider credentials are encrypted at rest with AES-256-GCM before they are written. GCM is authenticated, so a tampered ciphertext fails to decrypt rather than silently yielding a wrong credential.
• They are write-only from the interface: no query in the application returns a provider credential, including for administrators.

• Anyone can create an account. A new one is credited $5 once its email address is confirmed, and one bonus is paid per inbox rather than per address — plus tags and Gmail dots are normalised away. Beyond that balance nothing is free: the gateway refuses any request from a non-positive balance, and API keys cannot be minted before an account has been funded.
• Administrator is not self-assignable. No mutation in the application writes the role field; it is set out-of-band, so a compromised session cannot escalate itself.
• Sign-in and password reset never reveal whether an address is registered. That difference would be a way to enumerate who has an account.
• Password reset uses a 10-digit code valid for ten minutes, delivered by email — not a link, which would leak through browser history and link previews.

• Per request: the model, the capacity slot that served it, token counts, latency, status, and the computed cost. Prompt and completion content is never stored.
• Every movement of credit is an immutable ledger entry. Balances are derived from it and can be recomputed from scratch, so a disputed charge is answerable.
• Requests are subject to the content filtering configured on the upstream provider.

Send a report through the contact listed in /.well-known/security.txt. Include the steps to reproduce and what you were able to reach.

Please do not run automated scanners against the gateway, do not access or modify another account’s data, and give us a chance to fix an issue before disclosing it. Good-faith research reported this way is welcome, and we will not pursue action over it.

Stated plainly, because a security page that lists only strengths is not a security page:

• Requests are rate limited per key, in two places. An in-process token bucket allows 120 a minute with a burst of 40 and costs no round trip, which is what actually catches a runaway retry loop. Behind it a counter in the database caps 240 a minute across every server instance. The first is a guardrail rather than a boundary — it is per instance — and the second is the real cap.
• A balance is checked before a request and charged after it, so the final request on an account can overshoot slightly into a negative balance. It is recorded; the next request is refused.
• This is a preview, not a service with an uptime commitment.