Trust
Security
What we do not claim
Korps holds no SOC 2 report, no ISO 27001 certificate, no PCI DSS attestation and no HIPAA business associate agreement. We do not have an independent audit, and we will not say we do until one exists.
Do not put protected health information, payment card data or government identity documents into Korps.
The architecture is deliberately kept capable of private, isolated runtime and model deployments, which is a prerequisite for a future regulated configuration. That is a design property, not a compliance claim.
This is an engineering draft. It describes the build as inspected on the date above and has not yet been reviewed by counsel or by an independent security assessor. Both reviews are required before it is published as a formal statement.
This page describes controls that are actually implemented. Anything planned is labelled as planned.
1. Accounts and sessions
- Passwords are stored only as scrypt hashes with a per-account random salt and cost parameters N=16384, r=8, p=1. Plaintext passwords are never stored or logged.
- Password verification uses a constant-time comparison.
- Access tokens are HMAC-SHA256 signed and expire 15 minutes after issue.
- Refresh tokens are random 256-bit values, stored server side only as SHA-256 hashes, and expire after 30 days.
- Sessions belong to a family. Signing out revokes the family server side, so a copied token stops working rather than outliving the sign-out.
- Sign-out works even when the access token has already expired, using the refresh token as proof of the session.
- Account recovery uses one-time codes issued at signup, eight of them, shown once and stored only as SHA-256 hashes. Spending a code sets a new password and revokes every existing session, so recovering an account also evicts anyone already in it. Every failed attempt returns the same error and status, so the response reveals nothing about which addresses have accounts, and the endpoint is rate limited with the other authentication routes.
2. Rate limiting and abuse controls
- Authentication routes, runtime claim and workspace claim are rate limited per source IP: 5 requests in a 60-second window, then HTTP 429.
- Request bodies are capped at 256 KB. Oversized bodies are drained and rejected with HTTP 413 rather than dropping the connection.
- Malformed JSON is rejected with a specific error rather than a generic failure.
3. Tenant isolation
- Every workspace-scoped read and write is filtered by the caller's workspace membership on the server. The browser cannot ask for another workspace's records by changing an identifier.
- Usage attribution is checked against ownership: reporting usage for an agent or runtime that does not belong to your workspace returns a not-found error instead of writing a cross-tenant record.
- Avatar bytes are served only to members of the owning workspace, addressed by content hash.
- A tenancy test suite exists in the control plane. It requires a database to be supplied before it will run, and it is not yet part of a continuous integration gate, so treat the boundary as resting on the implementation rather than on a green test run.
4. Infrastructure pairing
- Attaching a server uses a one-time pairing code that expires 15 minutes after issue and is stored only as a SHA-256 hash.
- Pairing state is reported from the server's own view of the handshake, so the browser shows pending, claimed or expired rather than an indefinite spinner.
- Korps never asks for, copies or stores your private SSH keys as part of this flow.
5. Transport and hosting
- All public traffic is HTTPS, terminated by a reverse proxy with automatically renewed certificates. The control-plane API listens only on loopback behind that proxy.
- Marketing and API are on separate hostnames.
- The marketing site loads no third-party scripts, fonts or trackers.
6. Provider credentials
- Korps does not store your model provider API keys. There is no column for one, and the API rejects a request that tries to supply a key rather than quietly dropping it.
- A connection record holds the provider name, the kind of credential, and which of your servers holds it. The key itself stays on that server, which is also what makes the call to the provider.
- This means a breach of the Korps control plane does not expose your provider credentials, because they were never there.
7. Logging
- Request logs record method, path, status, duration and error code. Request bodies, tokens and passwords are not logged.
- Secrets are kept out of chat transcripts and command lines wherever a safer transport exists.
8. Usage limits as a safety control
Every workspace is metered against a token allowance for a rolling window. When the allowance is reached, metered work is refused rather than continuing silently. Metering stores token counts, provider and model names, not prompt content.
9. Agent authority
Agents act with the authority you give them. Korps treats a defined set of operations as high risk and outside the scope of any auto-approval setting, including force-push and history rewrite, destructive deletes, removing backups, credential exposure or movement, privilege escalation and payment actions. See the Acceptable Use Policy.
10. Known gaps and what is planned
Stated plainly so nobody has to guess:
- Planned, not in place: email-based password reset. Recovery works today through one-time codes issued at signup, described in section 1. If you lose both your password and every code, we cannot restore the account for you.
- Planned, not in place: self-serve account deletion and data export. Both are handled manually on request today, as described in the Privacy Policy.
- Planned, not in place: multi-factor authentication.
- Planned, not in place: customer-visible audit log export.
- Planned, not in place: SSO/SAML and SCIM.
- Planned, not in place: independent penetration test and a published summary.
- Planned, not in place: formal, tested disaster-recovery objectives and a published status page.
- Planned, not in place: encryption of workspace records with customer-managed keys.
- Planned, not in place: a Content Security Policy on the web app. Everything the app inserts into the page is escaped, and that is checked, but a policy is the second line of defence for when escaping is wrong somewhere, and today there is no second line. Your access token is held in browser storage, so this is worth saying rather than leaving for you to discover in the response headers.
11. Reporting a vulnerability
Send findings to security@korps.ai (mailbox to be confirmed before publication). Please include steps to reproduce, the affected endpoint or page, and what you were able to access.
Good-faith safe harbour
If you follow these rules we will not pursue or support legal action against you for the research:
- test only against accounts and workspaces you control;
- do not access, modify or retain another customer's data, and stop as soon as you can confirm a boundary is crossed;
- no denial of service, spam or social engineering of our people;
- give us a reasonable chance to fix before publishing;
- stay within the law.
We aim to acknowledge a report within 3 business days and to give a remediation view within 14 days. Those are goals, not a contractual service level. We do not operate a paid bug bounty today.