Corsair holds the keys to your apps so your agent doesn't have to. Here is how we keep them, and the data that comes with them, safe.
- Corsair Cloud encrypts every API key, OAuth token and record it syncs, and each account has its own key.
- The keys that unlock them are held in AWS Key Management Service and rotate automatically. Our database only ever stores them encrypted.
- If our database were copied tomorrow, your API keys and app data would stay unreadable.
- No cross-tenant contamination: one customer’s requests can’t open another customer’s data.
How Corsair Cloud protects your data
Corsair Cloud, including your links at hub.corsair.dev/me and your yourname.lug.dev address, runs on the open-source Corsair SDK. Everything the SDK does to protect data, Cloud does too, and adds the layers below.
The SDK uses envelope encryption. Your data is encrypted with a data key, and that data key is only ever stored encrypted, locked by a separate key kept somewhere else. A copy of the database holds the data and its locked keys, but not the key that unlocks them.
- Encrypted at rest. OAuth tokens, API keys, and the records we sync from your apps (messages, issues, events) are stored encrypted with AES-256-GCM. Every connected account has its own data key.
- Keys held outside the database. The keys that unlock your workspace live in AWS Key Management Service and rotate automatically. Only an encrypted copy is stored with your data.
- Zero trust inside our own system. The servers that run your tools have no standing permission to decrypt anything. Each request carries a short-lived grant that Corsair issues for one workspace, and the key service checks it before it unlocks that workspace and nothing else.
That is why a leak of our database wouldn't expose you. A copy would hold encrypted values only, and the keys to read your API keys, tokens and app data are not in it.
No cross-tenant contamination
Every person and every customer is walled off from every other. Each connected account's data is encrypted with its own key, each person's records are kept apart by their tenant ID, and every request is tied to one project and one person before anything runs.
The access tokens Corsair issues to MCP clients are signed, name the one person and link they belong to, and expire after 15 minutes. A grant opens one workspace, so a request for one customer can't reach another customer's keys.
Under the hood: the SDK
For more detail, here is what the SDK does, whether you run it in your own app or use it through Corsair Cloud.
- It stores everything in your database: connected accounts, credentials, and the records it syncs from each app.
- Every credential is encrypted with that account's data key, and data keys are wrapped by your key-encryption key,
CORSAIR_KEK. Run the SDK yourself and that key lives in your environment; Corsair never has it. - Synced records are sealed with the same per-account keys when
encryptDataAtRestis on. It's off by default in the SDK: setencryptDataAtRest: truein your Corsair config before the first sync, because it seals records as they're written and leaves records already stored as they were. Corsair Cloud turns it on for every workspace. - The encryption code is open source under the Apache 2.0 license on GitHub, so you can read exactly how it works.
Your agent never sees your credentials
On Corsair Cloud, an agent works with tool names, arguments and results. Corsair attaches the credential when it calls the app, so a token or API key never appears in a tool result or in the model's context.
Scripts the agent writes there (run_script and read_data) run in an isolated sandbox with no network, filesystem or process access. The only thing a script can reach is the person's own connected apps, through Corsair.
The SDK's MCP adapter works differently. When you host it in your own app, run_script runs the agent's code in your process with the full corsair instance, including the methods that read and set an account's credentials. It isn't a sandbox, and a script there can read a token, so connect only agents you trust. readonly: true blocks write and destructive Corsair calls, not credential methods or other side effects of the script.
What an agent is allowed to do
Every link has a mode. Corsair checks each action against it on our side, whatever the client allows.
| Mode | What it allows |
|---|---|
| Read | Reads only. Writes are refused. |
| Cautious (default) | Writes go through. Destructive actions, such as a delete, need your approval. |
| Strict | Every write needs your approval. Destructive actions are refused. |
| Open | Everything, without asking. |
When an action needs approval, you get a link that shows exactly what will run and with which arguments. One approval covers that action once.
This is also the defense against prompt injection. An email or a web page can carry instructions, and a model may follow them. Corsair doesn't rely on the model to refuse: a read-only link can't write and a strict link can't delete, whatever the prompt says.
Signing in
MCP clients connect with OAuth and PKCE. Corsair stores sign-in codes and refresh tokens only as hashes, so the stored values can't be used to sign in. You can sign any client out of a link at hub.corsair.dev/me.
Deleting your data
Remove an app, a connection or a person from a project, and Corsair deletes that account's credentials and everything synced from it. Adding it back means connecting again.
Workflow run records are deleted 30 days after the run. The Privacy Policy lists every retention period.
AI and your data
We don't train models on your data or on data from your apps. Optional AI steps in workflows go through a gateway we run to Microsoft Azure OpenAI Service, under terms that don't allow it to train on the data either.
Report a vulnerability
Email team@corsair.dev with what you found, where you found it, and the steps that show it. The same address takes security questionnaires and review requests.
While you test:
- Use only accounts and data that are yours.
- Don't make the service slow or unavailable, send spam, or use social engineering.
- Stop once you can show the issue, and don't keep access.
- Give us reasonable time to fix it before you tell anyone else.
If you act in good faith and follow these rules, we won't take legal action against you for your research. Our security.txt gives the same address.