ServiceNow AI identity failure exposes runtime trust gaps in agents

At a glance

What this is: This is an analysis of a critical ServiceNow AI vulnerability that let attackers impersonate users, abuse workflows, and pivot into connected systems through weak runtime identity checks.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern identity trust inside execution flows, not just at login or provisioning boundaries.

By the numbers:

• In late December 2025, security researchers disclosed the critical vulnerability as CVE-2025-12420.

👉 Read Silverfort's analysis of ServiceNow AI identity abuse and CVE-2025-12420

Context

ServiceNow AI identity risk is the practical problem here: when an automation layer accepts identity context once and then reuses it across workflows, the platform starts trusting execution rather than the actor. In this case, a static integration credential and weak API-layer identity verification allowed actions to proceed under a forged identity.

That pattern matters well beyond one product. IAM teams, PAM teams, and NHI owners are all seeing the same structural issue: once an identity assertion is treated as durable, every downstream workflow inherits the original trust decision, even when the actor is not the one that authenticated.

Key questions

Q: What breaks when an AI platform treats a single identity assertion as trustworthy for an entire workflow?

A: The control model breaks because identity stops being a runtime control and becomes a static label. An attacker who can forge or borrow that label can drive privileged actions through approved workflows, and every downstream decision inherits the original mistake. The result is authorization without current proof, which is exactly where control-plane abuse begins.

Q: Why do service accounts or embedded credentials increase risk in AI control planes?

A: They increase risk because long-lived credentials can be reused to reach privileged APIs without the user or actor being present at the moment of action. If the platform does not revalidate identity context before sensitive steps, a compromised integration can impersonate authority and turn normal automation into administrative compromise.

Q: How should security teams test whether workflow automation is creating hidden privilege paths?

A: They should map every workflow that can change identity state, then test whether that workflow can be triggered under a false identity or through an inherited trust chain. The key signal is whether a non-human actor can create accounts, change roles, or reset credentials without a fresh identity proof.

Q: Who is accountable when an AI agent or workflow executes privileged actions under a forged identity?

A: Accountability sits with the organisation that allowed authority to flow without revalidation. If the identity proof is stale, delegated, or implicit, then the governance failure is architectural, not operational. Frameworks such as Zero Trust and NHI governance both point to the same issue: trust must be continuously asserted, not assumed.

Technical breakdown

Static credential binding and forged identity context

The vulnerability combined a static integration credential with insufficient identity verification at the API layer. That means the system treated an asserted identifier, such as an email address, as enough proof to continue authorising actions. In practice, this collapses assurance because the platform no longer distinguishes between an authenticated session and a borrowed or forged identity context. Once the API accepted the claim, downstream automation used it as if it were true. This is a classic identity binding failure: the credential or token is present, but the system does not prove that the runtime actor still matches the original identity assertion.

Practical implication: verify identity at the point of action, not only at session start.

Agent-to-agent trust and delegated authority

Agentic systems pass authority across workflows, and that creates a confused-deputy problem when delegated actions are not revalidated. In the described attack path, an attacker could invoke AI agents to create privileged accounts and modify roles through approved workflows. The workflow executed correctly, but under a false identity context. This is not ordinary misconfiguration. It is transitive trust without runtime reassertion. When one agent acts on behalf of another without checking intent and identity again, the trust boundary moves deeper into the execution chain and becomes harder to observe, log, or revoke.

Practical implication: break transitive trust chains by forcing revalidation before delegated actions.

Business logic abuse in AI control planes

The exploit did not need a novel payload once identity was accepted. It relied on legitimate workflows, approvals, and configuration changes behaving exactly as designed. That is why business logic becomes the attack surface in AI-enabled control planes. When the platform uses automation to provision access, reset credentials, or suppress alerts, an attacker only needs a false identity to turn standard operations into compromise steps. The dangerous part is not code execution in the usual sense. It is authorised state change at scale, where the system itself becomes the mechanism of persistence and lateral movement.

Practical implication: review control-plane workflows as attack paths, not just administrative convenience.

Threat narrative

Attacker objective: The attacker’s objective is durable administrative control of the tenant and pivot access into downstream enterprise systems.

1. Entry occurs when an attacker learns a tenant URL and a privileged user email, then exploits the vulnerable Virtual Agent API to impersonate that user without authenticating.
2. Escalation follows when Now Assist AI agents are used to create an administrative account, assign high-privilege roles, and perform authorised state changes under a forged identity.
3. Impact comes when the attacker pivots into connected enterprise systems, resets credentials, and gains persistent control through the ServiceNow control plane.

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

Runtime identity binding is now a control plane issue, not a login issue. The ServiceNow case shows that identity can be accepted once and then incorrectly treated as durable across an entire automation chain. That assumption was designed for human-paced sessions and bounded workflow handoffs. It fails when the actor can drive multiple actions through agents and approvals without a fresh identity proof at each step. The implication is that governance must stop treating authentication as the end of the control story.

