AI Rules for Secrets Rotation

AI Treats Secrets as Constants

AI generates code with: hardcoded API keys (const API_KEY = 'sk-...'), database passwords in configuration files (committed to git), no rotation schedule (same key used for years), no revocation plan (compromised key stays active), and no secret scanning (keys committed to public repos). Each of these turns a routine credential compromise into a multi-day incident.

Modern secrets management is: vault-stored (HashiCorp Vault, AWS Secrets Manager, or Doppler), automatically rotated (on a schedule, without human intervention), zero-downtime (dual-read period where both old and new secrets are valid), CI-scanned (pre-commit hooks and pipeline checks catch leaked secrets), and incident-ready (playbook for immediate revocation and rotation). AI generates none of these.

These rules cover: vault-based secret storage, automated rotation schedules, zero-downtime rollover patterns, CI secret scanning, and incident response for leaked credentials.

Rule 1: Vault-Based Secret Storage

The rule: 'Store all secrets in a vault service: AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, or Doppler. Applications fetch secrets at startup or on-demand via API. The vault provides: centralized storage (one place for all secrets), access control (IAM policies per secret), audit logging (who accessed which secret when), versioning (rollback to previous secret version), and encryption (secrets encrypted at rest in the vault).'

For application integration: 'Fetch secrets at application startup: const dbPassword = await secretsManager.getSecretValue({ SecretId: "prod/database" }). Cache the secret in memory for the process lifetime. For rotation-aware applications: periodically refresh secrets (every 5 minutes) or subscribe to rotation events. Never write secrets to disk, environment files, or logs.'

AI generates: const DB_PASSWORD = process.env.DB_PASSWORD with the value in a .env file committed to git. Every developer, every CI pipeline, and every repo clone has the production database password. A vault: the secret lives in one place, accessed by authorized services only, with a full audit trail of who read it and when.

• AWS Secrets Manager / HashiCorp Vault / Doppler — centralized, audited, encrypted
• Fetch at startup, cache in memory — never write to disk or logs
• IAM-based access control — each service accesses only the secrets it needs
• Secret versioning — rollback to previous version if rotation breaks something
• Audit logging — who accessed which secret, when, from which service

Rule 2: Automated Rotation Schedules

The rule: 'Rotate secrets automatically on a schedule: API keys every 90 days, database passwords every 30 days, encryption keys annually (see encryption at rest article). AWS Secrets Manager supports automatic rotation with Lambda functions. HashiCorp Vault has built-in database credential rotation. The rotation happens without human intervention — reducing the risk of forgotten rotations and the blast radius of compromised credentials.'

For rotation triggers: 'Schedule-based: rotate every N days regardless of events. Event-based: rotate immediately on: employee departure (they may have seen the secret), suspected compromise (unusual access patterns), compliance requirement (audit finding). Both triggers should be supported — schedule handles routine rotation, events handle urgent rotation.'

AI generates: secrets that never rotate. The API key created two years ago is still the only one. If compromised, the attacker has had access for two years. With 90-day rotation: maximum exposure is 90 days. With immediate rotation on suspected compromise: exposure is hours, not years.

Rule 3: Zero-Downtime Secret Rollover

The rule: 'Use a dual-read pattern for zero-downtime rotation: (1) generate the new secret, (2) configure the service to accept both old and new secrets, (3) update all clients to use the new secret, (4) verify no clients use the old secret, (5) revoke the old secret. During steps 2-4, both secrets are valid — clients using the old secret still work while you roll out the new one.'

For database password rotation: 'Create a new database user with the new password (or alter the existing user to accept both). Update the application to use the new password. Verify connections succeed with the new password. Drop the old password. Total downtime: zero. AWS Secrets Manager Lambda rotation functions implement this pattern automatically for RDS, DocumentDB, and Redshift.'

AI generates: change the password in the vault, restart the application. During the restart: downtime. If the new password is wrong: extended downtime while debugging. Dual-read: both passwords work simultaneously. If the new one fails, the old one still works. No downtime, no emergency. Roll forward with confidence.

Rule 4: CI Secret Scanning

The rule: 'Scan for leaked secrets at three points: pre-commit hook (git-secrets, detect-secrets — blocks commits containing patterns matching API keys, passwords, or tokens), CI pipeline (trufflehog, gitleaks — scans the entire commit diff for high-entropy strings and known secret patterns), and repository monitoring (GitHub secret scanning, GitGuardian — continuous scanning of all commits, alerts on detected secrets).'

For pre-commit as the first line: 'Pre-commit hooks catch secrets before they enter the repository. Install: brew install git-secrets && git secrets --install. Add patterns: git secrets --add 'sk_live_[a-zA-Z0-9]{24}' (Stripe live key pattern). The hook rejects the commit with a clear message: Secret detected, do not commit. This is the cheapest fix — the secret never enters git history. Removing a secret from git history after the fact requires history rewriting (BFG Repo-Cleaner) and is significantly more expensive.'

AI generates: no secret scanning. Developers accidentally commit .env files, API keys in test files, or hardcoded tokens in configuration. The secret is now in git history — even if you delete the file, the secret is recoverable from history. Three layers of scanning (pre-commit, CI, monitoring) catch secrets at the earliest possible point.

Rule 5: Leaked Credential Incident Response

The rule: 'When a secret is leaked (committed to a public repo, found in logs, reported by a scanning tool): (1) immediately revoke the secret (do not wait to assess impact), (2) rotate to a new secret using the zero-downtime pattern, (3) audit access logs for unauthorized use during the exposure window, (4) scrub the secret from git history (BFG Repo-Cleaner or git filter-repo), (5) document the incident and improve scanning to prevent recurrence.'

For the urgency: 'GitHub public repos are continuously scraped by bots looking for API keys. A committed AWS key is exploited within minutes — not hours, not days. The first step (revoke) must happen immediately — before investigating, before understanding how it happened, before writing the incident report. Revoke first, investigate second. The cost of a false alarm (revoking a key that was not actually compromised) is minutes of rotation. The cost of delayed revocation is unbounded.'

AI generates: no incident response plan. A developer commits a secret, notices an hour later, deletes the file, pushes again. The secret is still in git history. The bots already scraped it. Without a revocation plan, the response is: panic, scramble to figure out how to rotate the key, deploy manually, hope nothing was exploited. A documented playbook turns a crisis into a 15-minute checklist.

Complete Secrets Rotation Rules Template

Consolidated rules for secrets rotation.

• Vault-based storage: AWS Secrets Manager, Vault, Doppler — never in code or .env files
• Automated rotation: API keys 90 days, database passwords 30 days, encryption keys annually
• Zero-downtime rollover: dual-read pattern, both secrets valid during transition
• Pre-commit scanning: git-secrets, detect-secrets — block secrets before they enter history
• CI scanning: trufflehog, gitleaks — catch secrets in commit diffs
• Repository monitoring: GitHub secret scanning, GitGuardian — continuous alerting
• Incident response: revoke immediately, rotate, audit, scrub history, document
• Bots scrape public repos in minutes — revoke first, investigate second