ServiceNow AI identity failure exposes runtime trust gaps in agents

At a glance

What this is: This is an analysis of a ServiceNow AI authentication and authorisation flaw that enabled impersonation, workflow abuse, and downstream system pivoting through unverified runtime identity.

Why it matters: It matters because IAM and security teams cannot treat AI agent identity as a one-time login event when delegated actions, workflow execution, and control-plane trust all depend on continuous verification.

Context

ServiceNow AI identity failures show what happens when an agentic platform treats identity as a static assertion rather than a runtime control. In this case, identity was checked once at the entry point and then trusted through subsequent workflow execution, even as the system created privileged state changes on behalf of the attacker.

The governance gap is not simply weak authentication. It is a failure to bind identity, intent, and action together while an AI agent is executing. That matters for NHI governance, agentic AI identity, and any platform that can act as a control plane for downstream systems.

Key questions

Q: What breaks when an AI platform only checks identity once at the start of execution?

A: The control that breaks is runtime trust continuity. If the platform accepts an identity assertion once and reuses it for later privileged actions, an attacker can ride the original trust decision into workflow abuse, account creation, and downstream system changes. The failure is not the first check alone, but the absence of revalidation as actions unfold.

Q: Why do agentic workflows create more risk when they can trigger privileged actions in connected systems?

A: They create more risk because the original identity context can propagate into systems that assume the source platform already handled authorisation correctly. When that platform is compromised or misled, downstream controls inherit the error and may treat malicious actions as legitimate business process execution.

Q: What are the signs that delegated agent access is failing governance?

A: Common signs include missing provenance, broad permissions that outlast the task, and audit records that show what happened but not who effectively authorised it. If reviewers must reconstruct the originator, agent and target from separate logs, the governance model is already too weak for agentic workflows.

Q: How should security teams model AI agents in cloud governance when the agent runs through a service account?

A: Treat the agent as an identity surface, but treat the service account as the source of effective privilege. The agent itself usually acts through delegated access, so governance should trace the full chain from invoker to agent to service account to downstream resources. That approach exposes blast radius, shared credentials, and over-privileged paths before they turn into control gaps.

Technical breakdown

Why static integration credentials break runtime trust

A static integration credential gives a platform a durable trust anchor, but it also creates a long-lived path for identity misuse when the credential is used to authorize agent behaviour. In this incident, the weakness was not only credential exposure. The deeper problem was that the credential and the API logic together allowed actions to be executed under a false identity context. Once the platform accepted that context, later workflow steps inherited the original mistake. That is why agentic systems need per-action identity validation rather than a single trust decision at session start.

Practical implication: treat any static credential that can trigger agent actions as a runtime trust dependency, not a harmless integration detail.

How agent-to-agent trust becomes a confused deputy problem

Agent-to-agent delegation is safe only when the receiving agent re-evaluates who is acting and why. Here, the reported abuse pattern showed trust propagating across agents and workflows without revalidation, which is a classic confused deputy condition in a modern execution model. The intermediary agent performed permitted work, but on behalf of an untrusted or forged identity context. That means the control failure is not just missing authorisation. It is delegated authority being reused beyond the trust boundary that originally justified it.

Practical implication: enforce revalidation at each delegation step where one agent can trigger another agent or workflow.

Why workflow legitimacy can hide privilege escalation

The most dangerous aspect of this class of flaw is that the malicious activity can look like ordinary business process execution. In the ServiceNow case, approved workflows created administrative state changes, role assignments, and downstream access actions that would normally be logged as legitimate. That shifts detection from code-exploit hunting to identity and intent analysis. When the platform itself is trusted as a control plane, security teams must examine whether workflow outcomes still match the asserted identity and the expected scope of authority.

Practical implication: monitor for legitimate workflows that create privilege, not only for obviously malicious commands.

Threat narrative

Attacker objective: The attacker’s objective was to obtain persistent administrative control of the ServiceNow tenant and use that trusted position to reach connected enterprise systems.

1. Entry occurred through a vulnerable ServiceNow AI API that accepted weak identity assertions and allowed impersonation without proper authentication.
2. Credential and authority abuse followed when the attacker used the forged identity context to invoke AI-driven workflows and create privileged access.
3. Escalation continued as administrative state changes and delegated actions extended trust into connected systems that relied on ServiceNow as a control plane.
4. Impact was tenant-level control with a path to downstream enterprise systems, even though public evidence of broad exploitation was not reported.

