Rotate an LLM provider credential by adding and proving a replacement before you revoke the old credential. Treat the work as a controlled connection change: identify the workload identity, issue a least-privileged replacement, deploy it through the secret-delivery path, test the connection, then retire the previous key. Reversing that order turns a routine security operation into an avoidable outage.
The OpenAI guide to API keys and service accounts recommends a service account for a deployed application or automation, and says to keep keys out of browser code, mobile applications, source control, logs and customer-facing responses. It also describes the basic rotation sequence: issue a replacement, update and verify the workload, then revoke the previous key.
Separate the identity from its current secret
A provider key identifies a credential, not a business purpose. Give each production workload a non-human identity and document its owner, provider account or project, permitted environment, expiration policy and rotation path. A shared developer key makes a rotation ambiguous: nobody can tell which job will fail when it is revoked.
| Item | Keep | Do not assume |
|---|---|---|
| Workload identity | Owner, role and provider project | A key identifies the person who needs to investigate |
| Secret reference | Secret-manager location and version | The deployment automatically refreshes the value |
| Connection scope | Provider, region and allowed models | The same key is valid for every customer policy |
| Verification | A non-production request and expected result | A successful secret write proves inference works |
| Retirement evidence | Revocation time and affected connection | An expired key disappeared from every running process |
For a hypothetical service, the support-assistant worker owns one provider service account. Its deployment reads a versioned secret through the server-side runtime. The browser receives only the application's own session token. During rotation, the worker accepts the replacement key while the old credential remains usable for a short, documented overlap.
Make the overlap explicit and short
Some providers and secret stores let you create a second credential before revoking the first. Use that overlap to prove the replacement, not as a permanent state. The AWS Secrets Manager rotation guidance describes rotation as updating credentials in both the secret and the service; for types it does not manage directly, your rotation implementation has to complete both sides.
Define the rotation window and the evidence required to end it. A useful record includes the old key identifier, new key identifier or version, deployment revision, connection test result, last observed use of the old credential and revocation result. Store identifiers or fingerprints where possible, not secret values.
Test the request path that actually serves customers
A secret-manager read proves only that a process can read a secret. A useful rotation test sends an authorized, harmless request through the same gateway, network route and provider connection that production will use. It should confirm the selected region, allowed model and response path without recording prompt content in logs.
Alectura keeps provider connections separate from an application's clients. Its connection test checks each configured model before the connection serves requests, and request records mask credentials and connection details. Your application still owns the provider credential lifecycle and must decide who can change a connection.
| Phase | Required result | Stop if |
|---|---|---|
| Create | A replacement has the intended identity and scope | The key is created in the wrong account or project |
| Deliver | Only the server-side workload can read the new version | A value appears in CI output, logs or a client bundle |
| Verify | A controlled request uses the new connection successfully | The request uses a cached old process or another provider path |
| Observe | Error rate and authentication failures remain normal | Failures cluster after rollout |
| Revoke | The old credential no longer authorizes requests | A known workload still depends on it |
Design for failed or urgent rotations
An expired, exposed or accidentally revoked credential needs a different response from a scheduled change. Keep an emergency owner and a documented way to disable the affected connection or policy. Do not respond by placing a long-lived replacement in a client environment or a shell-history command.
Test whether long-running workers reload secret versions. If they do not, a rotation can look complete while old pods keep using the previous credential. Restart or reload them deliberately, then confirm that the old credential's last-use signal stops before revocation. Provider audit events can help, but their delay and granularity are provider-specific.
For SaaS products with customer-specific routing, also check that the replacement remains inside each customer's allowed provider, model and region. A valid credential does not authorize a policy exception.
Keep the rotation review useful
After each rotation, record what made it slower or riskier: a missing owner, an untested reload path, a broad credential, or insufficient connection evidence. Fix that specific gap before scheduling the next one. A calendar reminder alone is not a credential-control system.
You can review the available connection and model path for a policy with the Alectura platform documentation.