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.

• Access is invite-only. Creating an account requires a valid invite code, including when signing up with Google or GitHub.
• 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 an 8-digit code valid for fifteen 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:

• There is no per-account request rate limit. Spend is bounded by the credit balance, not by request rate.
• 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 an invite-only preview, not a service with an uptime commitment.