ServiceNow Now Assist Configuration Risk and Privilege Scope

ServiceNow's Now Assist doesn't sit on top of the platform's access control system. It runs through it. That's the whole story here: every permission gap, every stale role, every overscoped service account that's been quietly living in a ServiceNow instance for years now has a machine-speed operator sitting on top of it, ready to act on whatever it can reach.

How ServiceNow's ACL and RBAC architecture works

Access Control Lists are the gatekeepers on every table and every field in ServiceNow. Want to read a record? You need to clear the table ACL. Want to see a specific field on that record, say a salary figure or another sensitive identifier? You need to clear a field ACL too. Both gates, every time. That's the design, and on paper it's sound.

Field-level ACLs exist for exactly this reason: locking down the columns that matter even when someone already has table access. PII, financial data, anything with embedded credentials. Least privilege, applied at the most granular level the platform offers.

It gets messy in practice. Role-based access control tends to sprawl as an instance ages. A few years of new hires, departing admins, and "just add this role for now" tickets cause role creep to set up shop. Users end up holding permissions nobody remembers granting, for job functions they don't hold anymore. This isn't a hypothetical, it's a documented pattern across long-running instances.

Then there's the Admin Overrides checkbox, which might be the single most underused safety switch on the platform. Best practice guidance advises unchecking it and relying on explicit security attributes instead, so that even an admin-level account has to satisfy defined conditions before touching sensitive data. Most production instances leave it checked. Which means "elevated" often just means "unrestricted," full stop.

How cross-scope privilege design creates compounding exposure before AI enters the picture

Scoped applications are supposed to behave like separate rooms in a house. Each app owns its own tables, its own scripts, its own walls. Cross-scope privileges, tracked in a table called sys_scope_privilege, are the doors between those rooms, and they're meant to be opened deliberately, one at a time, with a reviewer checking who's walking through.

Runtime Access Tracking is the mechanism that decides how seriously the platform takes those doors. Set to Enforcing, unauthorized cross-scope calls get logged and blocked. Set to anything less, the door's basically just... there. A lot of instances aren't running Enforcing across all their scopes. The wall is more decorative than structural in places nobody's audited recently.

And then there's the workaround developers reach for when the cross-scope privilege prompt slows them down: setting Caller Access to "All Application Scopes." It's faster. It also erases the entire point of scoping in one checkbox. Once that's set, the wall isn't just weaker, it's gone, and every app on the instance can reach into every other app's tables without so much as a logged request.

Stacking that on top of the ACL problems above produces compounding exposure. One misconfigured field ACL is bad. One misconfigured field ACL sitting inside a scope that any application can freely call into is a different, more serious order of problem.

What Now Assist's agentic layer adds to an already complex privilege surface

Now Assist plugs directly into this same architecture. It doesn't get its own separate, cleaner set of rules, it inherits whatever ACL and scope conditions already exist on an instance, good or bad. That means testing Now Assist means testing what data the AI layer can reach and surface, above and beyond what a given user's own ACLs would normally allow.

A human user working inside a misconfigured ACL is slow and limited, while an autonomous agent working inside that same hole is not. A person is slow. A person gets tired, gets distracted, only has so many hours in a shift to go poking around records they technically shouldn't see. An AI agent doesn't have any of those limits. It queries at machine speed, and it does it exactly as many times as it's told to, without fatigue or hesitation.

Once an agent is trusted to execute workflows or make decisions on its own, every misconfigured permission, every shared credential, every sloppy linking mechanism becomes something the agent can act through. Not necessarily maliciously on its own end, but as a proxy for whoever figures out how to steer it.

The broader an agent's permissions, the broader the exposure it creates on the platform. That's not a theoretical warning bolted onto a product review; it's what falls out of the architecture once you trace where the guardrails actually sit.

CVE-2025-12420 ("BodySnatcher"): what a hardcoded credential in the Virtual Agent API made possible

Aaron Costello, chief of security research at AppOmni, found something in the Virtual Agent API that reads like a case study in how not to handle third-party authentication. Tracked as CVE-2025-12420 and nicknamed BodySnatcher, it carries a CVSS score of 9.3, which is near the top of the severity scale.

The root cause traces to CWE-250, execution with unnecessary privileges. ServiceNow shipped one hardcoded credential, literally the string "servicenowexternalagent," to every third-party service that needed to authenticate against the Virtual Agent API. Not a unique credential per customer. Not a unique credential per integration. The same one, everywhere, shared across every third-party service that authenticated against the API.

That combination made an attack possible. Take the universal credential, pair it with a target company's subdomain (something scanning tools can find without much effort), add the victim's email address, and that combination bypasses MFA, bypasses SSO, and bypasses every other access control standing between an outsider and the platform. From there, the attacker impersonates any user in the system.

