ServiceNow AI breach exposes layered authorization gaps for agents

At a glance

What this is: This analysis shows how a ServiceNow AI agent breach turned overly broad agent permissions into persistent admin access.

Why it matters: It matters because IAM teams must govern agent tool scope, data scope, and human approval paths together across NHI, agentic AI, and lifecycle controls.

👉 Read P0 Security's analysis of the ServiceNow AI breach and layered agent authorization

Context

Agentic access is the point where an AI system is allowed to choose tools and act on them during runtime, which makes authorization more than a login problem. In the ServiceNow case, the issue was not model output quality but the reach of a prebuilt agent that could act across the platform once invoked.

That creates an identity governance problem for teams that still think in terms of static roles and one-time provisioning. When a powerful agent can be called broadly and then write to sensitive resources, the security question becomes how to constrain both the action surface and the data surface at the moment of use.

Key questions

Q: How should security teams govern AI agents that can call powerful business tools?

A: Security teams should govern AI agents by separating which tools they can see from which data and actions they can execute. The safest model evaluates each request in context, applies least privilege at the tool layer, and then rechecks policy before any sensitive write or permission change is committed.

Q: Why do AI agents complicate traditional IAM and access review processes?

A: AI agents complicate traditional IAM because they can select actions at runtime and complete them before periodic reviews ever see the access in use. That breaks assumptions built into provisioning, recertification, and standing-role models, which expect privilege to persist long enough to be observed and governed.

Q: What breaks when an agent has broad write access across business systems?

A: Broad write access turns a helpful agent into a platform-wide escalation path. If the same identity can create records, modify workflows, and touch sensitive data without separate policy checks, an attacker only needs one successful invocation to move from limited access to durable control.

Q: Who is accountable when an AI agent performs an unsafe privileged action?

A: Accountability should sit with the team that defined the agent’s permissions, the application owner that exposed the tool, and the governance function that approved the access model. For regulated environments, reviewers should be able to show why the action was allowed, who approved it, and which policy enforced the decision.

Technical breakdown

Tool-level authorization for agentic AI systems

Tool-level authorization decides which functions an agent can see and call at runtime. In this breach, the problem was not simply that an attacker found a bug, but that a powerful agent was available for invocation without sufficient context filtering. If all tools are exposed to all requesters, the agent becomes a policy bypass layer rather than a controlled interface. Runtime filtering needs to consider user role, task context, and the agent’s own allowed action set, because the model may choose a valid tool that is still inappropriate for that requester.

Practical implication: Limit which tools an agent can discover and invoke based on context, not just authentication state.

Data-level access inside MCP-backed workflows

Data-level access governs what underlying systems the agent can touch after a tool is selected. The article’s key point is that broad tool access is not enough to create harm if the underlying data path is tightly constrained, but broad write access turns the tool into a platform-wide backdoor. In MCP-style architectures, the server must enforce policy again before the underlying operation executes, because the tool description alone is not a security boundary. That second check is where sensitive tables, records, or actions should be blocked or stepped up.

Practical implication: Enforce policy at the data layer as well as the tool layer, especially for write-capable agent actions.

Human approval as a control boundary for powerful actions

Human-in-the-loop approval is not a usability feature here, it is a control boundary for high-impact actions. The article shows a model where an agent can request access, but the dangerous part is letting that request become an automatic grant for sensitive operations. Approval should interrupt the path before the action is executed, with enough context for the reviewer to understand which resource, query, or record set will be touched. Without that boundary, just-in-time access becomes just-in-time overreach.

Practical implication: Require explicit approval before sensitive agent actions execute, not after the agent has already reached the target.

Threat narrative

Attacker objective: The attacker’s objective was to convert a compromised entry point into durable administrative control over the ServiceNow platform.

1. Entry began when the attacker exploited an authentication bypass and reached the ServiceNow environment with access to invoke a prebuilt Now Assist agent.
2. Escalation followed when the attacker used the broadly scoped agent to create data anywhere in ServiceNow, turning a single granted capability into persistent admin access.
3. Impact was platform-wide privilege gain, with the agent’s write authority enabling persistent control rather than a contained, single-purpose misuse.

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

Agentic access control fails when teams treat tool invocation as the boundary. The ServiceNow case shows that a prebuilt agent can be safe in one layer and dangerous in the next if the surrounding policy model is too broad. Tool discovery, tool invocation, and underlying data access are separate controls, and collapsing them into one authorization decision leaves a structural gap. Practitioners should treat agent tool exposure as a distinct governance surface, not a proxy for overall safety.

