OASB
v1.0
Originally published on opena2a.org
#vulnerability-analysis#ai-security#ai-agents#case-study

The ServiceNow AI Vulnerability: What Went Wrong and How to Secure Your AI Agents

Abdel Fane||12 min read

Executive Summary: January 2026 marked a turning point in AI security. ServiceNow disclosed what researchers called "the most severe AI-driven vulnerability uncovered to date" -- exposing 85% of Fortune 500 companies to potential takeover through improperly secured AI agents.

This wasn't just another CVE. It was a wake-up call: AI agents need purpose-built security, not retrofitted legacy authentication.

What Happened: The Technical Breakdown

ServiceNow operates as the IT service management backbone for 85% of the Fortune 500. The platform connects deeply into customers' HR systems, databases, customer service platforms, and security infrastructure -- making it both a critical operational system and a high-value target for attackers.

When ServiceNow added agentic AI capabilities to their existing Virtual Agent chatbot through "Now Assist," they created a perfect storm of vulnerabilities:

Vulnerability #1: Universal Credential Sharing

ServiceNow shipped the same credential to every third-party service that authenticated to the Virtual Agent API:

# The credential used across ALL ServiceNow customers
credential = "servicenowexternalagent"

Aaron Costello, chief of security research at AppOmni (who discovered the vulnerability), found that any attacker could authenticate to ServiceNow's Virtual Agent API using this well-known string. No rotation, no uniqueness per customer, no cryptographic verification.

Vulnerability #2: Email-Only Authentication

To impersonate a specific user, the system required only:

  • The user's email address
  • The target company's ServiceNow tenant URL (easily discoverable via subdomain scanning)
  • The universal API credential

No password. No MFA. No second factor.

# Simplified attack flow
attack = {
    "credential": "servicenowexternalagent",
    "user_email": "admin@targetcompany.com",
    "tenant_url": "targetcompany.service-now.com"
}

# Result: Full user impersonation

Vulnerability #3: Unrestricted AI Agent Capabilities

ServiceNow's "Now Assist" AI agents had extraordinarily broad permissions. One prebuilt agent allowed users to "create data anywhere in ServiceNow" -- with no scoping, no approval workflows, and no capability restrictions.

Costello demonstrated the exploit chain:

  1. Impersonate an admin user (using email + universal credential)
  2. Engage the AI agent via the Virtual Agent API
  3. Instruct the agent to create a new admin account
  4. Gain persistent access with full admin privileges

From there, an attacker could access all data stored in ServiceNow, pivot to connected systems, maintain persistence, and operate undetected.

Why This Matters: Supply Chain Amplification

This wasn't just a ServiceNow problem -- it was a supply chain risk multiplier. According to ServiceNow's own marketing materials, they serve 85% of Fortune 500 companies.

425+
Fortune 500 companies
Millions
Employees' HR data
Countless
Customer records
∞
Interconnected systems
"It's not just a compromise of the platform and what's in the platform -- there may be data from other systems being put onto that platform. If you're any reasonably-sized organization, you are absolutely going to have ServiceNow hooked up to all kinds of other systems."
-- Aaron Costello, AppOmni

Root Cause: AI Grafted Onto Legacy Systems

The ServiceNow vulnerability reveals a dangerous pattern emerging across the AI industry: agentic AI capabilities bolted onto systems that were never designed for autonomous operation.

ServiceNow's Virtual Agent was originally a rules-based chatbot. When ServiceNow added "Now Assist" and granted AI agents the ability to "create data anywhere," they crossed a critical threshold -- but the underlying authentication and authorization models didn't evolve to match.

Traditional AppsAI Agents
Human makes every decisionAgent makes autonomous decisions
Predictable workflowsDynamic, emergent behavior
Fixed permissionsCapability drift over time
Human-verified actionsActions executed without human review
Single session scopePersistent, long-running operations

Legacy IAM wasn't designed for this.

The Five Security Principles AI Agents Need

Based on the ServiceNow vulnerability and our research into AI agent security, here are the five non-negotiable principles for securing autonomous AI:

1

Cryptographic Identity (Not Shared Credentials)

Every AI agent should have a unique, unforgeable identity based on public-key cryptography.

