ServiceNow virtual agent exposure shows AI integration security gaps

At a glance

What this is: This is an analysis of a critical ServiceNow Virtual Agent flaw that could enable arbitrary code execution and full enterprise compromise through weak API credential handling and minimal verification.

Why it matters: It matters because AI-enabled service workflows now sit inside identity and access pathways, so NHI, autonomous, and human IAM teams all need to recheck authentication, privilege, and monitoring assumptions.

👉 Read ZioSec's analysis of the ServiceNow Virtual Agent AI vulnerability

Context

ServiceNow Virtual Agent is an AI-assisted support interface, but the security issue described here is not about chat quality. The problem is that a system with account and workflow authority was tied to weak verification and a shared external credential, which turns identity design into the primary attack surface for AI-integrated enterprise services.

In practice, this is the point where human IAM, NHI controls, and AI workflow governance collide. If a third-party service can authenticate with a reusable credential and then act inside a business system, the programme is no longer just securing a chatbot, it is governing a privileged execution path that can create accounts, trigger actions, and spread laterally.

Key questions

Q: What breaks when an AI-integrated service uses one shared credential for many third-party connections?

A: A shared credential collapses accountability and widens the blast radius. If multiple services use the same secret, one compromise can expose every integration that trusts it. Organisations lose the ability to trace which external actor did what, and revocation becomes disruptive because one secret may support many workflows at once.

Q: Why do email-only checks fail for AI workflows that can change enterprise state?

A: Email-only checks provide weak assurance and are easy to abuse when the resulting action is administrative. If the AI can create users, modify permissions, or call connected systems, the identity proof must match that risk. Otherwise, the system is trusting a low-assurance signal to authorise high-impact actions.

Q: How should security teams detect abuse of an AI-supported enterprise workflow?

A: Focus on post-authentication behaviour, not just login events. Look for new admin accounts, unusual API patterns, and AI-initiated actions from unknown sources. Those signals reveal when a legitimate-looking session has crossed into privilege abuse, which is the stage where damage becomes durable.

Q: Who is accountable when an AI integration is used to create administrative access?

A: Accountability sits with the teams that own the integration, the identity controls, and the downstream system it can touch. If a third-party service can create privileged accounts, then IAM, application owners, and security operations all share responsibility for the trust boundary and the resulting access decisions.

Technical breakdown

Shared external API credentials and weak service authentication

The article describes a universal credential, "servicenowexternalagent," used across third-party services authenticating to the Virtual Agent API. That pattern creates a classic NHI exposure: one shared secret becomes a broad trust token, and once it is guessed or obtained, the attacker is no longer forced to break authentication per tenant or per integration. The real failure is not only the secret itself, but the fact that a single credential appears to represent multiple external actors with different trust levels. In identity terms, that collapses attribution, rotation discipline, and blast-radius control into one weak point.

Practical implication: treat shared external credentials as a high-risk design flaw and isolate them from any pathway that can create or modify enterprise identities.

Email-only verification and the absence of step-up controls

The source says Virtual Agent relied primarily on email addresses for verification and did not pair the AI integration with stronger authentication protocols such as MFA. Email-only verification is adequate for low-risk interactions, but not for actions that can alter accounts or invoke downstream workflows. Once the attacker can satisfy that weak check, the system has no additional barrier before granting access to AI-driven functionality. This is where authentication stops being a user experience choice and becomes a privilege boundary problem. The platform is effectively trusting identity evidence that is too easy to spoof for the impact level involved.

Practical implication: require step-up authentication or equivalent risk checks before any AI-enabled action that can affect accounts, permissions, or connected systems.

Arbitrary code execution to administrative account creation and lateral movement

According to the article, successful exploitation could allow arbitrary code execution, creation of new administrative accounts, and lateral movement across interconnected systems. That progression matters because the AI layer is not just being used as an interface, it becomes an execution path into the core environment. In enterprise terms, the attack chain moves from initial access to durable privilege and then to expansion of control. Once admin accounts are created, the attacker can preserve access even if the original weakness is found. The vulnerable design therefore turns one exposed integration into a full control-plane compromise.

Practical implication: monitor for unauthorized admin creation and lateral movement signals as direct indicators that an AI integration has crossed from misuse into compromise.

Threat narrative

Attacker objective: The attacker aims to turn a weakly protected AI integration into durable administrative control over enterprise systems.

1. Entry occurs when an attacker acquires or guesses the shared external credential used to authenticate to the Virtual Agent API, then uses email-only verification to reach the workflow.
2. Escalation follows when the authenticated session is used to execute arbitrary code and create new administrative accounts, converting weak identity proof into persistent privilege.
3. Impact appears when the attacker uses that access to move laterally across connected systems and extend control beyond the original chatbot boundary.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared external credentials are not just secrets, they are delegated trust without lifecycle control: A universal credential used across third-party services turns one authentication artifact into many identities with the same effective privilege. That pattern breaks the assumption that external actors can be individually governed, reviewed, and offboarded. The implication is that organisations must stop treating shared integration credentials as low-risk plumbing and recognise them as a governance failure in the access model.