Just-in-time access is not enough when the actor can chain actions inside one session. Traditional access governance assumes the identity holds privilege long enough to review, certify, or revoke. In this case, the agentic workflow could be used to move from invocation to persistent admin access before normal review processes could intervene. The implication is that lifecycle controls must be rethought for runtime decision paths, not just provisioned entitlements.

Layered defense is the right concept because no single control owns the whole path. The article’s strongest lesson is that authentication, agent scope, data enforcement, and human approval all need to fail closed independently. When one layer is only informational, the attacker inherits the next layer’s trust. Practitioners should design for multiple stops between request and execution, especially where autonomous tool use touches sensitive records.

Runtime authorization for agents belongs in the identity plane, not only in the application plane. The breach is a reminder that agent governance is now an identity problem as much as an application problem. Once an agent can choose actions at runtime, policy has to follow the request through the full delegation chain. Security teams should stop asking whether the model is clever and start asking where the authorization decision is actually enforced.

create-data-anywhere privilege is the specific failure mode this breach exposes. That permission was designed for administrative flexibility, but it fails when the actor can be invoked through a broad agent interface and then reuse that capability across the platform. The implication is not merely tighter permissions, but a rethink of which actions should ever be reachable through an agent at all.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same research.
• If you are moving from broad agent exposure to controlled delegation, revisit OWASP Agentic AI Top 10 for the runtime controls that should sit around tool use and delegation.

What this signals

create-anywhere privilege is becoming the new agentic blast-radius problem: when an agent can write across a platform, the control question shifts from whether it is authenticated to whether its delegated reach is bounded tightly enough to survive misuse. For governance teams, that means reviewing where agents can create, modify, or route records as a separate decision from who can invoke them.

The programme signal is clear. With 80% of organisations already reporting agent behaviour beyond intended scope, the gap is no longer theoretical. Identity teams should expect more incidents where the failure is not login compromise, but excessive runtime authority inside an otherwise legitimate delegation path.

For practitioners

• Split tool scope from data scope Inventory every agent-facing tool, then map each tool to the exact data objects and write actions it can reach. Block broad write paths by default, and require separate policy checks before the underlying operation executes.
• Add approval gates for high-impact agent actions Route sensitive actions such as record creation, permission changes, and bulk updates through explicit human approval before the action is committed. The reviewer should see the target resource, requested action, and intended business context.
• Audit for create-anywhere capabilities Find agents or service roles that can create records, objects, or workflows across multiple business domains. These capabilities should be narrowed to specific scopes because create-anywhere permissions become escalation paths when exposed through AI tooling.
• Treat agent authorization as a runtime control Review whether policy checks happen only at login or also at the moment the agent selects a tool and reaches the data layer. If enforcement is static, add controls that evaluate each request in context rather than assuming the original grant remains safe.

Key takeaways

• The ServiceNow breach shows that AI agent governance fails when tool exposure and data access are treated as the same control.
• Evidence from recent AI agent research shows that 80% of organisations have already seen agents act beyond intended scope.
• Practitioners should narrow runtime delegation, add approval gates for sensitive actions, and enforce policy again at the data layer.

Key terms

• Agentic access: Agentic access is runtime access granted to an AI system that can choose actions, call tools, and execute tasks inside a business environment. In practice, the security challenge is not only authentication. It is constraining what the agent can discover, invoke, and modify at the moment it acts.
• Tool-level authorization: Tool-level authorization controls which functions an agent can see and invoke. It sits before the data layer and is meant to prevent an agent from using powerful capabilities simply because they exist in the interface. For autonomous systems, this must be evaluated at runtime, not only at onboarding.
• Data-level access: Data-level access governs what records, tables, APIs, or objects an identity can actually touch after a tool is selected. For agentic systems, it is the second boundary that stops a broadly scoped tool from becoming a backdoor to sensitive information or unwanted write operations.
• Human approval gate: A human approval gate is a control that requires a person to review and authorise a sensitive action before it is executed. In agentic workflows, it is most valuable where the action has broad impact, changes privileges, or touches sensitive records that a runtime policy alone should not release.

What's in the full article

P0 Security's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact agent authorization flow that allowed broad invocation before policy enforcement
• The P0 enforcement pattern at the MCP layer, including request-time checks and approval routing
• Detailed examples of tool-level and data-level policy separation for sensitive agent actions
• The audit context that shows what the agent accessed, for whom, and why

👉 The full P0 Security post covers the attack path, authorization failure points, and layered defense model in more detail.

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.