Key management best practices

An inference key is a bearer credential. Whoever holds it can spend your workspace's credit until the key is revoked. Treat it like the password to a paid account.

What a key is

• A key is sg-api- followed by 64 hexadecimal characters. It goes in the Authorization: Bearer header. See Authentication.
• The full key is shown once, when you create it. Safeguard stores only a SHA-256 hash of it, so nobody can show it to you again. If you lose it, revoke it and create a new one.
• From then on, the Console shows the key masked, as its start and end: sg-api-1a2b3c4d…9f8e.
• A key carries one scope, inference. It works with the inference API and nothing else in Safeguard. MCP keys, Guard SDK keys and other Safeguard credentials are not accepted by the inference API.
• A key belongs to your workspace and acts for the member who created it. It stops working if that member is deactivated or removed.
• Keys created in the Console have no expiry date. They work until they are revoked.

Store keys as secrets

• Copy the key from the Copy your key dialog straight into your secret manager. A click outside the dialog does not dismiss it, but the Escape key does, and the key is gone once the dialog closes.
• Give the key to your application at runtime, from your secret manager or an environment variable such as SAFEGUARD_INFERENCE_KEY. Keep it out of source code and configuration files.
• Keep it out of tickets, chat, screenshots and logs. If you log outgoing requests, redact the Authorization header.
• When you report a problem, quote the key's name or masked form. Never the key.

Keep keys out of client-side code

Never put a key in a web page, a mobile app or a desktop app you hand out. Anyone with a copy of the app can read the key and spend your credit. Call the inference API from your own server, and have your apps call your server.

Use one key per app and environment

Create a separate key for each application and each environment, such as production, staging and CI. Then you can revoke one key without touching the others. Each key gets its own monthly spend limit and its own requests-per-minute limit, and Usage splits spend by key.

Name each key for where it is used, for example prod-checkout-service. Edit renames a key without changing its secret.

Give each key only what it needs

• Set a monthly spend limit on every key, sized to its job. A leaked key with a $50 limit is refused once its requests would take it past $50 in the month. See Spend controls.
• Lower the requests-per-minute limit for low-traffic jobs. The default is 60.
• Ask a tenant admin or super admin for a workspace limit, as a ceiling over all keys and the Workbench.
• Every key can call every model available to your workspace.
• A key stops working when its owner leaves the workspace. Before someone leaves, replace the keys they created.

Rotate keys

The Console does not rotate keys for you, but a rotation takes a few minutes:

1. Create a new key with the same limits.
2. Deploy it everywhere the old key is used.
3. Check that the old key is idle. On API keys, its Last used time stops changing and its This month spend stops growing. Last used is updated at most about once a minute.
4. Revoke the old key.

Both keys work while you switch over, so nothing fails in between. Rotate on the schedule your security policy sets, when someone with access to a key leaves, and after any suspected exposure.

If a key leaks

1. Revoke it now. On API keys, select Revoke on the key's row and confirm. The Console warns: "Requests that use this key are refused within 30 seconds. This cannot be undone."
2. Allow 30 seconds. The gateway trusts a key it has checked for up to 30 seconds before checking it again, so requests with a revoked key are refused within 30 seconds. A request that had already started runs to its end.
3. Replace it. Create a new key and deploy it.
4. Check what it spent. A revoked key stays listed under Revoked on API keys, with what it spent this month. In Usage, By key and the request log name it by its name and masked form, with each request's time, model, cost and status.
5. Close the gap. Find out where the key was exposed and fix that, so the new key does not leak the same way.

If you see usage your team did not make, contact hi@safeguard.sh with the key's name and the time window.

A tenant admin can stop all of one member's keys at once by deactivating the member, which also ends their sessions. See Team and access.

Related

• Authentication
• Spend controls
• Team and access
• Troubleshooting