What happens when an API key is leaked publicly

You pushed a commit with a live API key to a public repository. Or a teammate pasted one in a Slack channel that gets indexed. Maybe a CI log printed it in plain text. When a leaked API key what to do becomes an urgent question, you need a practiced sequence, not panic. This guide walks through the exact steps to contain the blast radius, rotate credentials safely, and harden your pipeline so it doesn’t happen again.

Revoke the compromised key immediately

The first action is always revocation. Every minute the key remains valid is a minute an attacker can burn your quota, exfiltrate data, or poison your fine-tuning runs. Most providers offer instant revocation via dashboard or API.

# OpenAI example
curl -X DELETE https://api.openai.com/v1/api_keys/sk-... \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# Anthropic example
curl -X DELETE https://api.anthropic.com/v1/organizations/$ORG_ID/api_keys/$KEY_ID \
  -H "x-api-key: $ADMIN_TOKEN" \
  -H "anthropic-version: 2023-06-01"

If you manage keys through a gateway like n4n.ai, revoke at the gateway layer first — it cuts access across all 240+ downstream providers in one call. Then revoke at each provider as a belt-and-suspenders measure.

Pitfall: Deleting the key from your .env file or secret manager does not revoke it at the provider. The key remains active until the provider invalidates it.

Rotate to a new key with zero downtime

Revocation breaks existing workloads. Plan the rotation so production doesn’t stall.

1. Generate the replacement key before revoking the old one, if your provider allows multiple active keys per account. OpenAI, Anthropic, and most others support this.
2. Stage the new key in your secret manager (Vault, AWS Secrets Manager, 1Password, Doppler) with a distinct version label.
3. Deploy the new version to your fleet using your standard config-reload mechanism — SIGHUP, rolling restart, or feature flag flip.
4. Verify health on a canary subset before full rollout.
5. Revoke the old key only after 100% of traffic uses the new one.

# Example: Kubernetes deployment with versioned secret
apiVersion: v1
kind: Secret
metadata:
  name: llm-api-key
  labels:
    version: "v2024-01-15"
type: Opaque
stringData:
  OPENAI_API_KEY: "sk-newkey..."

Tradeoff: Running two keys simultaneously expands the attack surface briefly. Keep the overlap window under 10 minutes. If your provider doesn’t support multiple keys, schedule a maintenance window and accept brief downtime.

Audit usage since the leak timestamp

You need to know what the attacker actually did. Pull usage logs from every provider the key accessed. Look for:

• Requests from unfamiliar IP ranges or ASNs
• Spikes in token consumption, especially at odd hours
• Calls to expensive models (GPT-4, Claude 3 Opus) you don’t normally use
• Embedding or fine-tuning jobs you didn’t initiate
• Admin API calls (key listing, user management, billing changes)

# Fetch OpenAI usage for a date range
import os, requests
from datetime import datetime, timedelta

end = datetime.utcnow()
start = end - timedelta(days=7)

resp = requests.get(
    "https://api.openai.com/v1/usage",
    headers={"Authorization": f"Bearer {os.getenv('ADMIN_TOKEN')}"},
    params={
        "start_date": start.strftime("%Y-%m-%d"),
        "end_date": end.strftime("%Y-%m-%d"),
    },
)
print(resp.json())

Export the raw logs to your SIEM or a notebook for correlation. If you route traffic through a gateway that meters per-token usage, you already have a unified audit trail across providers — one query instead of five.

Common pitfall: Provider usage APIs often lag by hours. Don’t assume real-time visibility. Check again at 24h and 72h marks.

Rotate any derived credentials

An API key often unlocks more than direct model calls. Check for:

• Webhook secrets used to verify provider callbacks
• Organization-level tokens with admin scope
• Fine-tuning job credentials stored in training pipelines
• Embedding model keys used by vector DB sync jobs
• Proxy/gateway tokens if you run a local relay

Treat each as a separate secret with its own rotation schedule. A leaked inference key doesn’t automatically compromise your webhook secret, but if both were in the same .env file, assume both are burned.

