ServiceNow impersonation exposure shows agentic access is brittle

At a glance

What this is: This analysis explains how a ServiceNow impersonation flaw exposed brittle assumptions in agentic access and non-human identity governance.

Why it matters: It matters because the same trust shortcuts that fail in one SaaS integration can undermine attribution, containment, and privilege control across NHI, autonomous, and human identity programmes.

By the numbers:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Only 5.7% of organisations have full visibility into their service accounts.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Aembit's analysis of the ServiceNow impersonation flaw and agentic access risk

Context

Agentic access becomes brittle when software is allowed to act with the trust assumptions built for human users. In this case, the primary security problem is not simply an application bug. It is the identity model behind the workflow, where a shared credential, weak account linking, and broad execution rights allowed impersonation to cross from authentication failure into privilege abuse.

For IAM, NHI, and identity architecture teams, the lesson is that SaaS integrations now behave like identity infrastructure, not just application features. Once a workflow can create records, provision access, or chain actions across systems, access control has to be treated as runtime governance rather than static login protection. That is where traditional trust shortcuts break first.

Key questions

Q: What breaks when agentic workflows rely on shared integration credentials?

A: Shared integration credentials collapse attribution and expand blast radius because multiple tools can present the same trust signal. In agentic workflows, that means an attacker or misbound process can act as a different user, chain actions across systems, and retain authority longer than the original request intended. The result is impersonation with weak forensic visibility.

Q: Why do agentic systems complicate identity governance more than traditional SaaS integrations?

A: Agentic systems complicate identity governance because they can initiate, sequence, and repeat actions across tools instead of waiting for a single user request. That makes static credential trust, delayed review, and account-level revocation too slow to contain misuse. Governance has to move to runtime decisioning and separate actor identities.

Q: How do security teams know if workflow identity controls are actually working?

A: They are working if a workflow cannot impersonate another identity, cannot reuse a credential outside the intended task, and leaves an audit trail that names the actor, the context, and the action. If a compromised integration can still provision access or create records after revocation, the control is not effective.

Q: Who is accountable when an integration can act as an administrator?

A: Accountability sits with the organisation that allowed shared trust to substitute for strong identity binding. Security, platform, and application teams all own different parts of the failure, but the governance standard should require distinct identities, runtime authorisation, and revocation that stops downstream actions before they complete.

Technical breakdown

Why shared integration credentials create impersonation risk

A shared platform credential turns an integration into a trust amplifier. If multiple tools can present the same credential, the backend cannot distinguish which actor initiated the request, so authentication becomes a statement about the integration rather than the caller. When email-based linking is also accepted, identity proof weakens further because possession of a linkable address is not the same as proof of user control. In agentic workflows, that matters because the software may generate actions continuously, multiplying the effect of one compromised trust relationship.

Practical implication: isolate each integration behind distinct, scoped credentials so a single trust anchor cannot impersonate multiple identities.

Runtime authorisation is different from credential-based access

Runtime authorisation means the system evaluates what the actor may do at the moment of each action, instead of assuming access because a token or shared secret was issued earlier. That distinction is critical in agentic environments, where actions can chain quickly across tools and APIs. Long-lived credentials create a large blast radius because they can be replayed, reused, or forwarded into other systems. Short-lived, task-scoped materialisation reduces reuse, but only if the policy engine remains in the decision path at execution time.

Practical implication: require policy checks at execution time and replace reusable secrets with short-lived credentials tied to a single task.

Attribution and revocation must survive chained actions

When an agent can create records, provision access, or hand off work to another system, the audit trail has to preserve actor identity, context, and action lineage. Without that, incident response cannot tell whether the initiating user, the integration, or a downstream workflow caused the change. Revocation also changes shape in these environments. Disabling one account or rotating one key may not stop the chain if other linked credentials or delegated permissions remain active elsewhere.

Practical implication: design for revocation and attribution at the workflow level, not just at the account level.

Threat narrative

Attacker objective: The attacker’s objective is to gain trusted user or administrator-level access inside workflow systems and use that identity to persist across automated actions.

1. Entry occurred through a critical impersonation flaw in ServiceNow’s Virtual Agent integration, where a trusted platform credential and email-based account linking let an unauthenticated attacker present as another user.
2. Escalation followed because the impersonated identity could include administrative privileges, allowing the attacker to act with broader authority than the original request should have permitted.
3. Impact would have been persistence through agentic workflows that can create records and provision access, making the impersonation durable across downstream actions.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 integration trust is no longer a safe control boundary: this incident shows what happens when a platform-wide credential is treated as an acceptable proxy for caller identity. That assumption was built for simpler SaaS integrations and fails when a system can act continuously across records, permissions, and downstream workflows. The implication is not just that one credential was weak, but that the trust model itself was overextended.

