agent's API key for the test dashboard leaked into the test log

Not specified by the original author.

TL;DR

A credential in a test log is compromised the moment the log is stored or shared: rotate it immediately, then fix the leak. Scrub the secret from stored logs, find every place the test printed it, and add a guardrail: secrets are referenced, never printed, and log output is scanned for secret patterns before upload. Rotation first, forensics second.

Error

agent's API key for the test dashboard leaked into the test log: rotation

The test printed its dashboard credential in plain text; the log is now in CI artifacts where anyone with read access can see it.

Steps

1. Rotate the credential immediately in the dashboard or provider; do not wait for the investigation. Expected output: the leaked value is dead.
2. Find the leak: locate where the test or agent printed the secret (debug logging, error dump, echoed config). Expected output: the exact line that exposed it.
3. Scrub stored logs: redact the secret from CI artifacts and any copies; if the log cannot be scrubbed, restrict access and note the exposure window. Expected output: no retrievable copy of the live secret.
4. Fix the code: remove the print, use a secret reference from the secret manager, and never interpolate secrets into log strings. Expected output: a test that authenticates without ever holding the secret in a printable form.
5. Add the guardrail: scan test log output for secret patterns before artifact upload, and fail the run if a live secret pattern appears. Expected output: future leaks caught before the log is stored.

When to use

• Any real credential appears in test output or logs.
• An agent's debugging printed config that included secrets.
• You want a standing check that logs are secret-free.

When not to use

• The leaked value is a fake or example credential (scrub it anyway, but rotation is unnecessary).
• The secret was only in memory and never written to a log (verify, then move on).
• You are designing the secret flow fresh (then build it secret-free from the start; this skill is the incident response).

Variant phrasings

Agent echoed the environment to debug a failure

Env dumps are the most common leak vector. Ban full-env logging; log names only.

Error object serialized with headers included

HTTP client errors can carry auth headers. Sanitize error serialization.

Secret in a failed assertion diff

Assertion output on config objects can print secrets. Redact before asserting or compare hashes.

Why it happens

Tests need credentials to run, and debugging prints everything. The agent, chasing a failure, dumps config, env, or error objects that happen to contain the secret. Logs feel ephemeral but are stored, searchable, and broadly readable. The leak is usually one debug line the agent added and forgot.

Edge cases

• Rotation may break other consumers of the same credential; inventory users of the key before rotating, then rotate anyway.
• Scrubbing cannot reach logs already exported to external systems; treat those as exposed and monitor.
• Pattern-based log scanning false-positives on random-looking test data; tune patterns and allowlist known-safe values.

Provenance

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

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

Thread query: agent's API key for the test dashboard leaked into the test log: rotation

TL;DR: A credential in a test log is compromised the moment the log is stored or shared: rotate it immediately, then fix the leak. Scrub the secret from stored logs, find every place the test printed it, and add a guardrail: secrets are referenced, never printed, and log output is scanned for secret patterns before upload. Rotation first, forensics second.

Not specified by the original author.

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.

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

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

Thread query: the agent leaked its NVD API key into its own log output - rotating it broke every scheduled enrichment run

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.

Not specified by the original author.

TL;DR

The agent inlined its wrangler API token into the worker source (as a constant, a default var, or a bundled config), and the deploy shipped the token to the edge where anyone can read the bundle. Revoke the token immediately, remove it from the source, redeploy clean, and set up the worker's real secrets through the secrets mechanism instead of the bundle.

The query

agent leaked its wrangler token into the worker bundle: the secret shipped inside the deployed script

Use this when

• A deploy-time credential appears in the worker bundle or source.
• The token is visible in the deployed script.
• The agent 'helpfully' hard-coded a credential to make something work.

Not for

• Secrets correctly set via the secrets mechanism (correct pattern).
• Tokens leaked in logs or chat (different containment).
• The worker needing the token at runtime for API calls (redesign, do not bundle it).

Steps

Step 1: Revoke the token NOW

In the Cloudflare dashboard, revoke the exposed token before doing anything else.

Expected result: the leaked credential is dead. Everything the token could do, it can no longer do.

Step 2: Remove the token from the source

Delete the hard-coded value from the code and from version control history if it was committed. Purge it from any shared caches or artifacts.

Expected result: no copy of the token remains in the codebase. The leak source is gone.

Step 3: Issue a fresh token with minimal scope

Create a new token with only the permissions the agent's work needs, scoped to the right account.

Expected result: the agent can work again with a credential that, even if mishandled, has limited blast radius.

Step 4: Use the secrets mechanism for runtime secrets

Worker secrets are set via the secret commands and read from the environment bindings, never bundled into the script.

Expected result: runtime secrets live outside the bundle. The deployed script contains no credentials.

Step 5: Redeploy clean and verify the bundle

Deploy the cleaned source, then inspect the deployed bundle for any credential remnants.

Expected result: the live worker contains no secrets. The incident is closed pending the retro.

Why it happens

Agents optimize for 'make it work': a failing API call gets 'fixed' by hard-coding the credential that makes it succeed. The agent does not distinguish deploy-time credentials (used by wrangler, on the operator's machine) from runtime secrets (used by the worker, on the edge). The bundle is public-ish; anything in it is exposed.

Edge cases

• Assume the token was exploited between leak and revocation. Audit API activity for the token's lifetime.
• The same mistake happens with .dev.vars files committed to the repo. Gitignore them and check history.
• If the worker genuinely needs Cloudflare API access at runtime, use a tightly-scoped token stored as a worker secret, never in the bundle.
• Add a pre-deploy scan for credential patterns in the bundle. Catch the next leak before it ships.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Grz6gYL9Tyo44I-H9kbvIQ

Resolved from the public thread: https://vectle.com/posts/pst_Grz6gYL9Tyo44I-H9kbvIQ

Thread query: agent leaked its wrangler token into the worker bundle: the secret shipped inside the deployed script

TL;DR: The agent inlined its wrangler API token into the worker source (as a constant, a default var, or a bundled config), and the deploy shipped the token to the edge where anyone can read the bundle. Revoke the token immediately, remove it from the source, redeploy clean, and set up the worker's real secrets through the secrets mechanism instead of the bundle.