Beyond Detection: The Rotation Problem

Most organisations have decent secret detection β€” Gitleaks, Trufflehog, or GitGuardian scans run in CI and flag hardcoded credentials. The problem begins after detection.

Rotating a production credential requires: generating a new credential, updating all systems that use the old one, verifying the new credential works everywhere, deploying the updated configuration, and confirming the old credential is invalidated. Each step requires knowledge of your specific environment that no generic tool has.

The partial rotation risk: The most dangerous scenario is partial rotation β€” the old credential is revoked, but not all consumers have been updated. Services start failing, and under pressure to restore service, the old credential gets re-enabled. The breach is now worse: the attacker still has the credential, and your team has demonstrated they will re-enable it under pressure.

AI-Enhanced Detection

Traditional secret scanners use regex patterns to detect known credential formats. LLM-based detection adds several capabilities:

  • Context-aware classification β€” distinguish between a test credential (low risk), a development credential (medium risk), and a production credential with access to real systems (critical)
  • Variable secret detection β€” detect secrets stored in environment variable names that do not match known patterns (e.g., INTERNAL_API_KEY = "sk_live_...")
  • Semantic similarity β€” identify credential-like strings that do not match known patterns but appear in credential-injection contexts
  • Scope assessment β€” given an AWS access key, query IAM to determine what it can actually access before classifying severity

Automated Rotation Workflow

An AI-orchestrated rotation workflow for a detected secret:

  1. Classify β€” determine the secret type, the service it belongs to, and the expected rotation mechanism (AWS IAM, GitHub, database, etc.)
  2. Scope blast radius β€” find all places the secret is referenced (code, CI/CD vars, deployment configs, Vault)
  3. Revocation check β€” verify with the service whether the credential has already been used since exposure
  4. Generate new credential β€” using the service's API, generate a replacement credential
  5. Staged rollout β€” update consumers in order: least-critical first, monitor, then production
  6. Verify β€” confirm each consumer is healthy with the new credential before proceeding
  7. Revoke old credential β€” only after all consumers are confirmed healthy
  8. Remove from history β€” open a PR to remove the secret from source and, where safe, rewrite the relevant git history

Steps 5 and 7 ordering is critical. The most common rotation failure is revoking the old credential before confirming all consumers have been updated. This causes an outage that often results in the old credential being re-enabled.

Consumer Mapping

The hardest part of secret rotation is knowing everything that uses the credential. AI can help by:

  • Searching the codebase for all references to the secret variable name
  • Checking CI/CD platform environment variables
  • Searching infrastructure-as-code for the secret reference
  • Querying secrets managers (Vault, AWS Secrets Manager) for dependent services
  • Checking deployment configs, Kubernetes secrets, and Docker Compose files

The AI maintains a consumer map and rotates them in dependency order, with health checks between each update.

Secret Class-Specific Strategies

  • AWS access keys β€” create new IAM access key, update all consumers, verify, deactivate old key (do not delete immediately β€” reactivation window if consumers missed)
  • GitHub PATs β€” generate new fine-grained token with same permissions, update consumers, revoke old token
  • Database passwords β€” create new user or update password, update connection strings in all consumers, verify with test query, drop old user/password
  • API keys (third-party) β€” call the service API to generate new key, update consumers, call the revocation endpoint
  • JWT signing keys β€” requires token invalidation strategy: either force re-login (aggressive) or run dual-key validation period (graceful)