The Script Security plugin controls how non-administrators run custom Groovy in Jenkins. The sandbox checks every method call, constructor and field access against a whitelist and blocks the rest. Script approval lets any script run, but only after an administrator approves it. Both route risky operations to an admin.
Definitions
Sandbox. A Groovy script that has Use Groovy Sandbox checked can run without approval, provided it only performs operations on the whitelist. Everyone, including administrators, is under the same restrictions.
Script approval. Any kind of script can run after an administrator approves it. Approved scripts go on a global list. An unapproved script fails when it runs, usually with a message that approval is pending.
Whitelist. The default list is small. Plugins can add operations to it.
Sandbox versus approval
| Question | Sandbox | Script approval |
|---|---|---|
| Who can run it | Anyone, if every operation is whitelisted | Anyone, after admin approval of the script |
| Languages | Groovy only | Any script type |
| What the admin approves | Individual operation signatures | The whole script text |
| Default posture | Blocks unknown operations | Blocks unapproved scripts |
Other languages have no sandbox, so their scripts must always be approved.
How an admin should approve
Blocked operations land in a queue on the In-process Script Approval page, under Manage Jenkins. An admin can approve a specific signature, which adds it to the whitelist for everyone.
The plugin documentation gives two cautions. Do not whitelist operations that change the state of persisted objects, such as Jenkins jobs. Most methods named getSomething are described as harmless, but some perform permission checks, and the assuming permission check option should only be used when you know Jenkins performs that check.
The plugin also no longer auto-approves scripts an administrator saves, a change made to prevent social engineering.
A stricter setting
For highly secured installations, there is an option to force the sandbox globally. It requires sandboxed scripts only and blocks creating new items on the approval screen.
What this does not do
The sandbox restricts what a script may call. It is not a general container for untrusted builds. Build steps such as shell commands still run on the agent with that agent's permissions, which is why agent isolation and credentials scoping matter as much as the sandbox. Keep Script Security current as well: sandbox bypasses are a recurring class of Jenkins advisory, so apply plugin updates promptly.
Quick check
Should I approve a script because a developer asks?
Read it first. Approval means the script can do whatever its code does, with no sandbox limits.
Is sandboxed Groovy safe to run from any user?
It is designed for that, but it depends on the whitelist staying tight and the plugin staying patched.
Safeguard can check the dependencies and plugins listed in your build inputs and enforce policies and gates on the results. Try the free scan on a repository to see what it finds.
Sources
Last reviewed: 19 October 2026.