Bad (ServiceNow's approach):
# Same credential for all customers
credential = "servicenowexternalagent"
Good (Proper approach):
# Each agent gets Ed25519 keypair
agent_key = generate_ed25519_key()
signature = agent_key.sign(request)
verify_signature(signature, request)
2

Capability-Based Access Control

AI agents should be restricted to explicitly declared capabilities, not granted blanket "admin" access.

Bad (ServiceNow's approach):
# Agent can "create data anywhere"
@agent.capability
def create_data(location, data):
    database.insert(location, data)
Good (Proper approach):
@agent.perform_action("ticket:create")
def create_ticket(title, desc):
    tickets_db.insert({
        "title": title, "desc": desc
    })
3

Continuous Trust Evaluation

AI agents should be continuously monitored and scored based on behavioral signals.

Trust factors evaluated:
  • Verification Status (25%) - Ed25519 signature success rate
  • Uptime & Availability (15%) - Health check responsiveness
  • Action Success Rate (15%) - Percentage of successful actions
  • Security Alerts (15%) - Active security alerts by severity
  • Compliance Score (10%) - SOC 2, HIPAA, GDPR adherence
  • Age & History (10%) - How long agent has been operating
  • Drift Detection (5%) - Behavioral pattern changes
  • User Feedback (5%) - Explicit user ratings
trust_score = calculate_trust({
    "verification": 0.95,      # Ed25519 signatures verified
    "uptime": 0.98,            # Health check responsiveness
    "success_rate": 0.92,      # Percentage of successful actions
    "security_alerts": 0.85,   # Active alerts reduce this
    "compliance": 0.90,        # SOC 2 certified
    "age": 0.75,               # 30-90 days = 0.75
    "drift_detection": 1.0,    # No behavioral drift detected
    "user_feedback": 0.75,     # Average user feedback
})

# Weighted average: 0.90 (90%)

if trust_score < 0.30:
    mark_as_compromised()      # Agent lockdown
elif trust_score < 0.70:
    require_approval_for_sensitive_ops()
else:
    allow_autonomous_operation()
4

Comprehensive Audit Trails

Every agent action should be logged, attributed, and auditable.

{
  "timestamp": "2026-01-15T10:32:45Z",
  "agent_id": "agent-servicenow-virt-01",
  "agent_signature": "ed25519:a4b8c2d...",
  "action": "create_user",
  "parameters": {
    "username": "new_admin",
    "role": "admin"
  },
  "trust_score": 0.78,
  "capabilities": ["ticket:create"],
  "result": "DENIED - capability not granted",
  "risk_factors": ["capability_escalation_attempt"]
}
5

Fail-Safe Defaults

Security controls should fail closed, but operational systems should fail open (to prevent denial-of-service via security infrastructure).

try:
    # Attempt cryptographic verification
    verify_agent_signature(agent_id, signature)
    trust_score = evaluate_trust(agent_id)

    if trust_score < MINIMUM_THRESHOLD:
        # Fail closed: Block untrusted agent
        raise SecurityError("Insufficient trust")

    execute_agent_action(agent_id, action)

except SecurityInfrastructureDown:
    if PRODUCTION_MODE:
        # Fail open: Allow operation, log warning
        logger.warning("Security service down")
        execute_agent_action(agent_id, action)
    else:
        # Fail closed in dev/test
        raise

How AIM Prevents ServiceNow-Style Vulnerabilities

We built Agent Identity Management (AIM) specifically to address these gaps. Here's how AIM would have prevented each attack vector:

Attack Vector #1: Universal Credential

ServiceNow's Vulnerability:
credential = "servicenowexternalagent"
AIM's Approach:
from aim_sdk import secure

agent = secure("servicenow-agent")
# Unique Ed25519 identity
# Cryptographic signing
# Server verification

Result: No universal credentials. Every agent has a unique, unforgeable identity.

Attack Vector #2: Email-Only Auth

# Multi-factor agent authentication
auth = {
    "agent_id": "agent-001",
    "signature": agent.sign(request),    # Cryptographic
    "trust_score": 0.85,                 # Behavioral
    "capabilities": ["ticket:create"],   # Declared
    "timestamp": current_time(),         # Replay prevention
}

if not verify_all_factors(auth):
    deny_request()

Result: Cryptographic proof of identity, not just a guessable email address.

Attack Vector #3: Unrestricted Capabilities

from aim_sdk import secure

agent = secure("support-agent")

# Explicitly declare capabilities
@agent.perform_action("ticket:create")
def create_ticket(title, description):
    tickets_db.insert({"title": title, "desc": description})

# This would fail - capability not declared
@agent.perform_action("user:create_admin")
def create_admin(username):
    # AIM blocks this at runtime
    # Logs capability escalation attempt
    # Reduces trust score
    pass

Result: Principle of least privilege enforced automatically. Agents can't escalate beyond declared capabilities.

Real-Time Detection & Response

When Costello's attack attempted to create an admin account, AIM would have:

# 1. Detected capability escalation
alert = {
    "severity": "CRITICAL",
    "type": "capability_escalation",
    "agent_id": "agent-servicenow-virt-01",
    "attempted_action": "user:create_admin",
    "declared_capabilities": ["ticket:create"],
    "risk_score": 0.95
}

# 2. Reduced trust score
update_trust_score(agent_id, -0.20)  # 0.78 -> 0.58

# 3. Marked agent as compromised
mark_as_compromised(agent_id, reason="capability_escalation")

# 4. Alerted security team
notify_security_team(alert)

# 5. Blocked the operation
return {"status": "DENIED", "reason": "Insufficient privileges"}

Result: Attack detected and blocked in real-time, with full audit trail.

Lessons for AI Builders

If you're building or deploying AI agents, here are the actionable takeaways from ServiceNow's vulnerability:

DO:

  • - Treat AI agents as first-class identities with cryptographic credentials
  • - Implement capability-based access control
  • - Monitor agent behavior continuously
  • - Log everything for forensics
  • - Review agent permissions regularly
  • - Test with adversarial inputs
  • - Assume compromise (defense-in-depth)

DON'T:

  • - Share credentials across agents
  • - Grant blanket admin access
  • - Skip authentication for "internal" agents
  • - Trust AI agents implicitly
  • - Bolt AI onto legacy auth
  • - Ignore capability escalation attempts
  • - Deploy without audit trails

Final Thoughts

The ServiceNow vulnerability wasn't an anomaly -- it was a preview.

As AI agents become critical infrastructure, the security models that protected human-operated systems won't be enough. We need purpose-built identity, authentication, and authorization for autonomous AI.

The good news? The solutions exist. They just need to be adopted before the next headline-grabbing breach.

Secure Your AI Agents

AIM provides cryptographic identity, capability-based access control, trust scoring, and comprehensive audit trails for AI agents. Open source and free.

View on GitHubTry AIM Free