agent trusted every notebook in a shared folder: XSS via malicious outputs
Prevents cross-site scripting from notebook outputs when an agent is tempted to trust every notebook in a shared folder. Verifies provenance, keeps untrusted outputs inert, and sandboxes rendering instead of blanket-trusting. This skill is defensive: it hardens the trust workflow and never helps anyone evade notebook security controls.
TL;DR
Notebook outputs can carry executable JavaScript, and trusting a notebook tells Jupyter to run it, so blanket-trusting a shared folder executes whatever the least careful contributor saved. Do not trust the folder: inspect unfamiliar notebooks, keep their outputs unrendered until verified, and view them in a sandboxed context first. The safe default is distrust; trust is granted per notebook after a human or a verified pipeline vouches for its outputs.
agent trusted every notebook in a shared folder: XSS via malicious outputsUse this when
- An agent proposes trusting all notebooks in a directory to 'fix' blocked outputs.
- Notebooks arrive from outside contributors, shared drives, or public downloads.
- You need a policy for which notebooks may execute JavaScript outputs.
Not for this skill when
- Your own notebooks are blocked after a git checkout. That is signature invalidation, a different fix.
- You want to run untrusted JavaScript anyway. This skill will not help you bypass the trust system.
Steps
- Revoke the blanket trust: untrust the folder's notebooks so their outputs stop executing. Expected: the notebooks show as not trusted and scripted outputs are inert.
- Establish provenance for each notebook: who wrote it, where it came from, and whether a trusted pipeline generated it. Expected: every notebook is labeled with its origin.
- Inspect before trusting: read the code cells and check outputs for anything that does not match the code (outputs that look hand-planted). Expected: a reviewed notebook with outputs consistent with its code.
- For notebooks you must view but not yet trust, render them through a sandboxed path: export to static HTML with scripts neutralized, or view with JavaScript disabled. Expected: you can read the content with zero script execution.
- Trust individually only after verification:
jupyter truston the specific notebook, never the directory. Expected: the trust database holds signatures for vetted notebooks only. - Write the policy down for the agent: never trust a notebook it did not generate or that a human has not reviewed; distrust is the default. Expected: the agent's instructions contain the distrust-default rule.
Tool compatibility
nbformat 5.x signing and trust; notebook 6.x/7.x and JupyterLab 3.x/4.x output sanitization; Python 3.9+.
Variant phrasings
should I trust all notebooks in a folder
The policy question. No: trust per notebook after verifying provenance.
notebook javascript output security shared folder
The security phrasing. Untrusted outputs stay inert until a notebook is vetted.
jupyter trust malicious notebook XSS
The attack phrasing. The defense is per-notebook trust plus sandboxed viewing.
Why it happens
The notebook format deliberately stores outputs alongside code, and rich outputs may include executable script content that the frontend will run once the notebook is trusted. Trust is therefore not a rendering preference; it is permission to execute. A shared folder mixes trust levels: your own exploratory work next to a colleague's download next to an agent's generated draft. Blanket-trusting the folder grants execute permission to the least vetted file in it. The trust database cannot distinguish your careful notebook from a hostile one, which is exactly why the unit of trust must stay at the single notebook, granted after inspection, and why unfamiliar notebooks get sandboxed viewing first.
Edge cases / pitfalls
- Re-saving an untrusted notebook does not sanitize its outputs. The hostile output bytes persist until the cells are re-executed or cleared.
- Clearing outputs is the strongest reset for a suspicious notebook: code without outputs cannot carry a script payload.
- Agents that 'fix' blocked outputs by trusting are optimizing for convenience over safety. Treat any such agent behavior as a bug to fix, not a workflow to bless.
- Exported HTML from an untrusted notebook can still be dangerous if opened with scripts enabled. Neutralize scripts in the export or open it with scripting off.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst7jWH0WFZOeUSsbqXJX6qg