Static credential binding: was designed for integrations that behave like stable services. That assumption fails when the actor can weaponise a credential to impersonate another identity context at runtime and drive privileged workflows under that false context. The implication is not simply stronger secrets handling. It is a rethink of what makes an identity trustworthy inside an execution flow.

Agent-to-agent trust abuse is a governance failure, not just an AI flaw. The exploit path relied on delegated authority moving across agents without revalidation of intent or identity. That exposes a confused-deputy pattern inside enterprise automation, where one trusted component becomes the proxy for a compromised one. Practitioners should read this as a warning that delegation chains need explicit governance, not implicit inheritance.

Workflow legitimacy can hide compromise when the identity layer is compromised first. The most dangerous part of this incident is that the platform can log attacker actions as normal administration. That erodes the value of identity-based monitoring, because behavioural analytics inherit the same false trust decision as the workflow engine. The practical conclusion is that audit fidelity depends on runtime identity assurance, not just on clean logs.

Runtime trust for agents: the control model assumed identity would remain valid for the duration of execution. That assumption fails when agents act, delegate, and compound authority without human review. The implication is that practitioners must rethink review cycles, trust propagation, and the boundary between authentication and authorisation.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• The same research found that organisations maintain an average of 6 distinct secrets manager instances, which fragments control and makes runtime trust harder to enforce.
• For a broader breach lens on identity-led compromise, see 52 NHI Breaches Analysis, which tracks recurring patterns of credential abuse and trust propagation.

What this signals

Runtime identity assurance will become the differentiator for AI-enabled control planes. Teams that already rely on automation to create, move, or revoke access need to assume that a single identity assertion is not durable enough for privileged execution. The practical signal is simple: if a workflow can still complete after the original authentication event is stale, the programme is operating on inherited trust.

Identity blast radius is the better planning concept than session duration. Once an attacker can turn a false identity into a legitimate workflow, the issue is not how long the session lasts but how far that identity can travel through approvals, provisioning, and downstream systems. That is why teams should pair runtime enforcement with reference material such as the Ultimate Guide to NHIs.

With 27 days as the average time to remediate a leaked secret, secret exposure cannot be treated as a short-lived operational nuisance, according to The State of Secrets in AppSec. The governance lesson is that delayed remediation and inherited trust create the perfect conditions for control-plane abuse.

For practitioners

• Revalidate identity at execution time Require fresh proof of identity before privileged workflow steps such as account creation, role assignment, and credential resets. Treat the action boundary as the control boundary, especially where AI agents or orchestration layers are involved.
• Inventory static integration credentials Find embedded credentials used by automation, then rotate them and replace long-lived bindings with tighter-scoped alternatives where possible. Focus first on credentials that can reach control-plane APIs or identity providers.
• Break delegated trust chains Force explicit revalidation when one agent, workflow, or service acts on behalf of another. If a downstream action can create privilege, reset secrets, or suppress alerts, the system should not inherit trust silently.
• Treat control-plane workflows as attack paths Map administrative workflows that can change identity state, then test them as adversary routes. Include provisioning, approval, escalation, and notification suppression paths in attack-path review exercises.
• Harden audit fidelity for AI actions Correlate workflow logs with identity assertions and runtime context so that a forged identity cannot produce a fully believable audit trail. If logs cannot distinguish the actor from the assertion, they cannot support reliable response.

Key takeaways

• This incident shows that AI platforms can become privilege engines when identity is trusted once and then reused across workflows.
• The evidence points to a control-plane failure, where forged identity context enabled administrative actions, persistence, and downstream pivoting.
• Teams need runtime identity revalidation, delegated trust boundaries, and workflow-level attack-path review to limit the blast radius.

Key terms

• Runtime Identity Binding: Runtime identity binding is the practice of verifying that the actor performing an action is still the same entity that was initially trusted. In AI and automation contexts, this means identity must be checked at the moment of privilege use, not only at login or provisioning time.
• Delegated Trust Chain: A delegated trust chain is the sequence of actions where one service, workflow, or agent acts on behalf of another. It becomes risky when each handoff inherits authority without fresh verification, because a compromise at one point can legitimise downstream abuse.
• Control-Plane Abuse: Control-plane abuse occurs when an attacker uses administrative workflows, rather than exploits, to change access, configuration, or identity state. The danger is that the system appears to be operating normally while it is actually being used to entrench compromise.
• Identity Blast Radius: Identity blast radius is the amount of system access, workflow reach, and downstream trust that a single identity can influence if compromised. The larger the blast radius, the more valuable runtime verification, scoped delegation, and rapid revocation become.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Silverfort covering the ServiceNow AI vulnerability: the identity failure that enabled impersonation and workflow abuse. Read the original.