ServiceNow phases out Server-Side Sandbox: guarded Scripts / Kittyscript / Server-Side Sandbox Runtime update
ServiceNow phases out Server-Side Sandbox
ServiceNow is replacing the server-side JavaScript sandbox with a locked-down runtime called Guarded Script (internal name KittyScript, abbreviated ks in property names). It restricts what code can run in sandbox contexts. SN KB in the thread.
see https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2944435
5/29/26, 12:17 PM Server-Side Sandbox Runtime Replacement - Support and Troubleshooting
9+ S
MyNow
Products
Industries
KB2944435
Learning
Server-Side Sandbox Runtime Replacement
Support
14041 Views Last updated : May 22, 2026 Customer Copy Permalink Subscribe
English (Original)
Partners
Company
KB Summary by Now Assist Summarize
Quick Summary
What you need to know:
ServiceNow is enhancing instance security by restricting the type of code that can run in server-side sandbox contexts (such as filters).
Simple scripts (basic function calls and expressions) will continue to work with no changes. Complex scripts (those using variables, if/else
logic, loops, or multiple statements) will need to be moved into a script include.
Your instance automatically identifies affected scripts in the Incompatible Guarded Scripts list (once on a version identified in the Rollout
Schedule below)
— no setup needed.
Client-side JavaScript and code inside script includes are not affected.
Guest (unauthenticated) traffic is fully enforced immediately on all upgraded instances.
On upgraded cloud instances, enforcement for authenticated traffic phases in automatically over approximately four weeks, with automatic
exemptions to protect existing functionality. On-premises instances begin detection automatically but require administrators to advance to
each enforcement phase manually.
Am I Affected?
If your instance uses any of the following, you may have scripts that need updating:
javascript: prefixes in filters, conditions, or passed to GlideRecord methods such as addQuery()
JavaScript evaluated via GlideEvaluator/GlideScopedEvaluator with withEnforcedSecurity(true)
AMB or RecordWatcher conditions with complex expressions
Not Affected
Earlier revisions of this article identified reference qualifiers and default values (including default
_
value) as potentially affected. This was
incorrect — neither is evaluated through the sandbox, so scripts in these locations are not subject to guarded script restrictions and do not need to
be remediated. This is a correction to the earlier guidance, not an exhaustive list of everything that is unaffected.
The fastest way to check: Navigate to the Incompatible Guarded Scripts list on your instance. If there are entries, those scripts need attention.
Note: The Incompatible Guarded Scripts list is only available on instances running the versions identified in the Rollout Schedule below.
What Is Changing
Background
Today, certain areas of ServiceNow allow server-side JavaScript to run in a protected environment called the sandbox. This includes places where
code runs on behalf of potentially untrusted users, such as filters.
https://support.servicenow.com/kb?id=kb
article
_
_
view&sysparm
article=KB2944435 1/7_5/29/26, 12:17 PM Server-Side Sandbox Runtime Replacement - Support and Troubleshooting
ServiceNow is releasing guarded script to enhance instance security. Guarded script will block JavaScript except for a small set of operations —
primarily simple expressions and function calls.
What Guarded Script Does Not Allow
Guarded script accepts only a single, simple expression. The following JavaScript features are not supported inside the sandbox:
Variable declarations ( var, let, const)
Control flow ( if, switch, for, while)
Function declarations
Assignment operators (=)
Multiple statements — only a single expression is allowed per script
Note: This change only affects server-side scripts that run inside the sandbox. Client-side JavaScript is not affected. Code inside script includes is also not affected, because
script includes run in the application scope, outside the sandbox.
Why This Is Happening
The current sandbox allows JavaScript from potentially untrusted sources — including unauthenticated users — to run on the server. JavaScript is a
powerful and flexible language, and that flexibility creates security risk. Even with restrictions in place, the broad nature of JavaScript means there is
always the possibility of new vulnerabilities.
Guarded script drastically reduces the attack surface by allowing only a small set of operations.
Rollout Schedule
The table below shows the ServiceNow releases that will include guarded script. Guarded script becomes active on your instance only after you
upgrade to one of these versions
— it is not pushed to your instance automatically. If your instance has not yet been upgraded to a listed release, no
action is required at this time.
Guarded Script Release Timeline
Release Release Target Date
Zurich Patch 9 May 5, 2026
Australia Patch 2 May 5, 2026
Yokohama Patch 13 May 5, 2026
Zurich Patch 7b May 14, 2026
Yokohama Patch 12 HF1b May 14, 2026
Brazil September 10, 2026
Default Behavior by Instance Type
Guarded Script Default Enforcement
Transaction Type Instance Type Guarded Script Behavior
Unauthenticated / guest All instances Fully enforced immediately
Authenticated New instances Fully enforced immediately
Authenticated Upgraded instances (cloud) Phased enforcement over ~4 weeks (see below)
Authenticated Upgraded instances (on-premises) Detection begins automatically; enforcement requires manual advancement
In plain terms: Guest traffic is fully protected as soon as your instance is upgraded. For authenticated traffic on upgraded cloud instances,
enforcement phases in automatically over approximately four weeks. The system detects incompatible scripts and creates exemptions for them
before enabling enforcement, so existing functionality continues to work. On-premises administrators control the pace of enforcement manually.
Guest (Unauthenticated) Traffic
Guest (unauthenticated) scripts are fully enforced as soon as your instance is upgraded. There is no phased rollout for guest traffic — because guest
endpoints are reachable without authentication, full enforcement is applied immediately to limit exposure.
https://support.servicenow.com/kb?id=kb
article
_
_
view&sysparm
article=KB2944435 2/7_5/29/26, 12:17 PM Validation Mode Property
Server-Side Sandbox Runtime Replacement - Support and Troubleshooting
Guarded script behavior for guest traffic is controlled by the system property com.glide.script.kittyscript.validation.mode (KittyScript is
the internal name for the guarded script language and runtime, and is abbreviated as ks in the watchdog property names later in this article). The
default value is block
_guest. The enforcement phase system described below does not apply to guest traffic; guest scripts are validated according
to this property's value at all times.
Validation Mode Values (Guest Traffic)
Value Behavior for Guest Scripts
block or
Full guarded script enforcement. Incompatible guest scripts are blocked and recorded in the Incompatible Guarded Scripts list.
block
_guest
Incompatible guest scripts are recorded in the Incompatible Guarded Scripts list but allowed to execute. Diagnostic use only — provides no
warn
protection.
ignore Guarded script validation is disabled for guest traffic. Provides no protection.
Recommendation: Do not change this property to warn highest-risk scenario the feature is designed to protect.
or ignore on production. Both values weaken or remove guarded script protection for guest traffic, which is the
Phased Enforcement for Authenticated Traffic
Note: The phased rollout described below applies only to authenticated traffic. Guest traffic enforcement is covered in the section above.
After your instance is upgraded, guarded script enforcement for authenticated transactions advances through three phases. On cloud instances, this
happens automatically. Before each phase transition, the system creates exemptions for any incompatible scripts it has detected, so those scripts
continue to work.
New instances ship with full enforcement because out-of-the-box scripts have been revised to be compatible with guarded script. Upgraded
instances, however, may have customizations that rely on the existing sandbox behavior, so a phased approach is used to give the system time to
detect incompatible scripts in your environment and create exemptions for them before enforcement begins.
Phase Overview
Enforcement Phases for Authenticated Traffic
Phase Duration What Happens
Phase 1 — Detection 2 weeks
The system silently analyzes authenticated scripts for compatibility with guarded script syntax rules. Incompatible scripts
are recorded in the Incompatible Guarded Scripts list. No change to how scripts execute.
Phase 2 — Syntax Enforcement 2 weeks
Guarded script syntax rules are enforced for authenticated scripts. The system also detects scripts that use restricted APIs,
but does not block them — API violations are recorded but execution continues. Exemptions created at the end of Phase 1
ensure previously detected scripts continue to work.
Phase 3 — Full Enforcement Full guarded script enforcement for all authenticated transactions, including API restrictions. Scripts that violate
Permanent
restrictions are blocked unless exempted. Exemptions created at the end of Phase 2 ensure previously detected scripts
continue to work.
Automatic Exemptions
Before each phase transition, the system creates a guarded script exemption for every entry in the Incompatible Guarded Scripts list that does not
already have one. At the end of Phase 1, this covers scripts with syntax incompatibilities (the only kind detected during Phase 1). At the end of
Phase 2, this additionally covers scripts with API incompatibilities. Exempted scripts continue to run in the existing JavaScript sandbox runtime,
bypassing guarded script restrictions. This means any script that ran during the detection windows will continue to work after each enforcement
step.
Important: Only scripts that actually execute during a detection phase are captured. If you have scripts that run infrequently — such as quarterly reports or annual
processes — they may not be detected automatically. Review the Incompatible Guarded Scripts list and test critical but rarely-used workflows before Phase 3 to ensure they
are covered.
Changing the Phase Manually
After upgrade, on-premises instances enter Phase 1 automatically — detection begins immediately. However, the system does not advance to Phase
2 or Phase 3 automatically; on-premises administrators must advance phases manually when ready. Cloud administrators may also use these
methods to advance ahead of the automatic schedule or to roll back to an earlier phase.
To change the phase, use the GlideGuardedScript script include. Run these methods from a Background Script:
https://support.servicenow.com/kb?id=kb
article
_
_
view&sysparm
article=KB2944435 3/7_5/29/26, 12:17 PM Server-Side Sandbox Runtime Replacement - Support and Troubleshooting
GlideGuardedScript Methods
Method Purpose
new GlideGuardedScript().resetToPhase1() Return the instance to Phase 1 (detection only).
new GlideGuardedScript().advanceToPhase2() Advance the instance to Phase 2.
new GlideGuardedScript().advanceToPhase3() Advance the instance to Phase 3 (full enforcement).
On-premises administrators who prefer automatic advancement may enable it by setting
com.glide.script.sandbox.ks.watchdog.auto.advance to true (cloud instances have this enabled by default).
Enforcement Phase Properties
The following system properties control the enforcement phase system:
Important: Do not modify the com.glide.script.sandbox.ks.watchdog.phase property directly. Use the GlideGuardedScript methods described above
( resetToPhase1 , advanceToPhase2 , advanceToPhase3 ) to change the enforcement phase. Only the API methods perform the automatic exemption creation that
protects previously-detected scripts during a phase transition; manually editing the property skips that step and can cause previously-working scripts to be blocked.
Enforcement Phase Properties
Property Description Default
com.glide.script.sandbox.ks.watchdog.phase com.glide.script.sandbox.ks.watchdog.phase.duration.days
com.glide.script.sandbox.ks.watchdog.auto.advance
com.glide.script.sandbox.ks.watchdog.enabled
Current enforcement phase ( 1 , 2 , or 3 ).
Duration in days for Phase 1 and Phase 2. Set to advancement.
-1 to pause phase
Whether phases advance automatically. Automatically initialized to
false on on-premises instances and true on cloud instances.
Master switch for the guarded script feature. When set to false , all
transactions (guest and authenticated) execute in the existing JavaScript
sandbox runtime, bypassing guarded script entirely. Use only when the
feature itself must be disabled fleet-wide.
1 (upgraded) /
3 (new)
14
true (cloud) /
false (on-
prem)
true
Finding Affected Scripts
Your instance automatically detects and records scripts that are not compatible with guarded script. No configuration is needed — this happens as
soon as the feature is active.
Where to Look: The Incompatible Guarded Scripts List
Every script that fails guarded script validation is recorded in the Incompatible Guarded Scripts list. Each entry shows:
Normalized script — the script source, in normalized form
Scope — the scope the script was running in; if the script is detected multiple times, the unique scopes will be concatenated and comma-
separated
Is Authenticated — whether the transaction was authenticated or unauthenticated (guest)
Page Title — the endpoint of the transaction that triggered the script; if the script is detected multiple times, the unique page titles will be
concatenated and comma-separated. The script name might be used in context where a page title doesn't make sense, like a scheduled job.
Stack trace — the JavaScript stack trace captured the first time this script triggered a rejection
Occurrence count — how many times that script has been encountered
Exemption — reference to the exemption record, if an exemption has been created for this script
About normalization. The Normalized script field is not the original source as written — variable parts of the script (such as string and numeric
literals) are replaced with ? placeholders so that variations differing only by constant values collapse to a single entry. For example,
gs.daysAgoStart(7) and gs.daysAgoStart(30) both normalize to the same form. Without this, a script invoked across many records or
parameter values would produce a separate entry each time, flooding the table and making exemption management impractical. A single exemption
created against a normalized entry covers every runtime variation that normalizes to the same form.
Together, the Scope, Page Title, and Stack trace fields can help identify the origin of an affected script — when those fields are populated. The
system records this information where possible, but availability depends on how the Evaluator was invoked, and some entries may be missing one or
more of these values.
https://support.servicenow.com/kb?id=kb
article
_
_
view&sysparm
article=KB2944435 4/7_5/29/26, 12:17 PM Server-Side Sandbox Runtime Replacement - Support and Troubleshooting
If the source information is missing or insufficient, search the instance for a distinctive snippet of the script content to help locate the configuration
record where the script lives. Note that the script source may be external — for example, a javascript: expression passed as a URL filter
parameter — in which case it will not be present in any configuration record on the instance.
If the source cannot be identified, review the script content directly and decide whether to create an exemption based on the safety of the content.
Scripts are deduplicated by the combination of their normalized form and traffic type, so the list stays manageable even on high-traffic instances.
Many real-world invocations of the same logic collapse into a single row, though a script that runs in both guest and authenticated contexts will
produce two entries. There is no default retention policy applied to the table — if growth is a concern, add a table cleaner to maintain the table
within acceptable limits.
How to Fix Affected Scripts
For each script in the Incompatible Guarded Scripts list, you have two options.
Option 1 (Recommended): Move Logic Into a Script Include
The cleanest fix is to take the complex logic out of the sandbox script and put it in a script include. Script includes run outside the sandbox and are
not restricted by guarded script. Then, your sandbox script just calls the script include with a simple one-line expression.
Example
Before (this will fail guarded script — it uses a variable and conditional logic):
var priority = current.priority;
if (priority == 1) { gs.beginningOfToday(); }
else { gs.endOfLastWeek(); }
After — Script Include (create a new script include called MyDateHelper):
var MyDateHelper = Class.create();
MyDateHelper.prototype = {
initialize: function() {},
getRelevantDate: function(priority) {
if (priority == 1) {
return gs.beginningOfToday();
} else {
return gs.endOfLastWeek();
}
},
type: 'MyDateHelper'
};
After — Sandbox script (this is what replaces the original — one simple line):
new MyDateHelper().getRelevantDate(current.priority)
Key point: The sandbox script is now just a single function call — exactly the kind of simple expression guarded script allows. All the complex logic lives safely in the script
include.
Option 2 (Last Resort): Create an Exemption
If rewriting a script is not practical, an administrator can exempt it. Exempted scripts bypass guarded script and continue to run in the existing
JavaScript sandbox runtime.
Exemptions are created from the Incompatible Guarded Scripts list — select the script entry and create the exemption from there. Only
administrators can create or remove exemptions. The system may also create exemptions automatically during enforcement phase transitions.
Automatic exemptions work the same way — the exempted script runs in the existing JavaScript sandbox runtime. You can review and manage all
exemptions, whether created manually or automatically, from the exemptions list.
Each exemption applies only to the traffic type (guest or authenticated) of the originating Incompatible Guarded Scripts entry. If the same
incompatible script appears in both guest and authenticated contexts, you must create an exemption from each entry to cover both paths.
Note that the exemption table is not part of an application scope, so changes are not tracked in update sets. To move exemptions between
machines, manually export and import them.
Use exemptions sparingly. Each exemption is a script that continues to run with the existing, broader permissions.
https://support.servicenow.com/kb?id=kb
article
_
_
view&sysparm
article=KB2944435 5/7_5/29/26, 12:17 PM Server-Side Sandbox Runtime Replacement - Support and Troubleshooting
Recommended Actions
On cloud instances, enforcement phases in automatically and the system creates exemptions for detected scripts. The following steps help you
prepare proactively and ensure full coverage.
For Cloud Instances
1. Review the Incompatible Guarded Scripts list during Phase 1. Once your instance is upgraded, detection begins immediately. Navigate to the
list to see which scripts have been flagged.
2. Exercise infrequently-used workflows. Trigger quarterly, annual, or other rarely-used processes on a sub-production instance so they are
detected and exempted before the phase transitions.
3. Fix incompatible scripts where practical. For each entry, either rewrite it (move complex logic to a script include) or confirm that it has an
exemption. Scripts rewritten to use simple expressions no longer need an exemption.
4. Review automatic exemptions after Phase 2 begins. The system creates exemptions before each phase transition. Review them to confirm
they are expected, and plan to remediate the underlying scripts over time.
5. Monitor after Phase 3. Once full enforcement is active, continue checking the Incompatible Guarded Scripts list. Any script that was not
detected during Phases 1 and 2 (because it did not run during those windows) will be blocked and recorded there. Create a manual exemption
for any that surface, then remediate them.
Tip: To pause automatic phase advancement, set set the property back to a positive value.
com.glide.script.sandbox.ks.watchdog.phase.duration.days to -1 . This freezes the current phase until you
For On-Premises Instances
1. Allow Phase 1 detection to run. After upgrading, your instance enters Phase 1 automatically. Let it run long enough to capture incompatible
scripts. A longer detection window catches more infrequent workflows but delays the onset of protection. ServiceNow defaults to two weeks
per phase and recommends this as a starting point.
2. Review the Incompatible Guarded Scripts list. Exercise all critical workflows — including infrequent ones — and review the detected scripts.
3. Fix or exempt each incompatible script. Rewrite scripts where practical; create exemptions for the rest.
4. Advance to Phase 2. When ready, run new GlideGuardedScript().advanceToPhase2() from a Background Script. The system will create
exemptions for any remaining detected scripts before enforcement begins. Allow Phase 2 to run using the same duration considerations as
Phase 1 to catch API-level incompatibilities.
5. Advance to Phase 3. Once you are confident all scripts are covered, run new GlideGuardedScript().advanceToPhase3() to enable full
enforcement. The system will create exemptions for any API-incompatible scripts detected during Phase 2 before full enforcement begins. To
roll back to detection-only at any time, run new GlideGuardedScript().resetToPhase1().
Why a Phased Rollout?
A common question is whether the system can identify all affected scripts on your instance before any enforcement begins, so they can be
remediated up front. Unfortunately, this is not possible. Sandbox-eligible scripts can originate from many sources — including URL parameters
supplied at request time — and whether a given input is evaluated under guarded script restrictions is often determined at runtime rather than from
static configuration. No static scan can produce a complete list of scripts that will be affected.
The phased rollout is designed to address this. During the detection windows, the system observes the scripts your instance actually executes and
records any that would fail guarded script validation. Before enforcement begins, exemptions are created automatically for the scripts captured
during those windows, so workflows that ran during detection continue to work after enforcement is enabled. The goal is to surface real-world
incompatibilities and minimize regressions while still moving toward full enforcement.
The corollary: only scripts that actually execute during a detection window will be captured automatically. If your instance has workflows that run
on monthly, quarterly, or annual cadences, consider extending the detection windows by increasing
com.glide.script.sandbox.ks.watchdog.phase.duration.days from its default of 14, or exercise those workflows manually on a non-
production instance during the relevant phase. Scripts that surface only after Phase 3 begins will be blocked and recorded; you can review them on
the Incompatible Guarded Scripts list and create manual exemptions or remediate as needed.
The world works with ServiceNow.
Was this content helpful?
65% found this useful
Yes No
https://support.servicenow.com/kb?id=kb
article
_
_
view&sysparm
article=KB2944435 6/7_5/29/26, 12:17 PM Server-Side Sandbox Runtime Replacement - Support and Troubleshooting
Did this KB article help you?
Terms and conditions Privacy statement GDPR Cookie policy Cookie preferences
© 2026 ServiceNow. All rights reserved.
https://support.servicenow.com/kb?id=kb
article
_
_
view&sysparm
article=KB2944435 7/7_
Comments
Post a Comment