Three ways people store keys today
| Approach | Risk | Recovery |
|---|---|---|
| Hard-coded in source | Key is in git history forever | Rotate and rewrite everything |
.env file | Copied to every machine and backup | Find every copy and rotate |
| Cloud vault + proxy | Key never leaves the platform | One click, nothing else to touch |
What the vault actually stores
The vault keeps provider credentials encrypted at rest with AES-256-GCM. Decryption happens only for the duration of a single model call, in memory, and the key is discarded straight after.
Your agent gets a signed device token instead. That token can be revoked without touching the provider, which matters when a laptop is lost or a teammate leaves.
The call path, step by step
- Agent sends a chat request with its device token.
- The platform checks the token, the agent’s budget, and the policy.
- If allowed, it decrypts the key and calls the provider.
- The provider’s response is streamed back to your agent.
- The key is wiped from memory; the request is added to the audit log.
When a .env is still fine
If you run everything on one machine you trust and never commit the file, a .env works. The vault earns its keep when you have several devices, share access with a team, or hand the agent shell access — because then one key in the wrong place is a real incident, not a theoretical one.
Rotation and revoke
In the vault, rotating a key means pasting the new one once. Every device picks it up on the next request. You never edit a config on a machine you are not sitting at.