Keep Provider Secrets Out of Your Apps
Most leaked AI keys leak because they were copied into too many places. Three habits remove the problem: apps hold virtual keys, the gateway holds provider keys, and strict workloads keep their keys inside your own network.
In this post
- 01The key that lived in nine places
- 02Two kinds of key
- 03What a virtual key can and cannot do
- 04Cutting off one app
- 05Labels that make keys useful in reports
- 06Provider credentials stay replaceable
- 07When the key must not leave your network
- 08What a leak costs, in numbers
- 09Keys as code
- 10Rotation as a routine
- 11Roll out in a week
- 12Your first week
The key that lived in nine places
Every AI team has a provider key that started in one place and ended up in many.
Picture this
A developer pastes a provider key into a notebook to try a model. The notebook becomes a service. The service is copied into a second service, a CI job, a staging config, and a teammate's laptop. Months later the key is in nine places, nobody knows which are live, and rotating it means a day of hunting.
No step was careless. The key simply had no single home, so every copy was a new place for it to leak from.
Two kinds of key
The fix is to separate the key your app holds from the key your provider issued.
| Provider key | Virtual key | |
|---|---|---|
| Issued by | OpenAI, Anthropic, AWS, Google | Cloptima |
| Held by | The gateway, once | Each app or agent |
| Can do | Anything the provider account allows | Send requests through the gateway, under policy |
| If it leaks | Full access to your provider account | Revoke one key, and nothing else changes |
Apps get virtual keys. The provider key goes into Cloptima once.
What a virtual key can and cannot do
A virtual key is deliberately small.
- It can send inference requests through the gateway
- It cannot change settings, read reports, or create other keys
- It carries a team, an app, and an environment, so every request is labeled
- It follows the policy bound to it: models, limits, budgets, guardrails, and tools
- It expires on a date you choose
Cutting off one app
The best thing about one key per app is what it does during an incident.
One shared provider key
- Revoking it stops every app
- The provider's logs cannot say which app spent what
- Rotating means redeploying everything
One virtual key per app
- Revoking it stops one app
- Spend and blocks are traced to a named key
- Rotating means redeploying one app
You can revoke a key in seconds, and your history stays in the Explorer under the key's name.
Labels that make keys useful in reports
A key is also a label. Set its team, app, and environment once and every call carries them.
| Label | What it unlocks |
|---|---|
| Team | Spend by team, and a policy per team |
| App | Cost per product or service |
| Environment | Production separated from testing |
Request headers can add detail, but the key decides which policy applies. A caller cannot talk its way onto a looser policy.
Provider credentials stay replaceable
Because apps refer to a credential and not to a secret, you can change the secret without touching an app.
- 1
Create a new key at the provider
Leave the old one live.
- 2
Rotate the credential in Cloptima
Test it.
- 3
Delete the old key at the provider
No app changed.
A routine that takes five minutes gets done. One that takes a day does not.
When the key must not leave your network
Some workloads cannot send a provider key to anyone, even a platform you trust.
For these, run the Cloptima edge gateway in your own network. The provider key lives on your host and never reaches Cloptima. The edge still enforces your policies and budgets, and still reports usage. Prompts and answers stay in your network unless you turn on trace retention.
- Policy changes reach the edge in about a second
- If the cloud is unreachable, the edge keeps serving and enforcing budgets on its last signed state
- Every edge request uses your own keys
What a leak costs, in numbers
A thought experiment shows why the two-key design matters.
The figures are an illustration.
| Shared provider key | Virtual key per app | |
|---|---|---|
| Apps holding the secret | 9 | 1 each |
| Time to find where it leaked from | Hours to days | Minutes: the key names the app |
| Apps stopped when you revoke | 9 | 1 |
| Spend an attacker can run before the limit | Whatever the provider account allows | The policy's budget and rate limit |
The virtual key does not make a leak impossible. It makes a leak small, local, and capped by a policy you set in advance.
Keys as code
Virtual keys and provider credentials can live in Terraform with the policies that govern them.
A key change then goes through review like any other change, and a rotation leaves a trail.
- Changing a key's lifetime issues a new secret
- Creating the new key before retiring the old one means no gap
- Secrets stay out of source control and go to your secret manager
Rotation as a routine
Treat rotation as a calendar item, not an emergency.
| Secret | A reasonable routine |
|---|---|
| Provider credential | Rotate when the provider asks, and at least once a year |
| Virtual key for production | Rotate every 90 to 365 days |
| Virtual key for a pilot | Let it expire |
| Edge token | Replace when people with access change |
Roll out in a week
You do not need to move every app at once.
- 1
Day 1: inventory
List where provider keys live today.
- 2
Day 2: add the credentials
Store each provider key in Cloptima and test it.
- 3
Day 3: create virtual keys
One per app, named by app and environment.
- 4
Day 4: switch one app
Replace its provider key with its virtual key.
- 5
Day 5: remove the old key
Delete it from the app, and then the other copies.
Your first week
Start with the key most likely to be copied.
- Pick the app whose provider key lives in the most places
- Give it a virtual key with team, app, and environment set
- Bind a policy to it before you cut over
- Revoke every other copy of the provider key
- Put the next rotation date in a calendar