Security
Security at Open LLMs
Open LLMs signs you in through Google, GitHub or an emailed one-time code, keeps API key secrets only as SHA-256 hashes and serves every request over TLS 1.2 or higher; it holds no security certification and has commissioned no independent audit.
- Sign-in
- Google, GitHub, or an emailed one-time code
- API keys
- Shown once, stored as a SHA-256 hash
- Transport
- TLS 1.2 or higher, HTTPS enforced
- Hosting
- AWS Asia Pacific (Mumbai), single region
- Certifications
- None held
What protects your account and your data?
Account access
Sign-in through Google, GitHub or an emailed code. No password exists to be stolen.
API keys
A 48-byte secret, shown once, stored as a hash, revocable in one click.
Data handling
TLS in transit, encrypted database and object storage, and one cache layer that is not encrypted.
Platform and network
Security-group-only database access, IAM-scoped secrets, role-gated admin routes.
How is your data encrypted?
| Row label | In transit | At rest | What sits on it |
|---|---|---|---|
| Between you and the API | Encrypted | Not applicable | Your requests and the responses we return |
| PostgreSQL database | Not enforced | Encrypted | Accounts, wallet balances, API key hashes, billing records |
| Object storage | Encrypted | Encrypted | Files you upload and files the platform generates |
| Cache and internal queue | Not encrypted | Not encrypted | Session identifiers, rate-limit counters, in-flight prompt and response text |
Warning:
One layer is not encrypted, and we would rather you heard it here
Session identifiers, rate-limit counters and the in-flight text of every prompt and response pass through a Valkey cache that has encryption switched off in transit and at rest. It runs inside our AWS network, accepts connections only from named security groups, and is shared with other workloads run by the same operator. The privacy policy sets out what happens to prompt text.
Which controls are in place, and which are not?
| Row label | In place | What that means |
|---|---|---|
| TLS 1.2 or higher on every request | In place | The load balancer terminates TLS on a policy that permits only TLS 1.2 and 1.3. Plain HTTP redirects to HTTPS. |
| Strict transport security | In place | Both the website and the API send a two-year Strict-Transport-Security header covering subdomains. |
| API key secrets hashed at rest | In place | Your key secret is 48 random bytes, shown once at creation and kept only as a SHA-256 hash. It cannot be read back afterwards, by you or by us. |
| Revoked, blocked and expired keys stop at the gateway | In place | Status, block flag and expiry are checked before a request reaches any model, and a failing key gets a 401. |
| Sign-in without passwords | In place | You sign in with Google, GitHub, or a six-digit code emailed to you. We store no password. |
| Hardened session cookies | In place | Session cookies are HttpOnly, Secure and SameSite=Lax, and expire after seven days. |
| Database encrypted at rest | In place | Encrypted with AWS-managed keys, not addressable from the internet, with seven days of automated backups. |
| Object storage encrypted and closed to the public | In place | Every bucket has server-side encryption on and all four public-access blocks set. |
| Credentials held in AWS Parameter Store | In place | Encrypted parameters are injected when a container starts and scoped by IAM to this environment. No credential is written into a task definition or into infrastructure state. |
| Database and cache reachable only from named security groups | In place | Neither accepts a connection from an IP range. Access is granted per security group, and neither is publicly addressable. |
| Administrative routes gated by role and permission | In place | Every admin route checks the signed-in role, then checks a named permission for that specific action. |
| Browser hardening headers | In place | frame-ancestors, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy are sent on every response. The only Content-Security-Policy directive is frame-ancestors; there is no script restriction. |
| Prompt storage is opt-in and time-boxed | In place | Request and response snapshots are stored only for accounts that switch the setting on, deleted after fourteen days, and erased the moment the setting is switched off. Platform operators can read stored snapshots. |
| Application errors captured centrally | In place | Backend and frontend errors go to our error-tracking system. |
| Machine-readable security contact | In place | /.well-known/security.txt is published with a live expiry date, so scanners and researcher tooling accept it. |
| SOC 2 report | Not in place | No audit and no auditor engagement exists. There is nothing to share under NDA. |
| ISO 27001 certification | Not in place | We are not certified and have not begun certification. |
| HIPAA and protected health information | Not in place | No business associate agreement exists. Do not send protected health information through the API. |
| PCI DSS certification | Not in place | Card details are entered on the payment provider's own hosted checkout. We never receive a card number, which limits our exposure but is not a certification. |
| Independent penetration test | Not in place | None has been commissioned. Our own internal reviews are not an audit and we do not describe them as one. |
| Paid vulnerability rewards | Not in place | We read and act on reports. We run no bug bounty and pay nothing for a finding. |
| Encryption on the cache and internal queue | Not in place | Switched off both in transit and at rest on the Valkey cluster that carries sessions, rate counters and in-flight prompt text. |
| Multi-factor authentication on Open LLMs itself | Not in place | Account security rests on your Google or GitHub account, or on access to your email inbox. Turn on two-factor authentication there. |
| Automated credential rotation | Not in place | No rotation schedule is configured for any credential. |
| Alerts that reach a person | Not in place | Error-rate, latency and dead-letter alarms are recorded in our cloud console and notify nobody. Nothing pages an engineer out of hours. |
| Web application firewall or bot filtering | Not in place | None is configured in our infrastructure. |
| Availability commitment | Not in place | Nothing on the platform measures availability, so we publish no availability figure and give no service-level agreement. |
| Status page | Not in place | We do not publish one. Failures surface as API errors. |
| Self-service account deletion | Not in place | Erasure runs as a manual privacy request rather than a button in the dashboard. |
How do I report a vulnerability?
Send it privately
Use the contact form. Do not open a public issue or post the finding first.
Include the four things
Reproduction steps, the impact, the affected host, and how to reach you.
Leave secrets out
Send no API keys, customer data or production credentials in the first message.
We come back to you
One operator reads these. There is no on-call rotation behind the address.
Note:
Automated scanners can read /.well-known/security.txt, which names this page as the reporting policy.
What do we ask of security researchers?
Other people's data
Stop at the first proof. Do not read, copy, alter or keep another account's data.
Service availability
No load testing, no denial-of-service, no automated scanning that degrades the API for others.
People
No phishing, no social engineering of users or of the operator, no physical intrusion.
Disclosure
Give us 90 days from your report before publishing, or less if we fix it sooner.
- No legal action
- Research that stays inside the four rules above is authorised. We will not pursue or support a claim against you for it.
- Credit
- We name you as the reporter if you ask us to, and stay silent if you would rather we did.
- Payment
- None. We have no budget for rewards and will not imply otherwise.