How BounceGrip handles your API keys

Where your keys are stored

When a workspace owner connects a provider, the key is encrypted before it is written to the database. Encryption is AES-GCM with a 256-bit key derived from a server-side secret that is never exposed to the application. Each key gets its own randomly generated initialisation vector, so two identical keys do not produce identical ciphertext.

What is stored alongside the ciphertext is a fingerprint: a short hash of the key plus its last four characters. That is what the interface shows you, so a workspace owner can tell two keys apart without the key itself ever being displayed again.

• AES-GCM encryption with a 256-bit derived key
• A unique random initialisation vector per stored key
• Only a fingerprint is ever shown back to a person

The path a request takes

Provider calls are server-routed. Your browser talks to the BounceGrip API, and the API talks to the model provider. The browser never holds a provider key and never opens a connection to OpenAI, Anthropic, or anyone else on your behalf.

Decryption happens only inside the server request handlers that need to make a provider call, for the duration of that call. The plaintext key exists in memory to authenticate the request and is not persisted, logged, or returned in a response.

The one moment a key passes through a browser is when a workspace owner first pastes it in, over HTTPS. After that it is encrypted server-side and never travels back.

• Browser to BounceGrip API to provider, never browser to provider
• Keys decrypted only server-side, only to make the call
• HTTPS everywhere, with HSTS enforced on the site

Who can reach a key

Connecting, replacing, and removing provider keys is restricted to workspace owners. Members can use the models an owner has enabled without ever handling a credential, which is the point: nobody needs to share an API key over chat to get someone working.

The query that lists a workspace’s providers selects the fingerprint, the label, and the status. It does not select the encrypted key at all, so there is no code path by which a member, or an owner, receives key material back from the API.

• Owners manage keys; members never see them
• The provider list query never reads the encrypted key column
• Every request is authenticated and scoped to one workspace

Isolation between workspaces

Credentials are isolated per workspace. Every provider key belongs to exactly one workspace, and every query that touches one is scoped to that workspace. Route access is checked before the handler runs: membership for reads, ownership for anything that changes a key or the enabled model list.

If you run more than one workspace, they do not share keys, models, chats, files, or usage history.

• Keys, models, chats, and usage are isolated per workspace
• Access is checked before a handler runs, not inside it

What we can and cannot see

Usage reporting is built from counts, not content. The usage record for a request stores the workspace, the member, the project, the provider and model, token counts, and an estimated cost. It does not store your prompt or the model’s reply.

Chats, saved outputs, and uploaded files are stored so the product can show them back to you and so shared context works. Provider error messages are scrubbed before they are shown: if a provider echoes your key back inside an error, it is replaced with a redaction marker rather than surfaced.

• Usage logs hold token counts and cost, not message text
• Provider error text is scrubbed of key material before display

Known limits, stated plainly

Removing a provider key disables it immediately: it stops being usable for any request, and the models behind it are switched off in the same operation. The encrypted record itself is retained rather than erased, so removal is a revocation rather than a deletion. If you need a key destroyed at the storage layer, ask and we will handle it directly.

The strongest guarantee available for any credential is rotation at the source. If a key has been exposed, revoke it in your provider’s console; that invalidates it everywhere, including here.

BounceGrip is a small product and does not hold a SOC 2 or ISO 27001 certification. This page describes the controls that exist in the code rather than an audited compliance posture, and it will say so until that changes.