Atomiq uses a client-held key model for credential security. Your OAuth tokens and API keys are encrypted with a key that only you hold. We store ciphertext we cannot decrypt. Not us, not an attacker with full database access, not anyone.
When you connect a tool like GitHub or Slack to a SaaS platform, that platform typically stores your OAuth token in their database. Their team can read it. An attacker who breaches their infrastructure can read it. A rogue employee can read it.
Atomiq takes a different approach. We designed the system so that even we cannot access your credentials. This isn't a policy decision. It's a cryptographic guarantee.
When a team member connects a service like GitHub through Atomiq, their OAuth token is encrypted before it ever reaches our servers. The encryption key stays with you.
When a team member connects GitHub, Slack, or Linear, the standard OAuth flow happens. The resulting access token arrives in the member's browser.
Before the token leaves the browser, it's encrypted using AES-256-GCM with your team's client key. The client key is generated when you create your Atomiq workspace and is held by you. It never travels to our servers.
Our server receives and stores the encrypted blob. We have no mechanism to decrypt it. The database column contains ciphertext that is meaningless without your client key.
When an authorized agent makes a tool call, the client key is provided in the request. The credential is decrypted in memory, used for that single API call, and immediately discarded. It is never written to disk, never cached, never logged.
Security architecture is only meaningful if it holds up under real threat scenarios. Here's what happens in each case.
An attacker gains full read access to the Atomiq database, including all stored credentials.
The database contains only AES-256-GCM ciphertext. Without your client key, the tokens are computationally indistinguishable from random bytes. There is nothing to decrypt.
An insider at Atomiq attempts to access customer credentials using their database access.
Atomiq employees have the same access as an external attacker: ciphertext only. The client key is not stored on our infrastructure. There is no key to steal, no backdoor, no master key.
A government agency requests all stored credentials for a specific customer account.
We can comply with the request, but we can only hand over encrypted ciphertext. We do not possess the decryption key and cannot produce plaintext tokens.
An attacker gains access to your client key through your own infrastructure.
They would also need access to the Atomiq database to retrieve the ciphertext. The key alone is useless without the corresponding encrypted data. Rotate your client key through the dashboard and all credentials are re-encrypted.
These aren't aspirational. They're architectural constraints built into the system.
OAuth tokens and API keys are encrypted before they leave your browser. Our servers process and store ciphertext only.
Your client encryption key is generated and held by you. It is not transmitted to, stored on, or recoverable from Atomiq infrastructure.
At request time, the token is decrypted in-process for one API call, then discarded. Never written to disk. Never cached. Never logged.
For security teams reviewing Atomiq's architecture.
Most platforms store your tokens in plaintext or with server-managed encryption. Atomiq is architecturally different.
| Capability | Typical SaaS | Server-managed vault | Atomiq |
|---|---|---|---|
| Token storage | Plaintext in database | Encrypted, server holds key | ✓ Encrypted, client holds key |
| Vendor can read tokens | ✕ Yes | ✕ Yes | ✓ No, cryptographically impossible |
| Database breach exposure | ✕ All tokens exposed | ✕ Key + ciphertext on same infra | ✓ Ciphertext only, key not present |
| Insider threat protection | ✕ None | ✕ Limited by access controls | ✓ Architectural, not policy-based |
| Subpoena response | Plaintext tokens | Can decrypt if compelled | ✓ Can only provide ciphertext |
| Per-member isolation | Shared credential store | Shared key scope | ✓ Individually encrypted per member |
Want to review the architecture with your security team? We're happy to walk through it.
Request access