--- sourceDocument: Brazil API Reference sourceDocumentLink: https://www.servicenow.com/docs/r/api-reference Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil API Reference ft:clusterId : - crapiref bundleId : - crapiref workflow : - Creator --- # Guarded script evaluator # Guarded script evaluator {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Guarded Script Evaluator The Guarded Script Evaluator enhances the security of your ServiceNow instance by restricting server-side scripting to a limited, safe subset of JavaScript syntax and APIs. It executes trusted scripts within a sandbox environment and rejects or detects scripts using unsupported features. This mechanism applies only to server-side scripts running in the sandbox and excludes client-side scripts and script includes running in application scope. Show full answer Show less ## Guarded Script Enforcement Enforcement behavior varies based on transaction origin (authenticated vs. guest user) and instance type: * **Guest users:** Incompatible scripts are immediately rejected on all instances. * **Authenticated users:** Enforcement depends on instance type and phase: * **New instances:** Full enforcement is immediate; incompatible scripts are rejected and logged. * **Upgraded cloud instances:** Enforcement progresses through three phases over time---detection, syntax enforcement, and full enforcement---to allow script review and remediation. * **Upgraded on-premise instances:** Detection only by default; administrators control phase progression. During enforcement, scripts with incompatibilities can be automatically or manually exempted to run in the script sandbox evaluator, providing flexibility while securing the instance. ## Enforcement Phases for Authenticated Traffic * **Phase 1: Detection** --- Scripts run regardless of compatibility; incompatible syntax is detected and logged; exemptions are created automatically for syntax issues. * **Phase 2: Syntax Enforcement** --- Scripts with incompatible syntax are rejected; incompatible API usage is detected but not rejected; exemptions are created automatically for API issues. * **Phase 3: Full Enforcement** --- Both syntax and API restrictions are enforced; all incompatible scripts are rejected; exemptions must be created manually. ## Configuration and Management Administrators can manage enforcement phases and behaviors using system properties and the `GlideGuardedScript` script include. Key configuration options include: * Setting the current enforcement phase and duration of phases. * Controlling automatic advancement between phases. * Enabling or disabling the guarded script evaluator (not recommended for production). The `GlideGuardedScript` script include provides methods to reset or advance enforcement phases, useful for manual control especially on on-premise instances. ## Supported JavaScript Features and APIs The guarded script evaluator supports only simple expressions or function calls using a limited subset of JavaScript syntax, including: * Primitive literals (number, string, boolean, null, undefined). * Common operators (+, -, \<, !==, \&\&, instanceof, typeof). * Ternary operator, array literals, property access, and indexed array access with constants. * Calling script includes flagged as sandbox-enabled. More complex scripting constructs like variable declarations, control flows, and multiple statements are not supported. Scripts using unsupported features must be refactored or moved into sandbox-enabled script includes. Guarded script also restricts ServiceNow server-side and built-in JavaScript APIs to a predefined safe list. Regularly reviewing and updating incompatible scripts is essential for maintaining security. ## Reviewing and Remediating Incompatible Scripts Scripts that violate guarded script constraints are logged in the Incompatible Guarded Scripts list when executed. Customers should monitor this list regularly, especially for infrequently run business-critical scripts, to identify and remediate issues before full enforcement phases are applied. For scripts that cannot be updated immediately, exemptions can be created to allow execution in the script sandbox evaluator, maintaining functionality while protecting instance security. The guarded script evaluator enhances instance security by supporting only a restricted scripting language and detecting or rejecting untrusted scripts that use unsupported JavaScript features. The guarded script evaluator uses a domain-specific language (DSL) that permits only a small set of JavaScript syntax, such as simple expressions and function calls, and certain APIs in server-side scripts that run in the script sandbox environment. Note: Guarded script doesn't apply to script includes, which run in the application scope outside of the sandbox, or client-side scripts. When a script that uses only supported features is evaluated by guarded script, it executes successfully. If a script contains unsupported features, guarded script handles it differently depending on the following factors: * The origin of the transaction: authenticated user or unauthenticated (guest) user. Guest traffic refers to server-side transactions executed without a logged-in user session, such as interactions coming from public pages. * The enforcement phase for authenticated traffic configured for an instance. {#guarded-script__ul_xlk_fb4_y3c} Scripts with a guarded-script exemption bypass guarded script restrictions and are routed to the script sandbox evaluator for execution instead. For more information about the script sandbox evaluator, see [Script sandbox evaluator](https://www.servicenow.com/docs/fi6OceerjxeoDIf7vqxwqQ "The script sandbox evaluator helps prevent executing untrusted scripts on an instance by limiting the APIs available to scripts."). ## Guarded script enforcement {#guarded-script__guarded-script-enforcement} Incompatible scripts sent to the server by guest users are rejected on all instances by default. Scripts sent by authenticated users are evaluated differently depending on the instance type. {#guarded-script__tableID-guarded_script_default_enforcement__entry__2} | Transaction type | Default behavior | |-|-| | Unauthenticated (guest) | Enforced immediately on all instances. Guarded script rejects incompatible scripts, adds them to the Incompatible Guarded Scripts list, and logs errors. | | Authenticated | * Upgraded cloud-based instances: Phased enforcement beginning with guarded script detecting but not rejecting incompatible scripts (Phase 1: Detection) and automatically advancing to each subsequent phase (Phase 2: Syntax enforcement and Phase 3: Full enforcement) after two weeks. * Upgraded on-premise instances: Not enforced, but guarded script detects and records incompatible scripts (Phase 1: Detection). Administrators can configure when to transition to the subsequent enforcement phases. * New instances: Enforced immediately. Guarded script rejects incompatible scripts, adds them to the Incompatible Guarded Scripts list, and logs errors (Phase 3: Full enforcement). {#guarded-script__ul_ynk_qwn_y3c} | [Table 1. Default behavior of guarded script] {#guarded-script__tableID-guarded_script_default_enforcement} For authenticated traffic on upgraded instances, guarded script enforcement advances through the following phases to provide time to detect and review incompatible scripts before rejecting them. Before transitioning to Phase 2: Syntax enforcement and Phase 3: Full enforcement, the system creates exemptions for any incompatible scripts detected during each phase automatically. Those exempted scripts bypass guarded script restrictions and run in the script sandbox evaluator. To further secure your instance, you can still review any scripts that have automatic exemptions, update them to be compatible with guarded script, and then remove the exemptions. Important: Incompatible scripts are only detected and recorded when transactions calling them are sent to the server. You should test business-critical scripts that run infrequently, such as for quarterly or annual processes, before moving to Phase 3: Full enforcement and review the Incompatible Guarded Scripts list regularly to identify any scripts that may need remediation before they could be rejected. For more information, see [Update scripts incompatible with guarded script](https://www.servicenow.com/docs/IQ7bch~fAxGmmuRWnvns~g#review-incompatible-guarded-scripts "Review scripts that are incompatible with guarded script and either rewrite them to use supported features or create an exemption for scripts that can't be rewritten."). {#guarded-script__table_yt2_cc4_y3c__entry__2} | Phase | Description | |-|-| | Phase 1: Detection | * Not enforced. Scripts execute regardless of guarded script restrictions. * Detects and records only scripts with incompatible syntax in the Incompatible Guarded Scripts list. Scripts with incompatible APIs aren't detected yet. * At the end of this phase, exemptions are created automatically for scripts with incompatible syntax, which routes them to the script sandbox evaluator for execution instead. {#guarded-script__ul_o52_w1y_z3c} Default duration: two weeks | | Phase 2: Syntax enforcement | * Enforces guarded script syntax restrictions only, rejecting scripts with incompatible syntax and logging errors, but doesn't reject scripts with incompatible APIs. * Detects and records scripts with any incompatibilities in the Incompatible Guarded Scripts list. * At the end of this phase, exemptions are created automatically for scripts that use incompatible APIs, which routes them to the script sandbox evaluator for execution instead. {#guarded-script__ul_zfg_1by_z3c} Default duration: two weeks | | Phase 3: Full enforcement | * Enforces both guarded script syntax and API restrictions. Guarded script rejects all incompatible scripts and logs errors. * Detects and records scripts with any incompatibilities in the Incompatible Guarded Scripts list. * In this phase, any additional exemptions must be created manually. {#guarded-script__ul_h5l_rly_z3c} | [Table 2. Enforcement phases for authenticated traffic] {#guarded-script__table_yt2_cc4_y3c} ## Configuring guarded script {#guarded-script__configuring-guarded-script} Administrators can configure the enforcement process for authenticated traffic using the following system properties and script include. {#guarded-script__table_tzb_vzf_y3c__entry__2} | Property | Description | |-|-| | com.glide.script.sandbox.ks.watchdog.phase | The current phase of enforcement that the guarded script evaluator applies to untrusted scripts. Note: Don't update the value of this property manually. Use the following GlideGuardedScript script include methods instead to generate automatic exemptions when transitioning between phases. If the com.glide.script.sandbox.ks.watchdog.auto.advance property is set to true, the value of this property is automatically updated according to the duration specified with the com.glide.script.sandbox.ks.watchdog.phase.duration.days property. * Type: String * Default value: * 1 for upgraded instances * 3 for new (or zBoot) instances {#guarded-script__ul_l5r_1yw_z3c} * Valid values: * 1: Enables Phase 1: Detection. * 2: Enables Phase 2: Syntax enforcement. * 3: Enables Phase 3: Full enforcement. {#guarded-script__ul_vzb_vzf_y3c} {#guarded-script__ul_uzb_vzf_y3c} | | com.glide.script.sandbox.ks.watchdog.phase.duration.days | The duration, in days, that each of Phase 1: Detection and Phase 2: Syntax enforcement is in effect. To pause automatically advancing between each phase, set the value to -1. * Type: Integer * Default value: 14 {#guarded-script__ul_n3g_g1g_y3c} | | com.glide.script.sandbox.ks.watchdog.auto.advance | An option to control automatically advancing between enforcement phases according to the duration configured with the com.glide.script.sandbox.ks.watchdog.phase.duration.days property. * Type: Boolean * Default value: * true for cloud-based instances * false for on-premise instances {#guarded-script__ul_r1k_j1g_y3c} {#guarded-script__ul_t2n_g1g_y3c} | | com.glide.script.sandbox.ks.watchdog.enabled | An option to turn off the guarded script evaluator and route all untrusted scripts to the script sandbox evaluator instead. Warning: Don't set this property to false on production instances. Setting this property to false removes the enhanced security protections provided by the guarded script evaluator. * Type: Boolean * Default value: true {#guarded-script__ul_ut3_tmy_z3c} | [Table 3. Guarded script properties] {#guarded-script__table_tzb_vzf_y3c} For information about configuring system properties, see [Add a system property](https://www.servicenow.com/docs/access?context=t_AddAPropertyUsingSysPropsList&version=brazil&pubname=brazil-platform-administration&ft:locale=en-US). The GlideGuardedScript script include supports methods for transitioning between enforcement phases and validates that the transition occurs sequentially. These methods are primarily useful for instances that aren't configured to advance automatically, such as upgraded, on-premise instances. From the Scripts - Background module, you can run the following methods to transition to each phase as needed. {#guarded-script__table_d5c_ngy_z3c__entry__2} | Method | Description | |-|-| | `new GlideGuardedScript().resetToPhase1()` | Resets the instance to Phase 1: Detection for authenticated transactions. Any automatic exemptions created previously remain. | | `new GlideGuardedScript().advanceToPhase2()` | Validates that Phase 1: Detection is complete, creates exemptions for scripts with incompatible syntax, and advances the instance to Phase 2: Syntax enforcement for authenticated transactions. | | `new GlideGuardedScript().advanceToPhase3()` | Validates that Phase 2: Syntax enforcement is complete, creates exemptions for scripts that use incompatible APIs, and advances the instance to Phase 3: Full enforcement for authenticated transactions. | [Table 4. GlideGuardedScript script include methods] {#guarded-script__table_d5c_ngy_z3c} For information about running background scripts, see [Background scripts](https://www.servicenow.com/docs/t~pXw7UlKQZCXgT~8i_Y5w "Administrators can use the Scripts - Background module to run arbitrary JavaScript code from the server."). ## JavaScript features supported by guarded script {#guarded-script__supported-features} The following JavaScript features are supported by guarded script. Use this information to analyze scripts in the Incompatible Guarded Scripts list and either rewrite them or create an exemption for them.{#guarded-script__guarded-script-dsl-para-5} Guarded script supports only a single, simple expression or function call using the following JavaScript syntax: * Primitive literals: number, string, boolean, null, undefined * Common operators: +, -, \<, !==, \&\&, instanceof, typeof * Ternary operator (?:) * Array literals (\[1, 'x'\]) * Property access using dot notation (a.b) * Indexed array access with constant numbers (a\[0\]) * Calling script includes that have the Sandbox enabled option selected {#guarded-script__ul_supported_features} Other JavaScript syntax, including variable and function declarations, assignment operators (=), control flows, and multiple statements, aren't supported by guarded script. For example, guarded script rejects the following script because it contains a variable and control flow logic (`if` statement): javascript:var ret='customer=true'; if (current.relationship_type.to == 'partner') ret = 'partner=true'; ret + '^sys_id!=' + current.from_company; If you move this logic to a script include and call the script include from the script instead, guarded script executes the updated script: javascript:new MyAppUtils().getAccountToFilter(current); In addition, guarded script supports only a restricted list of ServiceNow server-side JavaScript APIs and built-in JavaScript APIs. For a list of supported APIs, see [JavaScript APIs supported by guarded script](https://www.servicenow.com/docs/6gGjqLFXW9TbAzbDOUnPpg "Review the JavaScript APIs that guarded script supports to help you analyze scripts in the Incompatible Guarded Scripts list and either rewrite them or create an exemption for them."). You should review the Incompatible Guarded Scripts list regularly and either rewrite scripts to use supported features to further secure your instance or create exemptions for scripts that can't be rewritten. For more information, see [Update scripts incompatible with guarded script](https://www.servicenow.com/docs/IQ7bch~fAxGmmuRWnvns~g#review-incompatible-guarded-scripts "Review scripts that are incompatible with guarded script and either rewrite them to use supported features or create an exemption for scripts that can't be rewritten.") and the [Server-Side Sandbox Runtime Replacement \[KB2944435\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2944435) article on the Now Support Knowledge Base. * **[Reviewing scripts incompatible with guarded script](https://www.servicenow.com/docs/IQ7bch~fAxGmmuRWnvns~g#incompatible-guarded-scripts)** Guarded script records scripts that use unsupported JavaScript features in the Incompatible Guarded Scripts list when transactions calling those scripts are sent to the server. * **[JavaScript APIs supported by guarded script](https://www.servicenow.com/docs/6gGjqLFXW9TbAzbDOUnPpg)** Review the JavaScript APIs that guarded script supports to help you analyze scripts in the Incompatible Guarded Scripts list and either rewrite them or create an exemption for them. **Related concepts** * [Script sandbox evaluator](https://www.servicenow.com/docs/fi6OceerjxeoDIf7vqxwqQ "The script sandbox evaluator helps prevent executing untrusted scripts on an instance by limiting the APIs available to scripts.")