Agentic access needs layered authorization after the ServiceNow breach

At a glance

What this is: This analysis argues that the ServiceNow AI breach shows agentic systems need layered authorization at both the tool and data levels, not broad agent permissions.

Why it matters: IAM and NHI teams need to treat AI agents as privileged execution actors, because overly broad scopes can convert one access flaw into persistent administrative control.

👉 Read P0 Security's analysis of the ServiceNow AI breach and agent access risk

Context

Agentic AI changes the authorization problem because the software itself can choose tools, inputs, and follow-on actions. In NHI governance terms, that means the agent is not just a workload identity but an execution path that can cross permission boundaries if controls are too broad. The ServiceNow case sits squarely in that gap: the issue was not intelligence failure, but excessive authorization.

For IAM teams, the practical question is whether access is being decided only once at login or repeatedly at the point of action. When agents can create data, call tools, and touch downstream resources, privilege must be scoped by context, approval, and auditability. That starting position is increasingly typical across early agent deployments, which is why the control gap keeps repeating.

Key questions

Q: How should security teams govern AI agents with access to sensitive systems?

A: Treat AI agents as privileged non-human identities, not ordinary application clients. Separate discovery, invocation, and data access controls so one compromise does not expose the full environment. Add just-in-time approval for sensitive actions, limit standing permissions, and log every resource touched with enough context to support audit and incident review.

Q: What is the difference between tool-level access and data-level access for AI agents?

A: Tool-level access controls whether an agent can use a capability at all. Data-level access controls what that capability can reach once it runs. Both are necessary because a broadly exposed tool can still become a privilege escalation path if the underlying resources are not separately restricted.

Q: When does just-in-time access make sense for autonomous agents?

A: Just-in-time access makes sense when an agent needs occasional high-risk privileges, such as creating records, changing configuration, or touching regulated data. It is less useful if the workflow requires constant elevated access, because then the process itself may need redesign. The goal is to reduce standing privilege, not to add friction everywhere.

Q: Why do AI agents complicate zero trust assumptions?

A: AI agents complicate zero trust because they can make runtime decisions, chain actions, and hold delegated permissions across multiple systems. That means trust has to be verified repeatedly at the point of action, not assumed from the initial authentication event. Continuous policy checks and narrow scope become essential.

Technical breakdown

Tool-level access versus data-level access in agentic systems

Agentic systems introduce two distinct authorization surfaces. Tool-level access governs whether the agent can discover or invoke a capability at all. Data-level access governs what that capability can touch once invoked. The ServiceNow scenario shows why both matter: a broadly exposed tool can become a privilege expansion path if the underlying resource scope is unrestricted. This is different from classic application access control, where the frontend usually mediates user intent before the backend acts. In agentic architectures, the model can chain actions across systems, so the decision point must move closer to execution.

Practical implication: Separate tool discovery controls from resource-level authorization checks and review both for every high-risk agent action.

Why broad agent permissions create privilege amplification

An AI agent with blanket write access is effectively a high-privilege automation layer. Once compromised or misused, the agent can do more than a standard user session because it can operate continuously, select its own tools, and reuse delegated authority across tasks. That is privilege amplification: a narrow entry point yields a much larger blast radius. In NHI terms, this resembles an over-scoped service account combined with a workflow engine that can make decisions on its own. The control failure is not the model, but the trust granted to the agent identity and its downstream permissions.

Practical implication: Minimise standing permissions on agent identities and require explicit approval before sensitive write or admin actions execute.

Just-in-time authorization for autonomous AI agents

Just-in-time access gives an agent temporary rights only when a specific task requires them. In layered agent security, that is more than a privileged access feature. It becomes the enforcement point that limits how far an autonomous action can travel before a human or policy review occurs. Request-time checks, step-up approval, and detailed audit trails all belong in the same control path. Without those layers, an agent can continue using broad permissions long after the original business intent has expired. That is why agent governance has to be dynamic rather than role-based only.

Practical implication: Use task-scoped approval workflows for sensitive agent actions and log the exact resources touched for every grant.

Threat narrative

Attacker objective: The attacker aimed to convert a single application flaw into durable administrative control over the ServiceNow environment.

1. Entry occurred through an authentication bypass that let the attacker reach the vulnerable ServiceNow path.
2. Escalation followed when the attacker invoked a prebuilt Now Assist agent with the ability to create data anywhere in ServiceNow.
3. Impact came from using that agent to obtain persistent admin access across the platform.

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

Layered authorization is now a baseline requirement for agentic AI. The ServiceNow case shows that authentication alone does not contain an autonomous actor once it can call tools and modify data. Security teams need separate controls for discovery, invocation, and downstream resource access. The practical conclusion is that agent governance must be enforced in layers, not assumed from one gateway decision.

