How storage keys are protected

When an Owner adds a connection, they give quickS3 an access key for your storage. Here’s what happens to it.

1. You paste it into the connection form. It travels to quickS3 over HTTPS.
2. quickS3 encrypts it with AES-GCM, using a key held only on quickS3’s servers, and stores it with your organisation’s data.
3. quickS3 uses it only on its servers: to list buckets and files, and to sign the short-lived links your browser or AI client uses to move files. It’s decrypted in memory for that and never written anywhere in plain text.
4. Nobody can read it back. The key is never sent to a browser or an AI client, not even to Owners. Edit forms show the key fields empty.
5. You replace it by typing a new key into the connection. Leaving the fields empty keeps the current one.
6. You delete it by deleting the connection, which removes quickS3’s copy. To make sure it can never be used again, also delete the key at your provider.

Why the key’s own permissions still matter

Roles in quickS3 decide what people and AI clients can ask for. The key decides what quickS3 can actually do at your provider. If something went wrong inside quickS3, the damage would be limited to what the key allows. That’s the reason to give it only the buckets and permissions your team uses. See give quickS3 the smallest key that works.

Rotating a key

Create a new key at your provider, paste it into the connection, test, then delete the old key at the provider. Edit, rotate, or delete a connection has the steps.

Rotate on a regular schedule, and straight away if you think a key was exposed.

Where keys never belong

Support tickets, screenshots, chat messages, emails, and logs. Nobody at quickS3 will ask you for a key. Anyone who does is either mistaken or trying to steal it.