1. Discovery exercises regularly uncover two to three times as many privileged accounts as appear in official inventories.
For years, privileged access was relatively easy to define.
There were administrators and standard users. The administrators had elevated access, so security teams focused their efforts on the credentials and activity of those accounts.
That model worked when privileged access was held by a relatively small group of people. But organizations work differently today.
A developer can push code directly to production. An HR employee can access sensitive employee and compensation data. A service account can carry powerful permissions for years without anyone noticing. An AI agent can access systems, retrieve sensitive information, and take actions on behalf of a user.
So, are these identities privileged? Increasingly, that is the wrong question to ask.
The better question is: How privileged is this identity, and are we applying the right controls for that level of risk?
That was one of the central themes of our recent conversation on the Privilege Spectrum: Securing Human, Non-Human, Cloud and AI Identities, featuring Anupam Nandan, Senior Manager of Cybersecurity at EY, and Theo Walker, Director of Product Management for PAM at Saviynt.
The conversation points to a fundamental shift in how organizations need to think about privilege. Privilege is no longer simply something an identity has or does not have. It is contextual; it can change, and it can exist across virtually every type of identity.
And that changes how we need to secure it.
Key findings
2. Privilege exists on a spectrum (standard, elevated, privileged, highly privileged, and critical) rather than as a binary yes/no classification.
3. An identity's position on the spectrum can shift as its access, integrations, or responsibilities change, especially for AI agents.
What is The Privilege Spectrum?
The Privilege Spectrum is Saviynt’s security model that ranks identities (human, non-human, cloud, or AI) by how much access it actually has and how much damage it could cause if compromised. Instead of a binary privileged/not-privileged label, identities fall along a continuum from standard access to critical.
The problem with a yes-or-no definition of privilege
A binary privileged/not-privileged model fails because most organizations have more privileged accounts than their official inventory shows, hidden in service accounts, API keys, and AI tools that don't look like traditional admin accounts.
In the webinar, Anupam shared an observation he repeatedly sees when working with organizations: discovery exercises can uncover double or even triple the number of privileged accounts that appear in the official inventory.
Where are those identities hiding? They can be found in service accounts, SSH keys, API keys, cloud environments, business applications, development pipelines, and increasingly, AI tools and agents.
They may have been created to solve a specific problem, given additional permissions over time, or simply left behind as environments changed. And because they often look different than traditional administrator accounts, they may not receive the same scrutiny.
As Anupam put it:
Asking a yes or no question is missing most of the real risk.
That is the problem with a binary definition of privilege. It can tell you whether an identity has been classified as privileged. It does not necessarily tell you how much privilege it has, what it can do, or how much damage it could cause if compromised.
Privilege is a spectrum, not a checkbox
This is where the Privilege Spectrum comes in. Instead of asking whether an identity is privileged, the Privilege Spectrum considers privilege in context.
What does the identity have access to? What can it do? How sensitive are those systems or data? What is the potential blast radius?
Those factors help determine where an identity falls across a spectrum of privilege, from standard and elevated access through privileged, highly privileged, and critical access.
As Theo explained during the webinar:
All identities are privileged to some extent. It just depends on how much.
That is a very different way of looking at the problem. A business user with access to sensitive financial information may carry meaningful business privilege, even if they would never be considered a traditional privileged administrator. A service account with broad production permissions may carry significantly more technical privilege. An identity with access to an identity provider or PAM system may sit at the highest end of the spectrum due to the potential impact of that access.
Not all privilege is equal. And that distinction matters because different levels of privilege require different levels of control.

The Privilege Spectrum is explored in greater detail in Saviynt's Privileged Access Management in the AI Era Playbook, including how privilege is expanding across human, non-human, cloud and AI identities.
Why does privilege change over time?
An identity's privilege isn't fixed. It moves along the spectrum as its access, integrations, and responsibilities expand.
Consider an AI agent. It might start with read-only access to a repository and relatively limited potential impact. Then developers integrate the agent into a CI/CD pipeline, and its access expands. Down the line, it’s given administrative rights within a DevOps platform for a special project. This privilege escalation wasn’t wrong, but the identity's potential blast radius has increased significantly since it began. The identity did not simply go from "non-privileged" to "privileged." It moved along the spectrum as its capabilities changed.
As Anupam put it:
The spectrum only works if an identity can move along.
This is critical as AI agents become more capable and deeply embedded into business processes.
However, the principle extends well beyond AI. A developer may gain production access for a specific project. A cloud identity may suddenly gain access to a sensitive environment. A human administrator may access a system outside their normal working hours, changing the context and potentially the risk of that activity.
Privilege cannot be static because the environments, responsibilities, and access surrounding an identity are not static.
So what should security teams do differently?
Security teams should rank identities by potential impact and prioritize those most capable of causing damage, rather than trying to lock down every privileged account simultaneously.
During the webinar, Anupam described this as a critical distinction between organizations that make progress and those that get stuck trying to solve everything at once:
The organizations making progress aren't starting with ‘let's fix all privileged access,’ but they're ranking identity by actual impact and starting with the ones that could do the most damage.
That changes the conversation from "How do we secure all privileged accounts?" To, “Where is our highest-impact privilege, and are we applying the right controls there?”
This is where The Privilege Spectrum becomes more than a classification framework. It becomes a way to prioritize the security program itself.
If privilege changes, access should change too
There is another implication to consider.
If an identity can move up the privilege spectrum, should it continue to hold elevated access indefinitely? Probably not.
A static access decision can quickly become outdated in an environment where identities, applications, workloads, and AI agents are constantly changing.
Modern PAM needs to move toward more dynamic access decisions. That means continuously understanding identities and their access, assessing changes in risk.
This is where Just-in-Time access and Zero Standing Privilege become important. Rather than allowing elevated access to remain available indefinitely, organizations can provide the access required for a specific task, at the time it is needed, and remove it when the task is complete.
The goal of The Privilege Spectrum is to move beyond account control to reduce the amount of standing privilege available for exploitation in the first place.
As Theo explained:
We really wanna get to a place where access for privileged identities, and access for all identities, is really a more dynamic access decision rather than this deterministic decision based on one set policy.
That is the larger shift from traditional PAM to a more modern approach to privilege.
What does modern privileged access management require?
Privilege now spans employees, developers, service accounts, cloud workloads, applications, APIs, and AI agents. As those identities gain new access and capabilities, their level of privilege can change with them.
The organizations preparing for this shift will not necessarily be the ones with the longest list of privileged accounts, but the ones that can answer three more useful questions:
- What can this identity actually access?
- How much privilege does that create?
- Are we applying the right controls as that privilege changes?
The question is no longer simply whether an identity is privileged.
It is how privileged it is.
And increasingly, modern PAM means making access as dynamic as the identities and environments it protects.
Want to hear the full conversation?
The Privilege Spectrum is changing how security teams need to think about privilege across human, non-human, cloud, and AI identities.
Watch the webinar to hear Anupam Nandan and Theo Walker explore the real-world challenges behind the shift, including hidden privileged identities, dynamic privilege, AI agents, risk-based prioritization, and what modern PAM needs to do differently.
Watch The Privilege Spectrum webinar on demand
Frequently Asked Questions

