I've had some back and forth with them. There was a fairly long phone conversation where the tech told me that this whole guarded script thing was news to their level 1 service desk. They just started getting questions about it and were having to consult each other to figure out what it was. Here is a long body of text that was last posted to the Case a couple of days ago:
So Guarded script doesn't apply to script includes or client-side scripts. So anything running in the sandbox path.
The evaluator applies to untrusted, client-generated server-side scripts routed through the sandbox path — NOT to persistent Business Rules, Scheduled Jobs, Scripted REST API resources, or transform map scripts that run under their own application scope.
Here are some key points that might bring some clarifty from our conversation.
───────────────────────────────────────
1a. How is detection in Phase 1 different from Phase 2?
───────────────────────────────────────
Phase 1 and Phase 2 detect different types of incompatibilities:
• Phase 1 (Detection): Silently identifies syntax incompatibilities — variable declarations (var/let/const), if/else, loops, multi-statements. Nothing is blocked; scripts continue to execute normally. Incompatible scripts are recorded in the Incompatible Guarded Scripts list (sys_gs_incompatible_scripts).
• Phase 2 (Syntax Enforcement): Syntax violations from Phase 1 are now actively blocked for authenticated traffic. Phase 2 additionally detects API-level incompatibilities — scripts that pass syntax validation but invoke restricted APIs. API violations are logged but not yet blocked in this phase.
In short: Phase 1 catches structural problems; Phase 2 catches behavioral/API-level problems, while enforcing Phase 1 findings.
───────────────────────────────────────
1b. Will exemptions be created for scripts detected in Phase 2?
───────────────────────────────────────
Yes. Before the Phase 2 → Phase 3 transition, the system automatically creates exemptions for every entry in the Incompatible Guarded Scripts list that does not already have one — including API-incompatible scripts first detected during Phase 2. Any script that executed during Phase 2 will be protected before full enforcement begins.
Important: This automatic exemption creation only happens when phases are advanced using the GlideGuardedScript API methods (advanceToPhase3()). If the watchdog.phase property is edited directly in System Properties, the auto-exemption step is skipped and previously-working scripts may break. Always use the API method.
───────────────────────────────────────
2. Finding incompatible scripts without a known inventory
───────────────────────────────────────
This is a known platform limitation — no static scan can produce a complete list, as script eligibility is often determined at runtime. Beyond extending the detection window, we recommend the following complementary approaches:
• Static scan via Background Script: Query key tables for scripts containing patterns like "var ", "if (", "for (", "let ", "const ". Suggested tables: sys_filter, sys_ui_action, sys_script, sys_report, sys_portal_page. This surfaces statically-configured candidates before runtime detection.
• Audit URL-based javascript: filters: These are often embedded in saved reports, homepage widgets, or bookmarked URLs and will not appear in any configuration record on the instance — they are the hardest to detect.
• Sub-prod clone + synthetic load: Clone PROD to a sub-prod instance, upgrade it, and run full regression/UAT cycles. Any script that executes will be captured automatically in sys_gs_incompatible_scripts during Phase 1 detection.
• Use the Stack Trace and Page Title fields: Each entry in sys_gs_incompatible_scripts includes a stack trace and page title (where available). These can reveal patterns pointing to related scripts in the same module or application.
Note: Even with a 3-month detection window, some low-frequency scripts may only surface post-Phase 3. The per-script exemption mechanism (admin self-service via sys_gs_incompatible_scripts) is specifically designed for this — it takes effect immediately and does not require a Support ticket or a broad property change.
───────────────────────────────────────
3. Preventing disruption for Guest (Unauthenticated) traffic
───────────────────────────────────────
Guest enforcement is immediate on upgrade — there is no detection phase for guest traffic. The mitigation window is before upgrading Production, not after. Recommended approach:
• Upgrade sub-prod first (mandatory): Guest enforcement activates immediately on sub-prod, populating sys_gs_incompatible_scripts with guest-context violations before Production is touched.
• Temporarily set validation.mode = warn on sub-prod: This surfaces guest incompatibilities without blocking, allowing the customer to assess impact safely. Revert to block_guest before upgrading Production — do not leave warn in place on prod.
• Focus on guest-accessible endpoints: Service Portal public pages, unauthenticated REST APIs, login/password reset flows are the realistic vectors for guest-context sandbox scripts.
• Fix or exempt before Prod upgrade: Rewrite affected scripts or create exemptions on sub-prod. Since exemptions are not captured in Update Sets, manually export and import them to Prod prior to upgrading.
• Emergency fallback (post-upgrade): If an issue surfaces on Prod after upgrade, the immediate lever is:
- For guest traffic only: Set com.glide.script.kittyscript.validation.mode = warn. This restores guest script execution temporarily while the fix is applied.
- For both guest and authenticated (last resort only): Set com.glide.script.sandbox.ks.watchdog.enabled = false. This is the fleet-wide master kill switch and removes all guarded script protections. It must be treated as a strictly temporary measure with a remediation plan and re-enablement date.
Key message: Sub-prod validation before Production upgrade is the primary safety net for guest traffic — not the phased rollout, which applies to authenticated traffic only.
───────────────────────────────────────
4. Will "Sandbox Enabled" Script Includes be affected?
───────────────────────────────────────
Yes, conditionally. The distinction is:
• Regular Script Includes: Run in the owning application scope, outside the sandbox. Not affected.
• Script Includes with "Sandbox Enabled" (sandbox_callable = true): Run inside the sandbox by design and are subject to Guarded Script restrictions. However, it is important to note that KittyScript validation applies only to the top-level sandbox call — the body of a sandbox_callable Script Include is not subject to KittyScript syntax restrictions. Only the caller script that invokes the Script Include must conform to single-expression syntax.
Recommendation: Query sys_script_include where sandbox_callable = true and review whether any of those Script Includes are themselves being called from complex top-level sandbox scripts that need refactoring.
───────────────────────────────────────
5. Business Rules not triggered by CRUD — are they affected?
───────────────────────────────────────
Business Rule script bodies are not affected regardless of their trigger type — they do not run inside the sandbox.
However, there is an important distinction regarding where a BR is evaluated:
• BR Script body → Not affected (runs in app scope, outside sandbox)
• BR Condition field using javascript: → Affected (condition is evaluated in the sandbox)
• Reference qualifiers and default values using javascript: → NOT affected (engineering has confirmed these are not evaluated through the sandbox and require no remediation)
So the customer's claim has some basis, but the risk is in the Condition field, not the script body. We recommend reviewing Business Rule Condition fields specifically for javascript: expressions or complex logic. The sys_gs_incompatible_scripts list (Stack Trace and Page Title fields) will help identify any BR conditions already flagged during detection.
