Papermill takes a notebook, adds a cell holding your parameter values, and executes the notebook in order. So a parameterized run executes all the code in the file, not just the parameter cell. A scheduled notebook is a scheduled program, and it needs the same review and access controls as one.
How injection works
The papermill documentation explains that it inserts a new cell tagged injected-parameters immediately after the cell tagged parameters. The injected cell contains only the overridden parameters. If no cell carries the parameters tag, the injected cell goes at the top of the notebook. Cells then run in order, so injected values take effect after the parameters cell has already run its own defaults.
The documentation example runs papermill note.ipynb -p a 9 and produces output reflecting the new value of the parameter.
Why this is a security topic
Teams move notebooks into production using schedulers, because analysts already know the format. At that point the notebook is the job. Three things follow.
First, anyone who can edit the notebook can change what the job does, including adding a cell that reads environment secrets or writes data elsewhere.
Second, parameter values flow into the code. If a value comes from a form, a ticket or a message, treat it as input. Do not use it to build SQL text, shell commands or file paths without validation.
Third, a notebook carries its outputs. Saved outputs can hold sensitive rows, tokens printed by accident, or file paths, and that file gets copied to output storage with the executed results.
A review checklist for scheduled notebooks
| Area | Check |
|---|---|
| Source | Stored in version control, not edited on the server |
| Review | Changes need a second reviewer like any production code |
| Parameters | Typed, validated and limited to expected values |
| Secrets | Read from the scheduler's secret store, never typed into a cell |
| Environment | Pinned dependencies and a minimal container |
| Outputs | Executed copies written to a restricted location and cleaned of sensitive data |
| Permissions | The job's service account can read only what the notebook needs |
Parameter validation example
# parameters cell
region = "us"
days = 7
# first code cell after injection
assert region in {"us", "eu", "apac"}
assert isinstance(days, int) and 1 <= days <= 90
Failing fast on unexpected values is cheap, and it turns a quiet misuse into a clear error.
Related practices
Strip outputs before committing source notebooks, and see the existing guidance on cleaning notebook outputs before you commit. Pin the packages the notebook imports, and keep a record of which environment each run used.
Where Safeguard fits
Safeguard's dependency scanning and SBOM generation can inventory the packages a notebook project depends on once they are listed in a manifest. You can try a free scan on the repository.
Quick check
Does papermill sandbox the notebook?
The documentation reviewed here does not describe a sandbox. Run notebooks in a container with limited access.
Is the injected cell visible in the output?
Yes. It is a tagged cell in the executed notebook, which helps you record what values a run used.
Sources
Last reviewed: 19 October 2026.
