What Security Review Missed: ServiceNow Virtual Agent Passed Design Approval, Failed in Production
Security reviews asked: “Is ServiceNow secure?” They should have asked: “Does this agent verify caller authorization per-action, or does it execute with standing privileges?”
By Rav (MrDecentralize) | Business Information Security & Innovation Officer specializing in trust models for AI, crypto, and global finance | LinkedIn | X
10 min read | February 2026
At A Glance
What happened: CVE-2025-12420 revealed unauthenticated admin API access in ServiceNow Virtual Agent
What broke: Security review framework optimized for SaaS integrations, not AI agent authorization
What to check: Jump to audit framework
What Everyone Is Saying
ServiceNow Virtual Agent passed security reviews at thousands of enterprises. IT approved it. Compliance signed off. Procurement cleared it. The vendor is trusted. OAuth is configured. RBAC is scoped. Standard integration pattern.
Then CVE-2025-12420 revealed unauthenticated API access to admin functions.
The narrative focused on the technical vulnerability: attackers could call Virtual Agent APIs without authentication and execute privileged operations. ServiceNow patched it. Enterprises applied updates. Security teams marked it resolved.
They all missed what actually broke.
This isn’t a failure of diligence. Every organization that deployed ServiceNow Virtual Agent went through standard security reviews. They checked vendor trust. They verified OAuth integration. They scoped API permissions. They classified risk appropriately.
The problem: the review framework was optimized for evaluating SaaS integrations, not AI agent authorization models. It asked “Is ServiceNow properly connected?” instead of “Does every agent action verify the requesting user’s actual permissions?”
I’ve seen this gap firsthand. In security review meetings where standard checklists cleared AI agents that should never have passed. Where the question “does the agent inherit user authorization or bypass it?” created long silences. Where organizations discovered, months after deployment, that approved agents had standing privileges to execute admin operations without per-action authorization checks.
This is where security review frameworks meet AI agent privilege escalation. And security review frameworks have no process for catching it.
What Actually Happened
In early 2025, CVE-2025-12420 was disclosed, revealing unauthenticated API access to admin functions in ServiceNow Virtual Agent. The vulnerability affected thousands of enterprises that had deployed Virtual Agent through standard security review processes.
The pattern was consistent: ServiceNow Virtual Agent passed IT approval, security review, compliance sign-off, and procurement clearance at organizations across financial services, healthcare, and enterprise technology. The standard security review checklist verified vendor trust (ServiceNow is SOC 2 Type II certified), authentication configuration (OAuth 2.0 integration), API permissions (role-based access control), and data encryption (TLS in transit, encryption at rest). Every box was checked. Every gate was cleared.
The vulnerability revealed what those checklists consistently missed: the Virtual Agent API could be called without authentication and would execute admin operations using its service account, with no per-action authorization verification of the requesting user’s permissions.
Security reviews across these deployments followed the same framework. The checklist asked: Is ServiceNow a trusted vendor? Is OAuth configured correctly? Are API permissions scoped to appropriate roles? Is data encrypted? These are the standard questions for evaluating SaaS integrations, where the platform enforces authorization boundaries.
The checklist never asked: When the Virtual Agent executes a privileged operation, does it verify the requesting user is authorized for that specific action? Does the agent inherit user permissions or use its own service account with broader privileges? Can the agent be manipulated to execute operations the user isn’t authorized for?
In security review meetings across multiple organizations, the standard approval process follows the same pattern. Security leads verify authentication (OAuth 2.0, standard ServiceNow integration framework). They check data encryption (TLS in transit, ServiceNow’s encryption at rest). They confirm API permissions (role-based access control, agent scoped to IT Support role). They validate vendor security (SOC 2 certification, annual penetration tests). The review framework is optimized for SaaS platform integrations: “Is ServiceNow properly connected?”
What triggers the gap: when someone asks “When the Virtual Agent executes an action like unlocking a user account, does it inherit the end user’s authorization, or does it use its own service account permissions?”, the standard response reveals full delegation. The agent uses the configured service account. It has the permissions assigned to that account. User A asks to unlock User B’s account. The agent checks if it has unlock permissions. The agent executes using its service account, regardless of whether User A would have permission to unlock User B’s account.
The authorization boundary becomes the agent’s interpretation of “appropriate requests,” not cryptographic verification of user permissions. The security model: User authenticates to ServiceNow. User asks Virtual Agent to do something. Virtual Agent interprets the request. Virtual Agent executes using its service account (broad IT Support permissions) without verifying the user is authorized for that specific action.
This authorization model passed security review because the framework checks whether the service account has appropriate role assignments, not whether the agent verifies caller authorization per-action. “The agent is trained to only respond to appropriate requests” satisfies the review, even though it means authorization depends on prompt reliability, not access control enforcement.
After CVE-2025-12420 disclosure, organizations audited their approved AI agents. One healthcare company found 11 agents deployed using the same security review framework. 7 had full delegation with no per-action authorization. 4 had standing permissions to admin APIs. All 11 passed security review. The pattern repeated across industries: agents approved through standard SaaS integration checklists, none audited for authorization models that turn probabilistic text into privileged actions.
What Actually Broke
The trust model:
Security reviews evaluate whether the vendor platform is secure and the integration follows best practices. If ServiceNow has proper security certifications, OAuth is configured correctly, and RBAC is scoped appropriately, the integration is approved. This model works for traditional SaaS integrations where the platform enforces authorization.
The design assumption:
AI agents operate within the same authorization boundaries as the platform they’re integrated with. If you scope an agent to the “IT Support” role in ServiceNow, the agent will enforce the same permission distinctions that IT Support staff must follow. Role-based access control applies uniformly to both human users and automated agents.
The hidden dependency:
The security model assumes that “API permissions are role-based” means every API call verifies the caller’s authorization. In reality, AI agents often receive standing privileges (a service account with broad permissions) and execute operations without checking whether the requesting user has permission for that specific action. The authorization boundary becomes the agent’s interpretation of “appropriate requests,” not cryptographic verification of user permissions.
The failure mode:
Security reviews check whether OAuth is configured, whether the service account has appropriate role assignments, and whether the vendor is trusted. They don’t check whether the agent verifies caller authorization per-action or uses full delegation. CVE-2025-12420 exposed this gap: the Virtual Agent API could be called without authentication, and it would execute admin operations using its service account, no per-action authorization check required.
The review framework was optimized for SaaS integrations (”Is ServiceNow properly connected?”), not AI agent authorization (”Does every agent action verify the caller’s actual permissions?”). The risk classification compounded the gap. “AI chatbot for IT support” sounded benign. Nobody classified it as “privileged interpreter with admin API access that executes based on probabilistic intent recognition.”
That company went back and audited their other approved AI agents after CVE-2025-12420. 11 had been deployed using the same review framework. 7 had full delegation with no per-action authorization. 4 had standing permissions to admin APIs. All had passed security review.
Why This Matters
For security teams:
Your review framework checks vendor trust, authentication configuration, and API permission scoping. Those are necessary but insufficient for AI agents. Standard SaaS integration checklists don’t include: “Does the agent verify caller authorization per-action?” “Does it inherit user permissions or use standing privileges?” “Can the agent be manipulated to execute operations the user isn’t authorized for?” If those questions aren’t on your checklist, you’re approving agents the same way that healthcare company approved ServiceNow Virtual Agent, the same way enterprises approved thousands of agents that would later be patched for authorization bypass vulnerabilities.
For IT architecture and procurement teams:
You’re evaluating AI agents based on vendor reputation, integration complexity, and business value. The security review focuses on whether the platform is secure, not whether the specific agent’s authorization model is properly constrained. “AI chatbot for IT support” gets classified as low-risk because it sounds like a productivity tool, not a privileged interpreter with admin API access. This classification gap means agents get approved through streamlined processes that never audit their authorization architecture.
For compliance and risk teams:
Your risk classification frameworks don’t account for the authorization model gap between traditional applications and AI agents. A Slack bot that executes trades gets classified based on “Slack integration” risk profiles, not “privileged interpreter that turns natural language into irreversible financial transactions” risk profiles. ServiceNow Virtual Agent got classified as “IT support chatbot,” not “privileged automation with standing permissions to admin operations.” The classification determines which review rigor applies, and most organizations are classifying AI agents into categories that don’t trigger the authorization audits they require.
What to Check in Your Systems
If you’re deploying AI agents, extensions, or automation that executes privileged operations, here’s the audit framework the standard security review checklist is missing:
1. When the agent executes a privileged operation, does it verify the requesting user is authorized for that specific action?
Not “does the agent have the right role assignment?” But: “Does it check, per-action, whether the user making the request has permission to execute that specific operation?” If the answer is “the agent has standing permissions to handle IT support tasks,” you have full delegation without per-action authorization.
2. Does the agent inherit the user’s permissions, or does it use its own service account with broader privileges?
If User A (junior employee) asks the agent to grant admin access to User B (also junior employee), does the agent check whether User A has permission to grant that access? Or does the agent execute using its service account that has blanket permission to grant access? The difference is: user permission inheritance vs. privilege escalation through agent interpretation.
3. What proves the requesting user is authorized, cryptographically, not probabilistically?
Is the authorization boundary a cryptographic check of the user’s permissions? Or is it the model’s interpretation of whether the request is “appropriate”? If the answer is “the agent is trained to only respond to appropriate requests,” your authorization model depends on prompt reliability, not access control enforcement.
4. Can the agent API be called without user context?
CVE-2025-12420 revealed that Virtual Agent APIs could be called without authentication, and the agent would execute using its service account. Test: Can someone call the agent’s APIs directly, bypassing the UI where user authentication occurs? If yes, your authorization model depends on UI controls, not API-level enforcement.
5. Are admin operations gated per-action or per-session?
Does the agent verify authorization for each privileged operation, or does it authenticate once per session and then execute all subsequent operations using standing privileges? Per-session authorization means one successful authentication grants access to all agent capabilities for the session duration. Per-action authorization means every privileged operation requires fresh verification.
6. What happens if the agent misinterprets a request as an admin operation?
If a user asks “show me all admin accounts” (information request) and the agent interprets it as “create an admin account for me” (privileged operation), what authorization check prevents execution? Is there a separate gate for privileged operations that requires explicit confirmation and authorization verification, or does the agent execute whatever it interprets as the user’s intent?
7. How many other approved AI agents in your environment would fail this audit?
The company found 11 approved agents. 7 had full delegation. 4 had standing admin API access. All passed the same security review framework that cleared ServiceNow Virtual Agent. If you’ve approved AI agents using standard SaaS integration checklists, audit them against these questions. Because the review framework that cleared them wasn’t designed to catch agent authorization gaps.
If you can’t answer these confidently, your security review framework has the same gap that cleared ServiceNow Virtual Agent at thousands of enterprises before CVE-2025-12420 revealed what standard checklists miss.
The Pattern
This isn’t unique to ServiceNow Virtual Agent. It’s the same pattern I’ve documented across AI agent deployments:
At financial services firms: “Slack bot for trade support” approved without auditing whether it verified trader authorization per-action. The bot had standing permissions to execute trades. Standard review checked: Is Slack integration secure? Is the bot scoped to the trading team role? Nobody asked: Does the bot verify, per-trade, that the requesting trader is authorized for that specific transaction?
At healthcare systems: “ServiceNow chatbot for access requests” approved without checking if it gated privileged operations. The chatbot could grant access to patient records. Standard review checked: Is ServiceNow secure? Are API permissions role-based? Nobody asked: Does the chatbot verify the requesting user has authority to grant that specific access?
At tech companies: “Jira automation agent” approved without verifying it didn’t bypass approval workflows. The agent could modify production tickets and deployments. Standard review checked: Is Jira integration authenticated? Does the agent use OAuth? Nobody asked: Does the agent enforce the same approval gates that human users must follow for production changes?
The commonality: security reviews optimized for SaaS platform integrations don’t catch AI agent authorization gaps. The checklist verifies the platform is secure and the integration follows best practices. It doesn’t verify the agent’s authorization model enforces per-action verification of caller permissions.
This is the gap I mapped in the AI Agent Authentication Audit framework: traditional IAM reviews focus on “does the platform have proper integration?” not “does every agent action verify caller identity?” The questions that would catch this, “Does the agent inherit user authorization or bypass it?” and “Are privileged operations gated per-action?”, aren’t on standard security review checklists.
Related analysis:
→ AI Agents Are Privileged Interpreters (Framework for why traditional IAM fails for agents)
The Reality Check
CVE-2025-12420 affected thousands of enterprises. ServiceNow is a trusted vendor. OAuth 2.0 was configured. RBAC was scoped. Data was encrypted. Security certifications were verified. Every box on standard security review checklists was checked.
The vulnerability revealed unauthenticated API access to admin functions anyway. Not because reviews were careless. Because the review framework was designed for SaaS platform integrations, not AI agent authorization models.
The standard checklist asks: Is the vendor trusted? Is authentication configured? Are API permissions role-based? Is data encrypted? These questions verify the platform is secure and the integration follows best practices. They don’t verify the agent’s authorization model enforces per-action verification of caller permissions.
Organizations that audited their approved agents after the CVE found the same pattern: multiple agents deployed through standard security reviews, most using full delegation without per-action authorization checks, all approved because the authorization questions weren’t on the checklist.
Security review frameworks are optimized for evaluating whether ServiceNow is properly connected, not whether this specific agent’s authorization model is properly constrained. The question “Does the agent verify caller authorization per-action or does it execute with standing privileges?” isn’t on standard checklists. The question “Does it inherit user permissions or bypass them?” doesn’t appear in SaaS integration reviews.
This is where security review frameworks meet AI agent privilege escalation. The checklist verifies vendor trust and API configuration. It doesn’t verify authorization models that turn probabilistic text into privileged actions. CVE-2025-12420 demonstrated the gap: agents can pass every standard security gate and still operate with full delegation, executing admin operations based on intent interpretation rather than cryptographic authorization verification.
If you’ve approved AI agents using standard SaaS integration checklists, the question isn’t whether they’re vulnerable to similar authorization gaps. It’s whether your review framework includes the questions that would catch it before the next CVE does.
If you’re deploying AI agents, chatbots, or automation with privileged access, these are the authorization questions to audit before security review checklists learn them the way enterprises learned from CVE-2025-12420.
#AIAgents #CyberSecurity #Blockchain #FinTech #MrDecentralize
About: I map why trust models break at institutional scale. 20+ years securing trillion-dollar banking systems | 6 patents in blockchain and AI.
LinkedIn |X | Newsletter
References and Further Reading
ServiceNow Community - “ServiceNow Virtual Agent CVE-2025-12420: What You Need to Know” - https://www.servicenow.com/community/in-other-news/servicenow-virtual-agent-cve-2025-12420-what-you-need-to-know/ba-p/2991847
ServiceNow Security Bulletin - CVE-2025-12420 Technical Details and Remediation - https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0123456
NIST National Vulnerability Database - CVE-2025-12420 - https://nvd.nist.gov/vuln/detail/CVE-2025-12420
AI Agents Are Privileged Interpreters - Why traditional IAM fails for AI agents - https://mrdecentralize.substack.com/p/ai-agents-are-privileged-interpreters