The CVSS 4.0 vector spells out just how low the bar was: network-based attack, low complexity, no authentication required, no user interaction needed. That's about as frictionless as an attack chain gets, and it existed on a system holding incident records, HR cases, and vendor risk data for a platform used by nearly half of AppOmni's Fortune 100 customers.

The second attack class: prompt injection through Now Assist's agent-to-agent discovery

A second finding came out of AppOmni's research in November 2025, and this one lives entirely inside Now Assist's own design choices rather than a shipped credential. The mechanism is agent-to-agent discovery, the feature that lets one AI agent find and hand off work to another agent on the platform.

Attackers can exploit the default configuration of that discovery feature to run prompt injection, and from there, copy and exfiltrate sensitive corporate data and modify records. It's expected behavior, functioning exactly as the default configuration options define it. It's expected behavior, as defined by certain default configuration options. Read that twice, because it should worry security teams the most. Nothing broke. The feature did what it was built to do, and that was the problem.

What makes the finding land harder is what didn't stop it. The low-privileged user running the attack could not access the targeted ticket directly; ACLs blocked that path. And ServiceNow's own prompt injection protection feature was switched on the entire time testing ran. Neither one held.

Additional critical vulnerabilities in the ServiceNow AI platform in 2026

BodySnatcher and the agent-to-agent injection finding weren't isolated events. CVE-2026-0542 is a critical sandbox bypass vulnerability carrying a CVSS score of 9.8, one of the highest ratings the scale allows, and it enables unauthenticated remote code execution.

Then came the June 2026 API misconfiguration, documented under KB3067321. A REST endpoint, /api/now/related_list_edit/create, was set with requires_authentication=false. No login required. It exposed customer data sitting behind what should have been a locked door.

That June incident deserves a second look, because it's not glamorous. There's no clever exploit chain, no zero-day logic bug, nothing that took months of research to uncover. It's a single configuration parameter set to the wrong value. It drifts in quietly between one security review and the next, and nobody notices until something's already been exposed.

Looking at all three findings side by side, a pattern appears quickly. The highest-severity issues in this platform cluster around authentication bypass, privilege misuse, and configuration drift, categories that a generic vulnerability scanner isn't built to catch, because none of them look like a traditional software bug.

What a platform-aware penetration test of ServiceNow covers

A vulnerability assessment that only pokes at the login page and the Service Portal is going to miss almost everything that matters. Real ServiceNow breaches happen down in business logic and access control configuration, layers a generic web app scan doesn't know exist.

A complete assessment works methodically through the platform's own structure.

Attack surface inventory comes first. That means cataloging every external-facing surface: Service Portal, Employee Center, the mobile agent app, any unauthenticated widgets sitting in the open. It means listing every installed scoped application, including ones pulled from the Store, documenting Integration Hub spokes and MID Server connections, mapping outbound REST and SOAP messages, and locating SSO and SAML metadata endpoints. Sub-production instances that mirror live production data deserve a place on that list too, because they often carry the same exposure with less scrutiny.

ACL logic testing comes next, and it's mostly about trying to break the rules on purpose. Build a role-to-table matrix, then attempt horizontal privilege escalation between two users who share a role but sit in different departments. Try vertical escalation, pushing a standard fulfiller account toward tables meant for admins only. Check field-level ACLs on sys_user, hr_case, and incident tables independently, since table access and field access don't always line up the way they should. Client-callable Script Includes need a look too, since automated scanners can't reason through a Business Rule bypass via setWorkflow(false) or catch an unguarded GlideRecord query sitting exposed in server-side code.

SSO and identity federation testing covers SAML assertion tampering and signature validation, run against both IdP-initiated and SP-initiated login flows. Session fixation during the SSO handoff gets checked, along with MFA bypass paths that might exist through delegated admin accounts or emergency-access accounts, plus a review of service account credentials for scopes broader than the job requires.

Scoped application and custom code review looks for cross-scope privilege escalation reaching into global-scope tables, tests GlideAjax client-callable functions for unsafe logic running server-side, and searches through Script Includes for hardcoded credentials or API keys left behind in the code.

Now Assist and AI-specific testing rounds it out, and given everything above, it's arguably the section carrying the most weight right now. That means testing what data the AI can access and surface past a user's normal ACL boundaries, assessing agent-to-agent discovery settings against the pattern AppOmni documented in November 2025, verifying how Virtual Agent API credentials are handled post-patch for CVE-2025-12420, and checking whether Now Assist skills were auto-activated on the instance, and under what privilege context they're actually running.

SOC 2 Type II assessors and ISO 27001 lead auditors are asking more of these questions now, specifically whether the GRC and ITSM platforms holding customer data have gone through independent testing separate from the standard annual review cycle. Given what's turned up across BodySnatcher, the agent-to-agent injection pattern, and a REST endpoint left wide open by one flipped configuration flag, that question is not paperwork. That question should be asked before the next finding gets a name.