---
name: detector-credential-leakage
description: |
  Self-check whether your submission ships credentials or other content from
  your authoring environment inside its authored surfaces — above all
  `environment/workspace.patch`. Two tiers. (1) **Known-credential tier
  (deterministic):** hard-flags 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. The canonical
  incident: your toolkit `.env` — your personal API key, proxy URL, and user
  id — swept into the workspace as a new `.env` file. (2) **Task-relevance
  tier (judgment):** content your patch adds that doesn't appear to serve
  the task — `.env`-style files, env-file symlinks into your home directory,
  `export FOO=` lines, credential-shaped assignments with real values. A
  `credential-leak` finding must be acted on before submitting (remove the
  material AND report the key as compromised so it can be rotated);
  `suspicious-content` findings are advisory. 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 **credential leakage** — whether
anything from your own authoring environment (or any other secret) has been
swept 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: deleting the
line later does not un-ship it.

The failure shape to catch: your toolkit's `.env` — the file holding your
personal `ANTHROPIC_API_KEY`, `ANTHROPIC_BASE_URL`, and `USER_ID` — landing in
the workspace as a new `.env` file (or a `.env.bak-*` backup, or a symlink to
`/home/<you>/.env`). It happens easily: a stray `git add`, a working-tree
backup, a captured terminal snippet. None of it serves the task; the test
agent has no network to use a key with; and the key is now distributed.

What *doesn't* trip this check: placeholder and example values
(`.env.example` with empty or dummy entries, `sk-ant-...` as a literal
template, `changeme`), dev-infrastructure defaults (`POSTGRES_PASSWORD=postgres`
in a local docker-compose), code identifiers (`USER_ID = 4958` as a test
constant), and env vars your task's scenario genuinely needs documented.

**Severity differs by tier.** Unlike most self-checks, a `credential-leak`
finding is not a consideration: remove the material from the patch, rebuild it
(`bash scripts/check-workspace-sync.sh --update-patch harbor-tasks/<slug>`),
and report the leaked credential through your support channel so it can be
rotated — treat it as compromised even after you scrub it.
`suspicious-content` findings are the usual advisory kind: read each one and
fix or justify it.

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 two tiers, the deterministic pattern checks to run, the placeholder test, the redaction rule (never quote a secret value), what is NOT a finding, 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 or foreign
  content. Good. Move on.
- **`suspicious-content`** — no confirmed credential, but something your patch
  adds doesn't look like it belongs to the task: an env-file symlink into your
  home directory, a captured request with a real (if low-sensitivity) token, a
  config file of credential-shaped values. Fix each finding (replace tokens
  with placeholders, drop the file, or make its task relevance explicit) or
  satisfy yourself it's genuinely scenario material.
- **`credential-leak`** — a real credential or your authoring environment's
  own env vars are in the patch. Act before submitting: (1) remove the
  material and regenerate `workspace.patch`; (2) re-run this detector to
  confirm it's gone; (3) report the leaked value as compromised so it can be
  rotated — scrubbing the patch does not un-ship a key that already left your
  machine in an earlier submission.
- **`not-applicable`** — there's no workspace patch to assess yet. Build the
  workspace first.