Security

Nemu holds two things that matter: the provider keys you connect, and the content that passes through a request on its way to a model. Everything below is about those two, because the rest is ordinary infrastructure.

Nemu never asks for a provider account password and cannot sign in to your provider. A key you paste is a key you can revoke at your provider at any time, without our involvement.

• Keys are encrypted with AES-256-GCM before they are written, under an envelope key provisioned to the service environment and never committed to the repository.
• A stored key is decrypted only in memory, only for the lifetime of a request it is needed for, and is never written to a log or an error report.
• The console shows the last four characters and nothing else. There is no endpoint, for you or for us, that returns a stored key in full.
• Deleting a key removes the ciphertext. Any request already in flight against it fails closed rather than falling back to another key.

Every connection to api.nemu.cc, app.nemu.cc and chat.nemu.cc is TLS 1.2 or better, with HSTS set. Requests to your providers leave over TLS as well. Databases and object storage are encrypted at rest by the platform they run on.

Prompt and completion content is not retained for training, is not sold, and is not shared with any party other than the provider you addressed the request to.

• Production access is limited to the engineers who need it, through accounts that carry an explicit staff permission rather than a shared login.
• Reading or changing anything sensitive in the staff console requires re-entering the account password, that elevation expires after five minutes, and every administrative action is written to an audit trail, including staff reads of a flagged conversation.
• Workspace membership is the only thing that grants a person visibility of a workspace's keys, mappings, quotas and usage.

Live availability for each service is published at status.nemu.cc, and incidents are posted there while they are still open rather than after they are resolved.

If an incident affects your data we will contact the account owner directly, with what happened, what was reachable, and what to do about it. Where the law sets a notification deadline we work to the strictest one that applies to you.

If you have found a vulnerability, send it to [email protected] with enough detail to reproduce it. We will acknowledge within two working days and keep you updated until it is closed.

• Test only against your own account and your own data.
• Do not run denial of service tests, spam, or social engineering against our staff or our users.
• Give us a reasonable window to fix an issue before publishing it.

We do not take legal action against research that follows those three rules, and we are happy to credit you when the fix ships.

Security reports go to [email protected]. Questions about processing, sub-processors or a signed DPA go to [email protected].