The emergence of agentic AI presents new security challenges because it lets loose multiple autonomous agents to act on behalf of humans. Once an AI agent is trusted to execute workflows or make decisions autonomously, any misconfigured permission, shared credential, or flawed linking mechanism can turn an AI agent into a proxy for attackers, capable of performing real actions at machine scale.
That was evident when Aaron Costello, Chief of Security Research at AppOmni, a SaaS security firm, discovered a critical agentic hijacking vulnerability, known as BodySnatcher, in ServiceNow’s Virtual Agent API and the Now Assist AI Agents application. According to Costello, “AI agents significantly amplify the impact of traditional security flaws.”
“BodySnatcher represents the most severe AI-driven security vulnerability uncovered to date and a defining example of agentic AI security vulnerabilities in modern SaaS platforms.”
The exploit “demonstrates how an attacker can effectively ‘remote control’ an organization's AI, weaponizing the tools meant to simplify enterprise workflows,” Costello added.
“This finding is particularly significant given the scale of the risk; ServiceNow's Now Assist and Virtual Agent applications are utilized by nearly half of AppOmni's Fortune 100 customers.”
What caused the vulnerability, and how can enterprises avoid such exploits in their systems?
How a Single Integration Let Attackers Impersonate Any ServiceNow User
A specific integration between the Virtual Agent API and Now Assist allowed unauthenticated attackers to impersonate any ServiceNow user using only an email address, bypassing multi-factor authentication (MFA), single sign-on (SSO) and other access controls.
By chaining a hardcoded, platform-wide secret with account-linking logic that trusts a simple email address, an attacker would be able to impersonate an administrator and execute an AI agent to override security controls and create backdoor accounts with full privileges.
“Insecure configurations transformed a standard natural language understanding (NLU) chatbot into a silent launchpad for malicious AI agent execution,” according to Costello.
“This could grant nearly unlimited access to everything an organization houses, such as customer Social Security numbers, healthcare information, financial records, or confidential intellectual property.”
The vulnerability affected ServiceNow instances running Now Assist AI Agents (sn_aia) versions 5.0.24 through 5.1.17 and Virtual Agent API (sn_va_as_service) <= 3.15.1 and 4.0.0 – 4.0.3.
AppOmni reported the vulnerability to ServiceNow on October 23, 2025 and the vendor immediately acknowledged receipt of vulnerability. On October 30, ServiceNow fixed the vulnerability and emailed customers to inform them of the vulnerability. It also released a knowledge base article crediting Costello and AppOmni. The company stated this week:
“ServiceNow addressed this vulnerability by deploying a relevant security update to the majority of hosted instances. Security updates were also provided to ServiceNow partners and self-hosted customers. Additionally, the vulnerability is addressed in the listed Store App versions.”
How Virtual Agent Normally Keeps Things Safe
Virtual Agent is ServiceNow's enterprise chatbot engine, built to simplify everyday tasks inside large organizations. It uses NLU to give users a conversational way to interact with the system's underlying data and services.
Employees can ask a chatbot to reset a password, order equipment, or file a support ticket, and each request is routed to a predefined workflow known as a “topic.” These topics can only perform actions explicitly allowed by developers, which is why Virtual Agent has long been viewed as relatively low risk.
The Virtual Agent API extends this system beyond ServiceNow’s web interface, allowing external platforms like Slack or Microsoft Teams to send messages into the same topic framework. In that way, users can interact with the system without needing to log in to ServiceNow directly.
Rather than exposing separate endpoints for each integration, ServiceNow uses a shared API and distinguishes callers using “providers” and “channels.” Each provider defines how requests are authenticated and how an external user is linked to a ServiceNow account.
For authentication, many providers rely on Message Auth, which uses a static secret tied to the integration rather than a specific user. To determine who the user is, providers can enable a feature called auto-linking, which associates an external identity with a ServiceNow account. Once linked, all actions run with that user’s permissions.
Configuration Choices That Opened the Door
The vulnerability emerged when ServiceNow introduced new providers for its Now Assist AI Agents to extend the capabilities of the Virtual Agent API beyond bot-to-bot use cases to support bot-to-agent or agent-to-agent (A2A) interactions.
As each integration uses its own provider within ServiceNow to define how incoming messages are authenticated, the vendor removed the need to create new API endpoints for each integration. As Costello noted:
“It’s reasonable to assume ServiceNow chose this approach to provide a more seamless experience for end users, fully leveraging the transparent nature of auto-linking.”
These providers reused the same Message Auth and auto-linking mechanisms, but with critical flaws.
The providers “shipped with the exact same secret across all ServiceNow instances. This meant anyone who knew or obtained the token could interact with the Virtual Agent API of any customer environment where these providers were active,” according to Costello.
Worse, the auto-linking logic trusted any request that presented this shared secret, without multi-factor authentication. An attacker only needed a valid email address to be linked to that user’s ServiceNow account. From that point on, Virtual Agent treated the attacker as the impersonated user.
At first, the security risk appeared to be limited. Messages were asynchronous, and responses were routed to predefined endpoints the attacker couldn’t control.
“Nevertheless, the token provided a universal, instance-agnostic authentication bypass that should never have existed at all,” Costello pointed out.
