Security playbook · AI Employee: Sig

Secret & API Key Rotation

Zero secrets past rotation SLA

Install this playbookBack to marketplace
The problem

Secrets rot. Every API key, database password, service token, TLS certificate, and cloud IAM access key has a rotation cadence — usually documented in a policy nobody reads. Manual rotation is painful (coordinate with dependent services, avoid outages, verify nothing broke). The pragmatic result: rotation gets skipped, credentials age indefinitely, and the security team discovers 8-year-old production keys in the annual audit.

At a glance
Trigger
Cron + chat
Approvals
Owner approves for shared secrets
What it does
Writes to your systems
Systems
HashiCorp Vault · GitHub Secret Scanning · Cloud KMS
How it feels in production

An hour-by-hour walkthrough.

First Tuesday of the quarter. Sig runs the secret-rotation scan. Reads every managed secret from HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, and the direct-vendor credential registries. Computes each secret's age; compares against policy. Finds: 43 secrets past their rotation SLA. Categorises by risk + rotation-mechanism: - 12 fully-automatable (AWS access keys, GitHub PATs, Stripe API keys — all have rotation APIs) - 18 developer-owned (require dev to update local .env, redeploy) - 8 shared-service (require coordination — TLS certs, database passwords) - 5 vendor-side (require request to vendor + coordinated cutover) For the 12 automatable: Sig rotates immediately, coordinated to ensure no gap where both old + new are invalid. All dependents notified. For the 18 dev-owned: Sig opens a ticket per key + assigns to the owning developer with the rotation runbook + a 14-day deadline. Auto-nudges as deadline approaches; escalates to team lead if missed. For shared-service + vendor-side: Sig coordinates with the appropriate teams via ticket, tracks progress, ensures nothing slips. Weekly digest to security lead: 43 identified, 12 auto-rotated, 15 dev-tickets closed, 4 still open + on schedule, 2 overdue + escalated. Zero secrets past-SLA at steady state.
How it works

Step by step.

  1. 01

    Enumerate secrets past rotation window

    Scan every managed secret store: HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, GitHub secrets, third-party credential registries. Compare each secret's age against policy.

    HashiCorp Vault · AWS Secrets Manager · GCP · GitHub
  2. 02

    Categorise by rotation mechanism

    Sort into: fully-automatable (has rotation API + no coordination needed), developer-owned (requires manual update + redeploy), shared-service (requires cutover coordination), vendor-side (requires vendor request).

    Analysis
  3. 03

    Auto-rotate where possible

    For automatable secrets: generate new secret, update the secret store, disable the old secret. Dependents get notified. Rotation coordinated to prevent gap where both are invalid.

    AWS IAM · Vendor APIs · Kubernetes · Config Sync
  4. 04

    Open tickets for manual rotations

    Developer-owned: ticket per secret to the owning developer with runbook. Shared-service: coordinated ticket with cutover plan. Vendor-side: ticket to vendor with tracked follow-up.

    Jira · Slack · Vendor communication
  5. 05

    Verify no gaps

    Post-rotation, verify: services using the secret are healthy (no auth failures in logs); old secret is truly disabled (not just marked); audit event written for the rotation. Alert if anything wrong.

    SIEM · Application logs · Audit log
Systems and wiring

What you connect to make this run.

HashiCorp Vault · AWS Secrets Manager · GCP Secret Manager

read+write

Read secret age and metadata. Rotate via native rotation API where supported; write new secret with same identifier for auto-fetch by dependents.

AWS IAM · GCP IAM · Third-party APIs

write

For API keys with vendor-specific rotation flows (AWS keys, GitHub PATs, Stripe, etc.), Sig uses the vendor's rotation API to issue new + disable old atomically.

Kubernetes · Deployment tooling

trigger

Rolling redeploy triggered for services that mount secrets at pod-startup. Coordinated with rotation to avoid deployment failures on stale secret.

Jira · Slack

write

Ticket per manual-rotation task. Escalation ladder for overdue rotations. Dashboard for security lead visibility.

What changes

Before and after, honestly.

Secrets past rotation SLA at any time
Before
20-50% (accumulate silently)
After
Under 3% (weekly scan + nudge cadence)
Average secret age
Before
18-36 months (no manual rotation happens)
After
6-12 months (rotates on policy cadence)
Compliance findings on aged credentials
Before
5-15 findings per audit cycle
After
Zero at steady state
Post-rotation outage rate
Before
10-30% of manual rotations cause outages
After
Under 1% (auto-verification catches issues before they hit production)
Related

Playbooks that pair with this one.

Security

Compromised Credential Response

The reactive counterpart when a secret leaks before scheduled rotation.

Security

Certificate Expiration Tracking

TLS certificate rotation follows similar pattern; often co-managed.

Security

Cloud IAM Reviews

IAM role reviews complement key rotation for cloud access governance.

Frequently asked

Answers about this playbook.

How does Sig handle secrets not in a managed store (hardcoded in code)?

Sig can't rotate what it doesn't know about. Secret scanning + Context Graph surfaces hardcoded secrets during code reviews. Recommended: migrate hardcoded secrets to a managed store before enabling rotation.

What if a rotation breaks a dependent service?

Auto-verification catches most before they hit production. Post-rotation health check monitors for auth failures in the 30-min window post-rotation; auto-rollback (re-enable old secret temporarily) if the service starts failing.

Can we exclude break-glass credentials?

Yes — exclusion list for break-glass, disaster-recovery, and other rarely-used credentials. These get reviewed on different cadence (quarterly manual review by security).

How does this integrate with our CI/CD?

Post-rotation, Sig triggers rolling redeploys for services that need to fetch fresh secrets. Coordinated with your deploy pipeline. Zero-downtime rotations for stateless services; brief maintenance windows for stateful ones.

What about certificate rotation (TLS certs)?

Adjacent playbook (certificate-expiration-tracking). Same mechanism; different cadence and dependencies. TLS certs coordinate with load balancer + service mesh reload cycles.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Security playbooks