Security at KemJet

Three principles govern how the platform is built, and each is enforced in code rather than by convention.

• Least privilege. Every request is authorised against the caller’s membership of the specific workspace it touches, evaluated server-side before any data is read or written.
• Data minimisation. Subsystems that do not require your chemistry do not receive it. Our logs, audit trail and product telemetry carry identifiers and outcomes, never payloads.
• Defence in depth. Credential handling, transport security, tenant scoping and rate limiting are independent layers. No single failure exposes customer data.

Plaintext passwords are never persisted and never logged. Credentials are stored as a PBKDF2-HMAC-SHA256 derivation with a per-user cryptographic salt and a high iteration count, using the current hashing profile of ASP.NET Core Identity. Key stretching of this kind makes offline recovery of a password from a database copy computationally impractical.

Authentication issues a short-lived signed bearer token for API access, paired with a longer-lived refresh token. Refresh tokens are persisted only as a SHA-256 digest, so the credential capable of resuming a session does not exist in our database in usable form. Tokens rotate on every refresh, and the superseded token is invalidated on issue, which bounds the value of a captured token to a single use.

Account recovery links are single-use and time-limited. The reset endpoint is enumeration-resistant: a request for an address with no account is indistinguishable in response and in timing from one for an address that exists, so the flow cannot be used to determine who holds an account.

Customer data is scoped to a workspace, and workspace membership is the boundary. Isolation is enforced in the data access layer, not by filtering in the interface: a request for a resource in a workspace the caller does not belong to is refused identically whether or not that resource exists, so the authorisation boundary does not leak the existence of what sits behind it.

Within a workspace, role-based access control governs what each member may do. Owners administer membership, retention and billing. Editors create and modify chemistry and consume compute. Viewers have read access and cannot mutate state or spend budget. Guests are scoped to what they have explicitly been granted.

All traffic is served over TLS, and plaintext HTTP is redirected rather than answered. TLS terminates on infrastructure we control, under certificates we hold, rather than at a third-party edge that would observe decrypted traffic in transit. Internal service calls between the application tier and the model and data tiers remain within our own network boundary.

At rest, database volumes, backups and stored objects are encrypted using AES-256 through Amazon Web Services’s managed key infrastructure. Snapshots inherit the encryption of the volume they are taken from.

Every state-changing command writes an immutable audit record: the acting principal, the operation invoked, the outcome, and the resource affected. Outcomes distinguish success from refusal from failure, so an authorisation denial is visible as a denial rather than absent from the record. Workspace owners inspect their own trail directly in settings.

The trail records identifiers and outcomes. It deliberately holds no structures, predictions, request bodies or response bodies. An audit log is read by a broader audience than the data it describes and is retained considerably longer, so a trail that copied customer chemistry into itself would widen precisely the exposure it exists to measure.

The following are kept out of application logs, error reporting and telemetry by construction rather than by redaction after the fact:

• Passwords in any form, including within failed authentication records.
• Refresh tokens, API keys and account recovery tokens.
• Request and response bodies. Diagnostics reference identifiers.
• The content of assistant conversations. Our usage telemetry records how many turns occurred and how they concluded, never what was said.
• Structures, predictions and results, in any operational log.

Access to production data is restricted to the personnel required to operate the service, and is exercised to resolve faults and to answer support requests you have raised. Our staff do not browse customer chemistry. Clause 13 of the terms of service makes this contractual.

API endpoints are rate-limited per caller. This bounds the rate at which a compromised credential can be exercised and prevents any single client from degrading service for others.

Compute is budgeted per workspace and enforced at dispatch: a run that would exceed the remaining allocation is refused before it is scheduled rather than terminated mid-execution, and owners are warned as the budget is approached. Long-running scientific workloads execute in isolated processes, so a failure in a third-party engine is surfaced as a diagnosed error rather than propagating into the service.

The platform operates on Amazon Web Services. Workspace data is retained for as long as the workspace exists. We operate no expiry job and impose no time limit after which your work is removed, so nothing you have built disappears because it has been sitting there.

Deletion is customer-initiated. Removing a project or workspace clears its chemistry, runs and results from primary storage. Backups expire on their own rotation, so deletion propagates to them within 35 days. Audit records persist beyond the resources they describe, by design, and contain identifiers rather than content.

Where a regulated environment requires destruction on a defined schedule, we will agree one contractually.

Data subject requests, including export and erasure, are handled under the privacy policy.

We engage a small number of vetted sub-processors, each receiving only what its function requires. The complete list, including what each one receives and where it operates, is maintained in the privacy policy and updated before a change takes effect rather than after.

If you believe you have identified a vulnerability, report it to security@kemjet.org with sufficient detail to reproduce. We will credit you if you would like to be credited.

Our commitments to you:

• Acknowledgement within three working days.
• An assessment of reproducibility and impact, communicated back to you.
• No legal action for good-faith research conducted within your own account, halted at the first indication of access to another party’s data, and causing no degradation of service.
• Notification of affected customers without undue delay in the event of a confirmed breach of their data, with the facts as we know them and the remediation underway.

Testing against another customer’s workspace, denial-of-service or load testing, and social engineering of our personnel or providers fall outside this policy.

If your organisation requires a security review before adoption, write to security@kemjet.org. We will answer a questionnaire directly and tell you plainly where a control is in place and where it is on the roadmap.