Overly broad NHI scopes are the real failure mode behind many agent incidents. An AI agent with write access across a platform behaves like an over-privileged service identity with decision-making capability attached. That combination creates privilege amplification, where one compromise or misuse yields much larger impact than the initiating access path suggests. Practitioners should treat every agent permission as blast-radius design, not convenience.

Just-in-time approval becomes the control pattern that makes autonomous access tolerable. If an agent needs to create, modify, or expose data dynamically, those rights should be temporary and task-scoped. Static standing privileges are too permissive for systems that can act continuously and adaptively. The practical implication is clear: build approval into the access path before the agent can touch sensitive resources.

Agent governance and NHI governance are converging. The same questions now apply to service accounts, API keys, and autonomous agents: who can act, what they can touch, and how that access is reviewed. The distinction is that agents can choose actions at runtime, which makes policy enforcement and audit trails more important. Teams should stop treating AI agents as ordinary API clients and govern them as privileged non-human identities.

Identity blast radius is the right lens for this category. The issue is not only whether an agent is authenticated, but how far that identity can reach once it is trusted. Broad reach turns a single agent into a platform-wide risk multiplier. Practitioners should measure agent permissions by potential blast radius, then narrow them until the answer is defensible.

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.
• From our research: 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 AI Agents: The New Attack Surface report.
• For deeper context, review OWASP NHI Top 10 for the agentic risk patterns that make layered authorization necessary.

What this signals

Identity blast radius: teams should evaluate agent permissions by the maximum damage a single identity can cause, not by how often the agent is used. That shift matters because agentic systems can reuse delegated authority across multiple actions, which makes standing privilege a structural risk rather than an edge case. The OWASP NHI Top 10 is the right starting point for mapping those failure modes.

With 92% of organisations agreeing that governing AI agents is critical but only 44% having implemented any policies to do so, per AI Agents: The New Attack Surface report, most programmes are still behind the operational reality. The implication for readers is that policy design, approval flow design, and audit coverage need to move together, not sequentially.

For IAM and NHI teams, the next programme milestone is not broader automation but better containment. Align agent controls with NIST AI Risk Management Framework governance functions and verify that every sensitive action can be justified, approved, and reconstructed after the fact.

For practitioners

• Map tool-level and data-level authorization separately Inventory every agent capability, then document which tools it can discover and which underlying resources each tool can reach. Use this map to identify where a broadly exposed tool could become a backdoor into sensitive tables, records, or administrative functions.
• Replace standing agent privilege with task-scoped approval Require just-in-time approval for high-risk operations such as data creation, admin changes, and bulk updates. Keep grants short-lived, tied to a named request, and automatically revoked when the task completes.
• Add policy checks at request time and execution time Do not rely on a single front-door decision. Re-evaluate context when the agent invokes a tool and again when the downstream resource is accessed so a broad capability cannot bypass resource-level restrictions.
• Audit every agent action with business context Record who requested the action, which agent identity executed it, what data was touched, and why the grant was approved. Detailed audit trails make incident review and access recertification far more defensible.

Key takeaways

• AI agents should be governed as privileged non-human identities with layered controls, because authentication alone does not constrain runtime abuse.
• The scale of the problem is already visible: broad agent behaviour, incomplete audit coverage, and misplaced trust are creating a repeatable governance gap.
• Practitioners should move to task-scoped approval, separate tool and data authorization, and audit every high-risk agent action before the next incident forces the change.

Key terms

• Agentic Authorization: The set of controls that decide what an autonomous AI agent may do, what data it may reach, and when additional approval is required. It goes beyond login authentication and focuses on runtime enforcement, because agents can chain actions and reuse delegated authority across multiple systems.
• Identity Blast Radius: The maximum impact an identity can have if it is misused, compromised, or over-scoped. For agents and NHIs, blast radius is determined by the breadth of tools, systems, and data the identity can touch, which is why permission scope must be measured as part of governance.
• Just-in-Time Access: A pattern that grants privileged access only for a specific task and only for as long as needed. In NHI governance, it reduces standing privilege for service accounts and agents, but it only works when the approval path is fast, auditable, and tied to a clear business request.

What's in the full article

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

• A step-by-step explanation of how the ServiceNow exploit chain reached persistent admin access.
• The specific authorisation surfaces that need separate enforcement at the tool and data layers.
• A practical example of human-in-the-loop approval for sensitive agent requests.
• Implementation detail on audit logging for who requested, approved, and executed each action.

👉 P0 Security's full post covers the layered defense model and the authorization gap in more implementation detail.

Deepen your knowledge

Agentic access control and NHI scoping are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building layered authorization for autonomous systems, it is worth exploring.