Breaches seen in the wild

• JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.

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 requirement, not an enhancement. This incident shows that agentic platforms fail when identity is validated once and then assumed indefinitely. The trust gap is not in the workflow itself, but in the assumption that a verified identity remains trustworthy across every later action. For practitioners, the lesson is that execution identity must stay coupled to every privileged state change.

Identity review assumptions collapse when authority is delegated to agents. Access review processes were designed for identities whose privilege persists long enough to be reviewed after the fact. That assumption fails when an AI agent can create, delegate, and consume authority inside the same execution path. The implication is that governance must move closer to issuance and delegation time, because retroactive review cannot reconstruct what never remained stable.

Agent-to-agent trust abuse is a distinct governance failure mode. The article exposes a modern confused deputy pattern where one agent inherits and extends another identity context without revalidation. That is not the same as ordinary privilege escalation, because the abuse rides on legitimate workflow behaviour. Practitioners should treat delegated authority chains as a first-class identity boundary, not an implementation detail.

Weak identity binding creates an identity blast radius across control planes. Once a trusted platform can alter accounts, reset credentials, and trigger downstream provisioning, a single forged identity context can span multiple systems. That expands the blast radius far beyond the original application. The practitioner takeaway is to map where one platform can act on behalf of another, then govern that path as privileged infrastructure.

Runtime trust gaps are becoming the defining NHI and agentic AI failure pattern. The same design weakness appears whenever credentials, workflows, and delegation outlive the identity assertion that justified them. OWASP-NHI and OWASP-AGENTIC both reflect this convergence, but the deeper issue is governance continuity. Security teams need to question whether their identity model still works once action and authentication are separated in time.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• 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.
• Read next: Agentic AI Identity Guide

What this signals

Runtime trust gaps will keep surfacing wherever platforms can act as identity intermediaries. The practical test is no longer whether a system authenticates, but whether it can preserve identity truth across every delegated action. Teams running agentic workflows should assume that any static trust anchor will eventually be stretched beyond its original design.

Identity blast radius is the right way to think about control-plane exposure. When a platform can create accounts, reset credentials, or push changes into other systems, one forged identity context can become a multi-system incident. The governance response is to map those paths before they are weaponised, not after.

Agent-to-agent delegation should be reviewed as a privilege boundary, not a convenience layer. Once one agent can trigger another without revalidation, the organisation has effectively created transitive trust. That is where ordinary IAM controls stop being enough and runtime governance becomes mandatory.

For practitioners

• Audit runtime identity assumptions Identify every workflow where a single identity assertion can trigger multiple privileged actions without revalidation. Focus on agentic functions, integration tokens, and control-plane permissions that outlive the original authentication event.
• Break up static integration credentials Replace durable credentials where possible and limit the blast radius of any credential that must remain. Review whether the credential can still be used after the original actor, context, or session has changed.
• Require delegation revalidation Force each agent or workflow hop to recheck identity, intent, and scope before it executes a new privileged step. Do not let downstream actions inherit authority automatically from upstream context.
• Instrument privilege-creating workflows Alert on legitimate automation that creates administrators, resets credentials, or modifies trust relationships in downstream systems. Those are the actions that turn identity abuse into control-plane compromise.
• Map control-plane dependencies Document which enterprise systems trust the platform to act on their behalf, then treat those links as high-value privilege paths. Prioritise the paths that can reach identity providers, cloud access, or security controls.

Key takeaways

• This incident exposed a runtime identity problem, not just an authentication bug, because forged identity context could drive privileged workflow execution.
• The reported attack path could create administrative access and reach connected systems through a trusted control plane, even without evidence of broad public exploitation.
• Continuous revalidation of identity, intent, and delegated authority is the control that would have most directly limited the blast radius.

Key terms

• Runtime Identity Verification: Runtime identity verification is the process of proving a workload's identity at the moment access is requested rather than trusting a pre-stored secret. It ties access decisions to the current workload instance, which is more suitable for ephemeral services and short-lived sessions.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
• Trust Control Plane: A trust control plane is the operational layer that collects telemetry, applies policy, and exposes evidence about identity and cryptographic state. In this article, it is the mechanism that turns control activity into measurable proof across certificates, machine identities, and exceptions.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.