## TL;DR
Rotate the key now, then make the leak structurally impossible: the agent reads the key from a secret store at runtime, logs redact anything shaped like a key, and no job ever carries the value in its own config. Rotation breaking every job is the symptom that the key was copy-pasted everywhere instead of sourced from one place.

```text
the agent leaked its NVD API key into its own log output - rotating it broke every scheduled enrichment run
```

## Steps

1. Rotate immediately. Generate a new NVD API key and revoke the leaked one; treat the old key as compromised from the moment it hit the logs.
   - Expected: the old key stops working; the new key is active.

2. Purge the leaked value from log storage. Find every log line containing the old key and redact or delete it; check log aggregators and retained archives, not just local files.
   - Expected: no retrievable copy of the old key remains in any log store.

3. Find every place the old key was embedded: scheduled job configs, agent prompts, scripts, CI variables, and docs. List them all before changing anything.
   - Expected: a complete inventory of every consumer of the key.

4. Move the new key into a secret store and change every consumer to read it at runtime. No job config, script, or prompt should contain the value itself - only a reference to where it lives.
   - Expected: rotating the key in one place updates every consumer with no config edits.

5. Add log redaction for key-shaped values. Configure the logging pipeline to mask the key pattern before lines are written, and add a test that logs a fake key and asserts it comes out masked.
   - Expected: future leaks are redacted at write time.

6. Audit how the leak happened: the agent likely printed its own request headers or echoed its configuration for debugging. Remove debug logging of request headers and full config dumps from the agent's code paths.
   - Expected: the code path that printed the key no longer exists.

7. Re-run one scheduled enrichment job end to end against the new key sourced from the secret store.
   - Expected: the job succeeds with no key value appearing in its logs.

## Use this when

- An API key appears in agent log output or debug traces.
- Rotating a key breaks scheduled jobs because the value was hardcoded in many places.
- The agent logs full request headers or configuration dumps.
- You cannot answer "where is this key used" without grepping the fleet.

## Not for this skill when

- The key was committed to a git repo; you also need history rewriting or revocation plus a repo sweep, which is a bigger incident.
- The exposure is suspected but unconfirmed; rotate anyway, but the purge steps assume a known leak.
- The problem is the key lacking permissions, not exposure; that is an access-scope fix.

## Variant phrasings

- API key leaked in application logs how to rotate
- agent printed secret to stdout during run
- rotating NVD API key broke cron jobs
- secret committed to logs remediation steps

## Why it happens

The key lived as a literal value in configs and prompts because that was the fastest way to make the first job work, and every later job copied the pattern. Agents are especially prone to echoing it because they log verbosely for debugging and will happily print the headers of the requests they make. One source of truth plus redaction removes both the sprawl and the echo.

## Edge cases

- Log aggregators with long retention keep the leaked value searchable for months; check retention policies, not just live logs.
- If the agent cached the old key in memory or in a state file, a config change alone will not take effect until the process restarts.
- NVD keys are per-account; if several agents shared the leaked key, rotate once and re-issue per-agent keys so the next incident has a smaller blast radius.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dWVN2OZVxJkevbowp9nHwg