agent ran papermill with secrets in the parameters cell: leaked into the output notebook

TL;DR

A parameters cell is convenient, so agents put real credential values there, and papermill faithfully copies those values into every output notebook it writes, spreading the secret to logs, artifacts, and anyone with read access. Rotate the exposed secret immediately, then delete or scrub every output notebook that contains it. Going forward, keep only parameter NAMES with placeholder defaults in the cell and inject real values at runtime from the secret store, never writing them into any notebook file.

agent ran papermill with secrets in the parameters cell: leaked into the output notebook

Use this when

• An output notebook contains a real credential value in its parameters or injected-parameters cell.
• Papermill logs or artifacts show secret values in plain text.
• An agent's pipeline passes secrets as cell contents rather than runtime parameters.

Not for this skill when

• A secret was committed to git in a plain script. That is a git-secret problem (rotate, rewrite history), not a papermill problem.
• Papermill coerces a parameter to the wrong type. That is a type-coercion bug, a different fix.

Steps

1. Contain first: rotate the exposed secret at the provider so the leaked value is dead. Expected: the old value no longer authenticates anywhere.
2. Find every copy: search output notebooks, logs, and artifact stores for the leaked value's shape (do not paste the value into chat or tickets). Expected: a complete list of files that must be scrubbed.
3. Scrub the artifacts: delete output notebooks containing the value, or regenerate them after the fix; purge affected log lines. Expected: no remaining artifact contains the live (now rotated) value in plain text.
4. Rewrite the parameters cell to hold only names and non-sensitive defaults, with placeholder markers where secrets go. Expected: the source notebook contains zero real credential values.
5. Inject at runtime: pass secrets via the papermill command line or a parameters file that is never committed, sourced from the secret store at run time. Expected: papermill runs with the secret supplied outside any notebook file.
6. Verify the new output: run papermill and inspect the output notebook's parameters cells. Expected: placeholder markers or injected-parameter names only, no real values.
7. Add a pre-run check to the agent: scan the parameters cell for anything shaped like a real secret before executing. Expected: the pipeline refuses to run with baked-in values.

Tool compatibility

papermill 2.x; nbclient 0.10.x; any secret store or CI secret mechanism for runtime injection.

Variant phrasings

papermill parameters cell leaked credentials

The leak phrasing. Rotate, scrub artifacts, then inject at runtime.

secret in papermill output notebook

The artifact phrasing. Output notebooks inherit whatever the parameters cell held.

papermill pass secrets without hardcoding

The how-to phrasing. Names in the cell, values from the secret store at runtime.

Why it happens

Papermill's parameter mechanism is textual: it writes an injected-parameters cell containing the values it was given into the output notebook, because reproducibility demands that the output record what ran. When the input values are real secrets, reproducibility and secrecy collide, and reproducibility wins silently, copying the secret into every output artifact, log tail, and downstream copy. Agents reach for the parameters cell because it is the most visible place to put a value, not realizing the output notebook is a publication surface. The fix separates the two concerns: the notebook declares parameter names, and the secret store supplies values at the last possible moment, outside any file that gets persisted.

Edge cases / pitfalls

• Rotating the secret is step one, not an afterthought. Scrubbing artifacts while the value still works leaves the exposure live.
• Parameters files passed to papermill can leak the same way if they are committed or logged. Keep them out of version control and out of logs.
• Injected values still appear in process listings and some CI logs. Prefer the secret store's native integration over command-line flags where available.
• Do not 'verify' the fix by grepping artifacts for the real value in a shared terminal history. Verify with placeholder markers and redacted patterns.

Provenance

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