A Rotation Schedule for Keys That Feed Your Model Endpoints

• Model provider API keys, especially any used from a server-side integration where a leak grants broad usage under your account.
• Internal service-to-service tokens between your gateway and model server, easy to forget because nothing external ever sees them.
• Signing keys for webhooks or callbacks tied to your inference pipeline.
• Database credentials for whatever stores your prompt and completion logs, since that data is often more sensitive than teams initially treat it.

Each category needs its own rotation cadence; a database credential rarely used by humans can rotate less often than a key embedded in a client-facing integration.

Treat a leaked credential with the same urgency as an unpatched vulnerability. CISA's federal guidance gives critical, internet-facing vulnerabilities a 15-day remediation window¹; a secret that's been sitting exposed in a git history for months has already blown past a much tighter standard than that.

Once a secret is confirmed leaked, rotate it immediately rather than waiting for the next scheduled cycle, and check logs for any usage during the exposure window. A rotation schedule handles the routine case; a leak needs an incident response, not a queued ticket.

The failure mode teams fear most, rotating a key and breaking production because something still references the old value, is avoidable with a short overlap window: issue the new secret, deploy it everywhere it's needed, confirm it's live, then revoke the old one. Revoking before confirming the new one works is how rotation causes outages.

A secrets manager that supports versioned values makes this straightforward; without one, the overlap window has to be tracked manually, which is exactly the kind of manual step that eventually gets skipped under time pressure.

Rotation limits how long a leaked secret stays useful, but preventing the leak matters more. Keep secrets out of source control entirely, including config files committed by accident, and use a dedicated secrets manager rather than environment variables passed around in deployment scripts or shared documents.

Scan your repository history for anything that looks like a credential before you assume it's clean; a secret committed once and later removed from the current file still lives in git history unless someone explicitly purges it. Treat any secret found this way as leaked, not just accidentally exposed, and rotate it immediately rather than assuming history access is limited enough not to matter, even inside a private repository. A one-time repository scan before you set up ongoing rotation catches the backlog; ongoing scanning on every commit catches the next one before it becomes a backlog again.

Vanta and similar platforms can track rotation dates and flag secrets that are overdue, turning a policy into something with an actual evidence trail. That's useful for an audit and for catching drift internally, but it doesn't rotate anything itself; the automation that actually performs the rotation and manages the overlap window is a separate, engineering-owned piece.

A practical starting point is an inventory. List every secret the serving stack uses, who owns it, where it is stored, when it was last changed, and what breaks if it is revoked. Most teams find a few secrets nobody can account for, and those are the first candidates to rotate, since an unowned secret is one nobody would notice being misused. Once the list exists, assign each secret a rotation interval and an owner, and put the next rotation date in your secrets manager or on a shared calendar so the schedule does not depend on memory.

• Revoking an old secret before confirming every system using it has picked up the new one.
• Rotating external-facing keys on a schedule while forgetting internal service-to-service tokens that never show up in a vendor dashboard.
• Treating a rotation policy as complete once it's written down, without checking that it actually runs on schedule.