The security profile of API keys has shifted dramatically. Researchers at TruffleHog discovered over 2,800 live Google API keys publicly exposed in code repositories—keys that now grant access to Google's Gemini AI and any private data users have shared with it. Google classified this as "single-service privilege escalation" on January 13, 2026, and deployed automated detection to block leaked keys. This incident highlights a broader issue: your key management practices may not be equipped to handle this evolving threat landscape.
This checklist will help your team audit API key exposure across your codebase and infrastructure before a previously benign credential becomes an attack vector.
What This Checklist Covers
This audit focuses on API keys that authenticate to external services, particularly AI platforms, analytics tools, and cloud providers. You'll verify that keys are:
- Not committed to version control (current or historical)
- Stored in secure credential management systems
- Scoped to minimum necessary permissions
- Monitored for unauthorized usage
- Rotated according to your security policy
The checklist addresses PCI DSS v4.0.1 Requirement 8.3.2 (authentication credential management) and maps to NIST CSF v2.0 PR.AC-1 (identity and credential management).
Prerequisites
Before starting this audit:
- Access to your organization's code repositories (GitHub, GitLab, Bitbucket, etc.)
- Credentials for your secret scanning tools (if deployed)
- Inventory of third-party services your applications authenticate to
- Documentation of current key rotation policies (even if informal)
- Access to cloud provider IAM consoles for permission verification
Set aside 4-6 hours for an initial audit of a typical application. Budget additional time proportional to your repository count.
Checklist Items
1. Scan All Repositories for Exposed Keys
Run a secret scanning tool across every repository your team maintains, including archived projects.
Tools: TruffleHog, GitGuardian, GitHub Advanced Security, or AWS CodeGuru Reviewer.
What good looks like: Zero API keys, tokens, or credentials found in current commits. Historical commits flagged for remediation through git history rewriting or key rotation.
2. Verify Keys Are Not in Environment Files Committed to Git
Check for .env, config.yml, .properties, and similar files in your repository root and subdirectories.
Common mistake: Developers commit .env.example files that contain real keys instead of placeholder values.
What good looks like: All environment files in .gitignore. Example files contain only YOUR_KEY_HERE placeholders. Real keys stored in deployment-specific secret managers.
3. Audit Third-Party Service Permissions
For each API key your application uses, log into the provider's console and review the granted permissions.
Specific check: Can this key read data beyond what your application needs? Can it write or delete? Can it access user-generated content?
What good looks like: Keys scoped to read-only where possible. Write permissions limited to specific resources. No wildcard or admin-level grants. This aligns with NIST 800-53 Rev 5 AC-6 (Least Privilege).
4. Implement Automated Secret Scanning in CI/CD
Configure pre-commit hooks and CI pipeline checks to block commits containing secrets.
Implementation: GitHub push protection, pre-commit framework with detect-secrets, or GitLab secret detection jobs.
What good looks like: Pipeline fails immediately when a secret pattern is detected. Developer receives clear remediation instructions. No manual review required to catch 95%+ of accidental commits.
5. Rotate All Keys Found in Git History
Even if you've removed keys from current commits, they remain in git history and are accessible to anyone who clones the repository.
Action required: Generate new keys in provider consoles. Update production systems. Revoke old keys. For public repositories, assume exposed keys are already compromised.
What good looks like: All keys found in git history are revoked within 24 hours. New keys never existed in version control. Rotation documented in security log.
6. Centralize Key Storage in Secret Management Systems
Migrate API keys from environment variables, config files, and deployment scripts to dedicated secret managers.
Options: AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, Google Secret Manager, or Doppler.
What good looks like: Applications fetch secrets at runtime via SDK or sidecar. No secrets in container images. Audit logs show which services accessed which secrets. This satisfies PCI DSS v4.0.1 Requirement 8.3.1 (secure authentication credential storage).
7. Enable Usage Monitoring and Alerting
Configure alerts for unusual API key usage patterns that might indicate compromise.
Metrics to track: Request volume spikes, geographic anomalies, access to new resources, elevated error rates.
What good looks like: Alert fires within 15 minutes of anomalous activity. Runbook defines who responds and how to revoke keys. Monthly review of usage patterns catches gradual abuse.
8. Document Key Ownership and Rotation Schedule
Create a registry of every API key your organization uses, who owns it, and when it was last rotated.
Minimum fields: Service name, key ID, owner email, creation date, last rotation date, next rotation due date, permission scope.
What good looks like: Every key has a documented owner. Keys older than 90 days flagged for review. Automated reminders sent to owners 14 days before rotation due. This supports SOC 2 Type II CC6.1 (logical access controls).
9. Test Key Revocation Procedures
Verify you can quickly revoke a compromised key without breaking production services.
Test scenario: Rotate a non-critical key during business hours. Measure time from revocation decision to new key deployed.
What good looks like: Revocation takes less than 30 minutes. Zero production impact. Process documented in incident response playbook. Team has practiced this within the last quarter.
10. Review Keys in Container Images and Infrastructure-as-Code
Check Dockerfiles, Kubernetes manifests, Terraform configurations, and CloudFormation templates for hardcoded credentials.
Common locations: ENV statements in Dockerfiles, inline strings in Terraform, base64-encoded secrets in K8s YAML.
What good looks like: Container images contain no secrets. IaC references secret manager ARNs or parameter store paths. Build process injects secrets at deploy time, not build time.
Common Mistakes
Treating API keys as "not that sensitive": The Gemini AI incident proves that yesterday's low-risk credential becomes today's data breach vector as services add capabilities.
Rotating keys without revoking old ones: If you generate a new key but leave the old one active, you've doubled your exposure window.
Scanning only production repositories: Development and testing repos often contain real keys that developers copied for convenience.
Assuming secret scanning catches everything: Pattern-based tools miss keys that don't match standard formats. Manual review of config files remains necessary.
Storing secrets in "private" channels: Slack messages, internal wikis, and shared documents are not secret management systems. They lack audit logs, access controls, and rotation workflows.
Next Steps
After completing this checklist:
- Prioritize remediation by risk: Public repositories first, then private repos with broad access, then internal tools.
- Set a 90-day rotation policy for high-privilege keys, 180 days for read-only keys.
- Schedule quarterly audits to catch keys added since your last review.
- Add secret management training to your developer onboarding—most leaks are accidental.
- Review your key permissions monthly as services add new API capabilities that your existing keys might access.
The window between "harmless configuration value" and "critical vulnerability" is closing. Your audit cadence needs to match the pace at which third-party services add features to existing APIs.