Email-only verification was designed for low-assurance interaction, not administrative AI actions: The article shows a control stack that verifies identity too weakly for the consequences it authorises. That mismatch lets an attacker satisfy the front door and then use AI-driven functionality to create accounts and expand access. The implication is that assurance level must be matched to the action being taken, not to the convenience of the channel.

Identity blast radius is the right concept for this failure mode: Once an attacker controls a single AI-integrated service path, the damage is not confined to the chatbot. The attack can pivot into admin creation and lateral movement, which means the identity boundary was already too wide before the exploit began. Practitioners should read this as evidence that workflow authority and identity authority are now the same control problem.

Agentic AI changes the meaning of “authenticated access” in enterprise systems: The issue is not that the system contains AI, but that AI can be used to execute tasks that alter state once authentication has been satisfied. That collapses the old distinction between interface access and privileged action. The implication is that IAM programmes must govern what the AI can do after authentication, not just whether a session exists.

Monitoring needs to pivot from login events to privileged action patterns: Unauthorized admin account creation and unusual API calls are the signals that matter when AI-assisted workflows become the attack path. Traditional authentication logs do not explain intent or downstream abuse. Practitioners should treat post-authentication actions as the primary control surface for this class of exposure.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That visibility gap includes 38% with no or low visibility and a further 47% with only partial visibility, which leaves delegated access poorly governed.
• For a broader breach lens, The 52 NHI breaches Report shows how unmanaged third-party access repeatedly turns into privilege abuse.

What this signals

Shared trust is the hidden failure mode in many AI integration designs: once one external credential stands in for many actors, the programme loses the ability to prove who accessed what, when, and why. The practical response is to map every AI-connected integration to a distinct identity boundary and review where action authority exists beyond the point of authentication.

The governance lesson is broader than ServiceNow. As AI-assisted workflows become embedded in business systems, identity teams should expect more abuse that starts after authentication and before visibility catches up. The relevant control question is no longer whether the AI is connected, but whether its post-login actions are constrained, monitored, and attributable.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, this kind of exposure is not an edge case. It is the predictable outcome of allowing delegated access paths to grow faster than governance can see them.

For practitioners

• Eliminate shared external credentials for AI integrations Assign unique, traceable credentials to each third-party integration and revoke any universal secret that can authenticate multiple services through the same path. Shared trust tokens prevent clean attribution and widen the blast radius when one credential is exposed.
• Add step-up checks before sensitive AI actions Require stronger verification before any AI workflow can create accounts, modify permissions, or touch connected systems. Email-only verification is not enough when the resulting action can change enterprise state.
• Alert on unauthorized admin creation and API anomalies Build detection for new administrative accounts, unusual API calls, and AI-initiated actions from unrecognised sources. These are the earliest reliable signs that an integration has moved from normal use into abuse.
• Separate workflow access from privilege authority Constrain the AI layer so it cannot directly perform high-risk administration without a stronger approval boundary. The control objective is to prevent one authenticated session from becoming full system control.

Key takeaways

• The breach pattern shows that a shared AI integration credential and weak verification can turn a chatbot into a privileged entry point.
• The evidence points to arbitrary code execution, admin account creation, and lateral movement, which means the impact extends well beyond the original interface.
• The control that would have mattered most is tighter identity assurance at the action layer, backed by distinct credentials and monitoring for privileged post-authentication behaviour.

Key terms

• Shared External Credential: A single secret or token used by more than one external service or integration. In NHI governance, this creates weak attribution and a large blast radius because one compromise can expose every actor that trusts the same credential.
• Identity Blast Radius: The amount of enterprise access and downstream system impact that becomes available once one identity is compromised. For AI-integrated services, blast radius grows when one authenticated workflow can create accounts, change permissions, or reach multiple connected systems.
• Step-up Authentication: Additional verification required before a high-risk action is allowed. In AI-supported systems, step-up controls should be tied to the action being attempted, so account creation or privilege changes require stronger assurance than ordinary chatbot use.
• Delegated Access Path: A route by which one system or service acts on behalf of another using shared trust or scoped permissions. This matters in NHI security because delegated paths often hide the real actor behind the visible integration, making review and offboarding harder.

Deepen your knowledge

AI integration identity and delegated access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing service workflows that can change accounts or permissions, it is worth exploring.

This post draws on content published by ZioSec: Critical AI Vulnerability in ServiceNow's Virtual Agent Exposed. Read the original.