ServiceNow AI breach exposes layered authorization gaps for agents

At a glance

What this is: This analysis shows how an agentic AI breach in ServiceNow exposed a layered authorization failure, where broad tool access and broad data access combined to enable persistent admin control.

Why it matters: IAM, PAM, and AI governance teams need to treat AI agents as separately authorised actors, because role scoping alone does not stop a broadly invoked agent from overreaching at runtime.

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

Context

Agentic AI changes the authorization problem because the system itself chooses which tools to call and what inputs to send. In this ServiceNow case, the issue was not prompt injection or model error alone. The security gap was that a prebuilt agent could be invoked too broadly and then operate across too much of the platform once it was active.

For identity teams, the important distinction is between user permission and agent permission. Traditional application controls assume the interface constrains action, but agentic systems need explicit tool-level and data-level boundaries. When those boundaries are missing, an AI agent can turn a legitimate invocation into a much larger administrative outcome.

Key questions

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

Q: Why do agentic systems need more than role-based access control?

A: Role-based access control is too coarse when the actor can choose actions at runtime. Agentic systems need enforcement at the tool layer and again at the data layer, because a role alone does not explain which action the agent will take or which resource it will touch next.

Q: How do security teams spot over-privileged AI agents in practice?

A: Look for agents that routinely cross system boundaries, reuse the same credential across unrelated tasks, or access more data sources than the original workflow requires. Those patterns show that the entitlement scope has drifted beyond the intended use case and is no longer defensible in review.

Q: What should teams do after a privileged agent is discovered in production?

A: Pause the agent’s broadest write paths, separate invocation rights from data rights, and require human approval for sensitive operations before restoring service. The goal is to narrow the blast radius first, then reintroduce capability only where the access model is explicit.

Technical breakdown

Why agentic systems create two authorization surfaces

Agentic AI does not just answer requests. It selects tools, builds action sequences, and then executes those steps against connected systems. That means access control has to govern both whether the agent can discover and invoke a capability and whether the underlying resource is reachable once the tool is used. In ServiceNow’s case, the Now Assist agent reportedly had broad capability to create data across the platform, which collapsed the separation between tool permission and data permission. The result was not a model flaw but an authorization design flaw: the system trusted the agent too much after invocation.

Practical implication: Define separate controls for tool invocation and downstream data access, rather than treating them as one permission decision.

Why broad tool availability becomes a platform-wide risk

A prebuilt agent that can be called in many contexts becomes a high-leverage path if tool discovery is not filtered by user context. If the agent can see powerful tools that the initiating user should not effectively wield, the tool catalog itself becomes an attack surface. This is especially dangerous when the agent can act quickly and repeatedly within a single interaction. ServiceNow’s breach illustrates that a powerful action buried inside a general-purpose agent is still a privileged action, even when the user interface makes it look ordinary.

Practical implication: Restrict agent tool exposure by role, context, and intent before the tool is even offered to the session.

How data-level authorization limits damage after tool access

Data-level controls decide whether the specific object, table, record, or workflow target is in scope after a tool has been selected. In layered authorization, the agent may know a capability exists but still be blocked when it tries to touch sensitive data or privileged write paths. That is the control that was missing in this incident. Without it, a broad write-capable agent can become a cross-platform backdoor, because every successful tool call expands the attacker’s practical reach inside the environment.

Practical implication: Enforce object and data checks at execution time so a broadly available tool cannot write anywhere by default.

Threat narrative

Attacker objective: The attacker wanted persistent administrative control over the ServiceNow environment by abusing agentic authorization gaps.

1. Entry occurred through an authentication bypass that let the attacker reach the vulnerable agentic workflow.
2. The attacker then invoked a broadly scoped Now Assist agent that could create data anywhere in ServiceNow.
3. That broad capability was used to write persistent administrative changes across the platform.
4. The impact was durable admin access inside the tenant, not a transient one-off action.

Breaches seen in the wild

• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Layered authorization is now a core requirement for agentic AI. This breach shows that agentic systems cannot be governed with a single allow or deny decision at the front door. Tool-level permission and data-level permission are different controls, and the failure of either one can turn an ordinary invocation into platform-wide privilege abuse. The practitioner conclusion is clear: agent authorization must be evaluated as a chain, not as a checkpoint.