Runtime identity must replace static credential trust for agentic workflows: software that can create records and provision access cannot be governed as if it were a passive integration. The key failure mode here is not merely over-privilege, but authorization that was fixed ahead of execution and then reused in motion. NIST-CSF and OWASP-NHI both point toward scoped control, but the operational lesson is sharper: the decision must exist when the action happens.

Attribution breaks when agent actions are recorded under human credentials: once identity is blended across users and integrations, incident response cannot prove who actually performed the action. That creates a governance gap in both NHI and human IAM programmes because the audit trail becomes a reconstruction exercise rather than evidence. Practitioners should treat separate actor identities as a baseline requirement, not an optimisation.

Identity blast radius is the right concept for this failure mode: the dangerous part of the ServiceNow pattern is not one bad login, but how far a single trust relationship can propagate once workflow logic starts chaining actions. This is a workload identity problem, an access governance problem, and a lifecycle problem at the same time. The practitioner conclusion is that every integration needs a bounded blast radius before it is allowed to act.

Agentic access exposes the limits of human-era approval assumptions: controls that depend on slow review, delayed detection, or account-level disablement are outpaced by continuous execution. In practice, that means the governance model has to assume rapid chained action, not isolated requests. The field should stop asking whether a workflow is authenticated and start asking whether its authority can be contained once execution begins.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot even confirm where integration trust is concentrated.
• That visibility gap is why the 52 NHI Breaches Analysis remains useful for practitioners who need to trace how hidden credentials turn into lasting access paths.

What this signals

Identity blast radius: this incident is a reminder that workflow access must be designed to fail small. When a single shared trust relationship can impersonate administrators, the issue is not only authentication weakness but the inability to confine what one integration can become once it starts acting.

Enterprise programmes should watch for any place where human context is inherited by software without a separate actor identity. The more a workflow can create records, provision access, or chain actions, the more it behaves like an identity system and the less it should depend on static secrets.

The governance gap will widen as more platforms expose agent-style APIs and internal automation layers. Teams that already struggle with service account visibility will find it harder to prove who acted, revoke authority quickly, and explain the chain of custody after the fact.

For practitioners

• Separate every agent identity from the invoking user Assign distinct identities to integrations, service actors, and workflows so actions are not recorded under a human account. Bind human context explicitly to execution metadata instead of inheriting it implicitly.
• Remove shared credentials from multi-tool workflows Replace platform-wide secrets and reusable tokens with scoped credentials that are unique per integration and expire after the task. Review where account linking depends on email alone, because that does not establish control of the identity.
• Enforce runtime policy before each privileged action Require an authorisation decision at execution time for record creation, access provisioning, and administrative changes. Use policy controls that can deny or reshape the action before the workflow completes, not after the fact.
• Test revocation at the workflow level Validate how quickly you can stop a compromised agent or integration without waiting for manual rotation or account disablement. Your recovery plan should prove that downstream permissions, linked tokens, and cached trust cannot keep the workflow alive.

Key takeaways

• The core failure is not just an application flaw, but a trust model that let a shared credential and weak identity binding stand in for real caller assurance.
• This matters because workflow systems increasingly behave like identity infrastructure, and compromised non-human access can expand far faster than human review cycles can respond.
• Separate identities, runtime authorisation, and workflow-level revocation are the controls most likely to limit the blast radius of agentic impersonation.

Key terms

• Agentic Workflow: An agentic workflow is an automated process that can sequence actions across systems with limited human intervention. In security terms, it behaves like an identity-bearing actor, so it needs explicit attribution, narrow authorisation, and revocation that can stop downstream effects, not just a login session.
• Runtime Authorisation: Runtime authorisation is the practice of deciding whether an identity may act at the exact moment an action is requested. It is stronger than issuing a token once and hoping the original permission still fits, because it can account for context, task scope, and changing risk during execution.
• Identity Blast Radius: Identity blast radius is the amount of damage a single credential, account, or trust relationship can cause if misused. For non-human and agentic identities, the key question is how far access can propagate across tools, records, and delegated actions before containment succeeds.
• Workload Identity: Workload identity is the identity assigned to software that acts on behalf of a process, service, or agent. It replaces shared secrets with explicit, attributable execution context, which makes access easier to govern, revoke, and audit when systems operate continuously across multiple resources.

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 Aembit covering the ServiceNow impersonation flaw and agentic access risk. Read the original.