How your AI provider key is stored: encryption at rest
When an admin adds an AI provider key in the app, Swiftly Workspace encrypts it with AES-256-GCM before storing it, using a secret kept outside the database. The server never sends the key back, not even partly hidden, and decrypts it just to call the provider for your company.
An API key is a password that spends money. Whoever holds it can send requests that your provider account pays for, so how a business application stores it deserves a straight answer. This post gives it, along with what you can do on your side.
Why the key is stored on the server at all
Cloud AI in Swiftly runs on your company's own provider account: an admin adds the key once, and the provider bills that account for what you use. Bring your own AI key explains that model.
The apps on your iPhone, iPad and Mac never talk to a cloud AI provider. The server does, with your question and the records needed to answer it. That design keeps the key off every device and in one place where access can be controlled, but it means the server has to hold the key safely.
What happens when an admin saves a key
| Step | What happens |
|---|---|
| Paste and save | The app sends the key to the server over HTTPS, like every other request. |
| Format check | The server checks that the key looks like a key for that provider and refuses it if not. |
| Encryption | The key is encrypted with AES-256-GCM and a fresh random value for that encryption. |
| Storage | A key you add in the app's AI provider settings is stored encrypted, for your company and that provider. The plain key is not written to the database. |
| Response | The app learns that a key is configured, nothing more. The input field clears. |
On a Mac, this all happens behind a single Save; how to connect your own AI provider key on Mac shows the screens, and the iPhone and iPad guide covers the same steps there.
AES-256-GCM in plain words
AES is a widely used symmetric cipher, and 256 is the length of the secret key in bits. GCM is a mode that does two jobs at once: it keeps the content secret, and it adds an authentication tag that detects any change to the stored value. If the encrypted key were altered in the database, decrypting it would fail instead of producing a wrong key.
Each encryption uses a new random nonce, stored next to the ciphertext. Saving the same key twice therefore gives two different stored values, so nobody can tell from the database whether two companies use the same key.
The encryption secret itself is a separate 256-bit value held in the server's configuration, not in the database. A copy of the database alone is not enough to read the keys in it.
When the key is decrypted
The key is decrypted on the server at the moment it is needed:
- whenever the server sends a request to that provider for your company, for example a question in Conversations or a message to a record's assistant;
- when the server asks the provider for its list of available models.
The decrypted key is used for that call to the provider. It is never part of what the server sends back to the apps.
Who can see or change the key
Nobody can read a stored key back, admins included. What admins can do is add a key, replace it by saving a new one, turn a provider on or off, and remove a key with Remove Custom Key.
Even that is limited to people whose role includes the company's AI provider settings. The Standard role that new members get leaves those settings out, along with the other company administration, so a new colleague can use the workspace without being able to touch the keys. What the Standard role includes lists the rest.
What you can do on your side
- Create a key just for Swiftly. A dedicated key can be revoked without breaking anything else that uses your provider account.
- Set a spending limit in the provider's console, if it offers one. That caps the cost of any mistake.
- Keep the admin group small. The fewer people who can replace keys, the easier it is to reason about them.
- Rotate the key now and then. Create a new one at the provider, save it in Swiftly, then revoke the old one at the provider.
- If a key leaks, revoke it at the provider. Removing it from Swiftly stops Swiftly using it, but revoking it is what stops anyone else.
Choosing which provider to trust with your data is a separate decision; how to choose an AI provider for your business covers it. Passwords are protected differently, with hashing rather than encryption, as how passwords are stored explains.
Frequently asked questions
Can Swiftly staff read my AI provider key?
Not through any screen or API. The key can be decrypted with the server's encryption secret, which is kept outside the database; the server does that for each call to your provider. If you want a key that can be cut off at any moment, create a dedicated one and revoke it at the provider whenever you like.
What is the difference between encryption and hashing for secrets?
Hashing is one-way: it suits passwords, which never need to be read back, just checked. Encryption can be reversed with the right secret, which an API key needs, because the server has to send the real key to the provider.
Why can't I see my saved API key again?
Because the server never returns it, not even partly hidden. If you lost your copy, create a new key at the provider, save it in Swiftly and revoke the old one.
How often should I rotate an AI API key?
There is no single rule. Many teams rotate on a fixed schedule, such as every few months, and always when someone with access leaves or a key may have leaked. In Swiftly, an admin saves the new key over the old one, then revokes the old key at the provider.
Run your business on Apple.
Create your account on the web, then set up your workspace in the app on your iPhone, iPad or Mac.
Create your account
