Environment Variable Leak Conversation Audit

The scan included compact user histories and richer conversation transcripts because environment-variable exposure can happen in assistant messages, tool outputs, or generated docs rather than only in user prompts.

The first-pass scanner found 13,314 raw secret-like candidates and 2,890 deduplicated candidate matches. Many were false positives such as code variables named key, token, or animation state. The report therefore relies on confirmed repo records, high-confidence credential shapes, and correction history rather than treating every candidate as a leak.

1. Production credential as routine workflow input

The kanban workflow originally required POKETOWORK_DATABASE_URL for standard operations. That put a raw database credential into the same operational lane as board discovery, card creation, validation, and test documentation.

2. Direct script bypassed app-layer auth and scoping

The archived migration brief says the standalone script executed direct SQL via Neon and bypassed application permission checks. This made the DB URL both powerful and operationally necessary.

3. Validation artifacts copied live setup state

The validation results doc preserved how tests were run. Before cleanup, that included a resolved credential-bearing export instead of a placeholder. This is the direct tracked-file leak path.

4. Secret scanning happened after review, not before commit

The credential was caught by expert review and then removed. The evidence implies there was no reliable gate at the moment docs were written, staged, or committed.

5. Tool output was treated as safe source material

Session transcripts show commands like installers, search, test runners, and validation outputs repeatedly printing env names, setup instructions, and sometimes credential-shaped values. Tool output then became model-visible source material for summaries and docs.

6. User warnings were not converted into automatic controls

History contains direct user warnings about not reading .env.local values and not leaking secrets. Those warnings reduced ambiguity but did not create mechanical checks. The later lesson fixed the instruction layer; the remaining gap is enforcement.

2026-03-02 user prompt: "woah, you should not be looking at environment variables, they're secret right"

2026-04-01 user prompt: "ok I've added the env vars. Remember they're meant to be secret, do not look at them."

2026-04-06 user prompt: "can you identify how many times secrets were leaked and what we can do to prevent this from happening in the future? Can you also inventory what needs to be rotated?"

2026-04-14 user prompt: "will the test leak any env vars?"

2026-05-03 user prompt: "did you read the secret? Did you leak them?"

Representative redacted leak shape found in history: DATABASE_URL=<redacted postgres URL with credentials>. Representative safe replacement now present in current docs: poketo auth login or export POKETO_API_KEY="pk_...". The report intentionally does not include old resolved values.

Recommended next command: $targeted-skill-builder secret-safe documentation and tool-output gate for ship/exec workflows. Likely owner surface: shared execution/shipping contracts plus validation scripts. Minimum validation: a layer1 contract test with fake secret fixtures and a focused command-output redaction smoke.

1. Secret-safe docs/handoff gate. Before any report, test result, task doc, final answer, or commit, scan for URL credentials, sensitive env assignments, provider token prefixes, and password-like query params.
2. Tool-output redaction filter. Treat command output as untrusted when it contains env/config/dotenv text. Redact before summarizing or writing it.
3. Env-file access boundary. Default to .env.example, schema validation code, or variable names. Reading live .env files should require explicit user intent and should never print values.
4. Direct-DB fallback quarantine. Keep kanban.mjs fallback/admin-only, with active docs and skills using poketo kanban.
5. Historical leak handling rule. When a prior commit removed a credential, report commit/path metadata only. Do not run patch-view commands that could reprint deleted secret content unless the user explicitly asks for forensic history rewriting.

Assumption: Conversation history and repo artifacts are sufficient to identify the main leak path. This is strong because task history and commit metadata explicitly name the tracked credential leak.

Gap: I did not inspect the deleted patch hunk from commit 72fdc1ad, so I cannot classify the exact credential string beyond what repo records state: a Neon database credential in docs/kanban-test-results.md. That omission is intentional to avoid re-disclosure.

Gap: The broad scanner counted candidate secret-shaped matches, not confirmed secrets. Counts should be used to prioritize guardrails, not to infer exact rotation inventory.

Residual risk: Git history may still contain the old value unless history was rewritten outside the observed artifacts. The evidence only proves scrub + rotation, not complete historical erasure.

Review Gates