---
name: detector-credential-leakage
description: |
  Self-check whether your submission ships a credential inside its authored
  surfaces — above all `environment/workspace.patch`. Mainly one job: find
  leaked keys, tokens and secrets. Deterministic pattern checks hard-flag your
  authoring environment's own env vars (`ANTHROPIC_API_KEY`,
  `ANTHROPIC_BASE_URL`, `USER_ID` as an env assignment) and well-known secret
  shapes (`sk-ant-…`, AWS `AKIA…`, GitHub `ghp_…`, Google `AIza…`, Stripe
  secret keys, bearer tokens, private-key blocks, URL-embedded passwords) on
  lines your patch adds; a placeholder test then clears dummies, `.env.example`
  files, dev defaults and code identifiers. A `credential-leak` must be fixed
  before submitting AND the key reported for rotation, since removing the line
  doesn't un-ship it; `suspicious-content` is advisory. A second, narrow check
  flags an absolute path from your own machine that continues into your checkout
  on a line your patch adds (`/home/you/.../worker-toolkit-x/repo/...`) — a
  patch is repo-relative, so such a path only gets in by accident: that's
  `internal-leak`, fix it before submitting, nothing to rotate. The report never
  reproduces secret values. Reads workspace.patch (+ Dockerfile,
  instruction.md, tests/*.md); runs before or after reference runs exist.
allowed-tools: Bash, Read, Write
---

# Credential-leakage detector

This skill checks one of your tasks for **a leaked credential** — a key, token
or secret swept out of your authoring environment into the submission's
authored surfaces, above all `environment/workspace.patch`. Everything your
patch adds ships to everyone downstream, so a leaked key is compromised the
moment you submit, and scrubbing it afterwards doesn't undo that. It also
catches one closely-related shape: an absolute path from your own machine.

The failure shapes to catch:

- **Your toolkit `.env`** — your personal `ANTHROPIC_API_KEY`,
  `ANTHROPIC_BASE_URL` and `USER_ID` landing in the workspace as a new `.env`
  file, a `.env.bak-*` backup, or a symlink to `/home/<you>/.env`.
- **Any real third-party secret** the patch adds — an AWS or Google key, a
  GitHub token, a Stripe secret key, a private-key block, a captured request
  carrying a live `Authorization: Bearer …`, a database URL with the password
  embedded.
- **An absolute path from your machine into your checkout**, on a line your
  patch adds — `/home/you/…/worker-toolkit-<repo>/repo/app/foo.rb`. A patch is
  repo-relative by construction, so this only ever gets in by accident: a
  coverage report keyed by your file paths, or a helper script with your
  checkout hardcoded. It ships your username and directory layout to everyone
  downstream. Rare — 2 in 350 patches.

What *doesn't* trip this check: placeholder and example values (`.env.example`
with dummies, `sk-ant-...` as a literal template), dev defaults
(`POSTGRES_PASSWORD=postgres` in a local docker-compose), code identifiers
(`USER_ID = 4958` as a test constant, or any variable merely *named* `SECRET`
or `TOKEN`), and secrets on context or removed lines — those belong to the
source repo, not to you.

Nor do generic paths that name no person and no checkout — `/home/runner/work/…`
in a CI workflow, `/home/ubuntu/<app>` in a deploy config, `/home/app/…` in a
compose volume — which real repos legitimately commit.

Also out of scope, and never reported here: authoring artifacts
(`.raccoon-setup-done`, `.claude/settings.local.json`, stray logs) and patch
content that simply doesn't relate to the task.

Read these before deciding:

1. `.claude/skills/_detector-worker-shell.md` — where to write the report and how to handle re-runs.
2. `.claude/skills/detector-credential-leakage/core.md` — the deterministic pattern checks to run, the placeholder test, the redaction rule (never quote a secret value), what is NOT a finding, the out-of-scope list, verdict enums, and the body schema.

Compose the report per the schema in `core.md` and write it per `_detector-worker-shell.md`.

## Acting on the verdict

- **`clean`** — nothing your patch adds looks like a credential. Good, move on.
  This is the normal answer.
- **`suspicious-content`** — no confirmed credential, but something
  credential-shaped couldn't be resolved: a captured request with a real (if
  low-sensitivity) token, a config file of credential-shaped values. Replace
  the value with a placeholder, drop the file, or satisfy yourself it's
  genuinely scenario material.
- **`credential-leak`** — a real credential (or your authoring env vars) is in
  the patch. Act before submitting: (1) remove the material and regenerate the
  patch with `bash scripts/check-workspace-sync.sh --update-patch
  harbor-tasks/<slug>`; (2) re-run this detector to confirm it's gone;
  (3) report the leaked value through your support channel so it can be
  rotated — scrubbing the patch does not un-ship a key that already left your
  machine in an earlier submission.
- **`internal-leak`** — your patch adds an absolute path from your own machine
  into your checkout. Fix before submitting: remove or relativize the path (or
  drop the file, if it's a generated artifact like a coverage report),
  regenerate the patch, and re-run this detector. Nothing to rotate.
- **`not-applicable`** — there's no workspace patch to assess yet. Build the
  workspace first.