Protect an AI API key and bound the requests that can spend it
Keep the provider key server-side, authorize users and limit request size, model access and usage before exposing an AI feature.
In brief
An AI provider’s secret key can authorize billable requests. Keep it in a server-side secret store; a frontend environment variable or hidden button does not stop a visitor inspecting and copying it.
A secure integration also controls who can spend through your server, not just where the key is stored.
Protect the credential path
Use a provider project and credential with the least appropriate scope. Do not ship it in generated JavaScript, source maps or public configuration. Keep development and production values separate and avoid printing them in build logs or error responses.
Bound the billable operation
Limit input size, output and concurrent requests according to the feature. Restrict available tools and model choices on the server. A user-controlled parameter should not silently turn a cheap text helper into an expensive unrestricted job. Add abuse controls suitable for the application.
Respond to a leak at the issuer
Revoke the exposed key, replace legitimate configuration and review usage or billing. Deleting a bundle or commit does not invalidate copies. Keep non-secret request references for diagnosis, and do not paste a key into a support ticket or a public checker.
Before you act
A proxy with an unrestricted prompt, model or output limit can still be abused. Provider budget alerts may not be a hard application spending cap.
What to do next
- Store the secret using the hosting platform’s server-side facility and exclude local secret files.
- Authenticate and authorize the public request path, validating size and allowed model/action.
- Set appropriate usage limits and review provider activity; rotate the key if it was exposed.
