You can, but it trades convenience for trust. Jupyter stores a signature for each notebook whose outputs you produced, and that database is private to you by default. Sharing it means one person's trust decision applies to everyone who uses it, so only share it inside a group that trusts its writers.
Definition
Jupyter's security model says no code should execute just because a user opened a notebook they did not write. Untrusted HTML is sanitized, untrusted JavaScript is never executed, and HTML or JavaScript in Markdown cells is never trusted. The central question is whether the current user produced the output.
When a notebook is executed and saved, Jupyter computes a signature from a digest of its contents plus a secret key. The signature goes into a database writable only by the current user. On open, the server recomputes the signature and checks the database. A match means the HTML and JavaScript outputs are trusted at load.
Why collaboration is awkward
Each collaborator has a different key, so a notebook from a colleague starts untrusted for you. The Jupyter documentation lists three ways to deal with it:
| Approach | Cost | Risk |
|---|---|---|
| Re-run the notebook | Time, and data or dependencies may be missing | Lowest, and you run the code knowingly |
| Explicitly trust it with the trust command or the menu | A manual step per notebook | Depends on you having read it |
| Share a signatures database | None after setup | One writer can make notebooks trusted for all |
What sharing really means
The setting is a data directory for the notary, which points to a different location for the SQLite database. If that folder is writable by several accounts, any of them can add signatures. A signature only says that someone with the shared setup executed or trusted those outputs.
So shared trust is a team policy decision. It makes sense when:
- A small group works on one project and reviews each other's changes.
- The database sits in a folder with tightly controlled permissions.
- The shared setting applies only to that project, as the documentation suggests, using configuration dedicated to the collaboration.
It does not make sense across a whole department, a classroom, or a server with untrusted users.
Steps for a team
- Decide if re-running is feasible. If it is, prefer it.
- If not, use explicit trust only after reading the notebook source and outputs.
- If you share the database, scope it to one project and restrict write access.
- Write the rule down, including who may add signatures.
- Treat any notebook from outside the group as untrusted, whatever the database says.
Remember that trust here protects against code running when a notebook opens. It does not stop code you choose to run. Once you execute cells, the notebook can do anything your account can.
For the single user version of this question see /resources/blog/is-it-safe-to-open-an-untrusted-jupyter-notebook.
Safeguard's policies and gates are about code and dependencies in your repositories, not the Jupyter trust database. Use the free scan at gold.safeguard.sh/scan on the projects the notebooks live in.
Quick check
Is the notebook signature a malware check?
No. It records that output was produced or trusted by the current user, not that the code is harmless.
Where is the signatures database by default?
In a file named nbsignatures.db in the user's Jupyter data folder, which differs by operating system.
Sources
- Security in the Jupyter Server, Jupyter documentation, fetched 19 October 2026.
Last reviewed: 19 October 2026.