Least privilege for agents is not a static role design problem. The more important question is whether the agent can discover, select, and execute powerful actions at runtime without additional review. That matters because the dangerous step is often not the first request, but the transition from approved invocation to overbroad execution. The implication is that access scope for agentic systems has to be enforced dynamically, not assumed from initial role assignment.

Agentic AI identity exposes a runtime scope problem that traditional IAM models understate. A human user can be restricted by UI, but an agent can be given a toolset that changes the practical meaning of authorization once execution begins. This is where agentic identity control and PAM-style guardrails meet. The practitioner takeaway is to treat every autonomous tool path as a privileged path until proven otherwise.

Authorisation architecture is becoming as important as the model itself. The ServiceNow case was not about hallucination or prompt injection. It was about an overpowered agent with the wrong enforcement boundaries, which means the system design, not just the model behavior, carried the blast radius. The practitioner conclusion is to redesign authorization around agent behavior, not retrofit human application patterns onto autonomous execution.

Just-enough-privilege is the right named concept for this class of failure. Agentic systems need just-enough-privilege because broad write capability turns a single successful invocation into a tenant-wide risk. That concept matters across OWASP-AGENTIC, OWASP-NHI, and zero trust thinking, because the problem is not access existence but access breadth at execution time. The practitioner conclusion is to make scope the first control question, not the last.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: AI Agent Authorisation Guide

What this signals

Just-enough-privilege: agentic AI turns scope control into a runtime discipline, not a provisioning exercise. If the agent can discover and execute powerful actions in the same flow, the practical control point shifts to invocation time and data access time, not role assignment alone.

The governance lesson extends beyond ServiceNow. Access reviews assume a stable permission set that can be recertified later, but agentic systems can cross from request to action within a single interaction, which means the review model has to be complemented by execution-time authorization.

According to the 2026 Infrastructure Identity Survey, 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems. That shift is not about adding another checkbox; it is about redesigning authorization for actors that choose actions dynamically.

For practitioners

• Implement tool-level authorization filtering Limit which agent tools appear and can be invoked based on the user’s role, context, and request intent, instead of exposing the full tool catalog to every session.
• Separate tool access from data access Add an execution-time check before each underlying data operation so a permitted tool cannot touch tables, records, or workflows that are outside scope.
• Require human approval for privileged agent actions Route high-risk actions through an approver workflow when the agent requests sensitive writes, administrative changes, or cross-domain data access.
• Log agent decisions and touched resources Record which tool was requested, which resources were queried or modified, and which end user initiated the action so reviewers can reconstruct the chain of authority.
• Review prebuilt agents for broad write paths Inventory any default or packaged agents that can create, modify, or route data broadly, then reduce their default scope before they are exposed to production workloads.

Key takeaways

• This breach shows that agentic AI can become a privilege amplifier when tool access and data access are not controlled separately.
• The ServiceNow case demonstrates that a broadly scoped agent can be used to create durable administrative access after initial entry.
• Layered authorization and just-enough-privilege are the controls most directly implicated by this failure mode.

Key terms

• Agentic Access: Agentic access is delegated system access granted to an AI agent or autonomous workflow so it can perform defined tasks across tools and data sources. It differs from human access because the actor can execute continuously, combine actions quickly, and amplify mistakes at scale.
• Tool-Level Permission: An authorization constraint that limits which actions an authenticated identity can invoke inside an MCP server. It is the difference between proving who a client is and limiting what that client can actually do once connected.
• 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.
• Just enough privilege: Just enough privilege is the practice of granting only the access needed for a specific workload, task, or time window. For NHIs, it works best when privileges are tied to a single function and expire automatically, reducing the chance that a leaked credential can be reused broadly.

What's in the full article

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

• The specific ServiceNow agent behaviour that enabled platform-wide writes
• How the MCP-layer control model enforces separate checks for tool use and data access
• The human-in-the-loop approval flow used for high-risk agent actions
• The audit trail requirements for reconstructing what the agent touched and why

👉 The full P0 Security article covers the agent permission model, enforcement layers, and the ServiceNow exploit chain.

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.