Scan for lateral exposure

The leak rarely stops at one key. Run these checks:

# 1. Git history — the key may exist in prior commits
git log --all --full-history --oneline -- "**/.env" | head -20
git log --all -p -- "**/*.py" | grep -i "sk-" | head -10

# 2. CI/CD logs — many runners print env vars on failure
# Check CircleCI, GitHub Actions, GitLab CI, Buildkite artifact retention

# 3. Container images — keys baked into layers
docker history your-image:tag --no-trunc | grep -i "api_key\|secret"

# 4. Shared notebooks / Colab / Databricks exports
# 5. Terraform state files (local backend or unencrypted S3)
# 6. Kubernetes secrets in etcd backups

Tooling: Use git-secrets, truffleHog, or gitleaks in pre-commit and CI. They catch patterns like sk-[a-zA-Z0-9]{48} before merge.

Notify stakeholders per your incident policy

Document the timeline: leak timestamp, discovery method, revocation time, rotation completion, audit findings. Share with:

• Engineering lead — owns the fix
• Security team — tracks for compliance (SOC 2, ISO 27001)
• Finance — monitors for billing anomalies
• Legal — assesses notification obligations if PII was processed

If the key accessed customer data, you may have breach notification duties under GDPR, CCPA, or sector-specific rules. Involve legal early.

Harden the pipeline so it doesn’t recur

The leak is a symptom. Fix the cause.

Remove secrets from developer machines

Developers shouldn’t hold production keys. Use:

• Short-lived tokens minted by a local daemon (e.g., aws-vault style) that exchanges a developer’s SSO session for a 1-hour provider token
• Remote development environments (GitHub Codespaces, Gitpod, Coder) where secrets inject at runtime, never touch disk
• CLI tools that fetch from secret manager on demand — doppler run -- python app.py, op run -- ./scripts/train.py

# Example: 1Password CLI injects at runtime, no .env file
op run --env-file=.env.template -- python -m llm.train

Enforce secret scanning in CI

# .github/workflows/secret-scan.yml
name: Secret scan
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Block merges on findings. No exceptions.

Use scoped, short-lived keys per workload

One root key for everything is a single point of failure. Most providers now support:

• Project-scoped keys — limited to one project ID
• Read-only keys — embeddings only, no completions, no admin
• IP-allowlisted keys — only your egress NAT ranges
• Rate-limited keys — hard cap at expected max QPS

// Anthropic: create a scoped key via API
{
  "name": "prod-embeddings-worker",
  "role": "user",
  "expires_at": "2025-01-15T00:00:00Z",
  "metadata": {
    "team": "ml-platform",
    "purpose": "embedding-pipeline"
  }
}

Rotate scoped keys on a 30-day cadence via automation. Root keys rotate quarterly and require break-glass approval.

Centralize egress through a gateway

Routing all LLM traffic through a single gateway gives you:

• One place to revoke — kill a compromised key across 240+ models instantly
• Unified audit logs — one query spans OpenAI, Anthropic, Cohere, together
• Automatic fallback — if a provider degrades, traffic shifts without new credentials
• Cache-control forwarding — provider hints pass through so your cache layer stays coherent
• Client routing directives — your code specifies x-n4n-model: gpt-4o and the gateway handles the rest

This doesn’t eliminate key management, but it reduces the blast radius of any single leak.

Test your incident response quarterly

A runbook you’ve never executed is fiction. Schedule a game day:

1. Plant a canary key in a test repo
2. Trigger your secret scanner alert
3. Time the team: detection → revocation → rotation → audit complete
4. Measure: did staging break? Did prod notice? How long was the overlap window?
5. Update the runbook with gaps found

Target: full containment under 15 minutes for a key with production scope.

Summary checklist

The leaked API key what to do question has a boring answer: practiced muscle memory. Revoke fast, rotate clean, audit thoroughly, then fix the system that let it leak. Everything else is noise.