The Identity Security Taxonomy In The AI Era
Why the Identity Taxonomy Decides Whether a Security Team Sees Anything At All
Shaun Archer
9/21/20269 min read
Get the identity taxonomy wrong, and everything built on top of it (detection, posture scoring, ownership resolution, blast radius analysis) is reasoning about the wrong thing. That is the whole case for why classification, not detection, is where identity security actually starts.
What an identity taxonomy is
"Identity" used to mean a person and a password. It doesn't any more. The average enterprise identity graph is now made up mostly of non-human identities, including service principals, OAuth grants, API keys, workload identity pools, and a fast-growing population of AI agents, and the ratio only moves one way. Gartner expects the average Fortune 500 organisation to run over 150,000 agents by 2028, up from fewer than 15 in 2025. None of those agents has a password lifecycle. Most don't have a clear owner.
An identity taxonomy is the classification schema that decides what kind of identity you're looking at, human or non-human, and within non-human, service principal versus OAuth grant versus long-lived API key versus AI agent, before anything else happens. It isn't a label for the dashboard. It's the structural decision everything downstream inherits, from whether an event even registers as unusual to whether an analyst can trace an identity back to an owner at all.
Why it matters so much
Misclassify a service principal as a human-style anomaly candidate and you get noise, because "normal" for a service principal (near-zero creation events, static permissions, no travel pattern) looks nothing like normal for a person. Run the mistake the other way, treating a compromised human account as a low-risk automated identity, and you miss the thing that actually mattered.
Non-human identities are also structurally harder to govern than human ones. They're typically MFA-exempt, rarely rotated, and routinely outlive whoever created them, which is exactly why they're a preferred path for attacker persistence once an environment is compromised. None of that is manageable if the system can't first answer what an identity is. Every later stage of the security process, detection, investigation, response, is built on the assumption that the classification underneath it was correct. When it isn't, the team isn't dealing with a detection problem. It's dealing with a foundation problem wearing a detection problem's clothes.
The chain the taxonomy sits underneath
Security teams have leaned on a simple chain for years. Visibility feeds insight. Insight feeds action. You cannot generate an insight from something you never saw, and you cannot act on an insight you never generated. Most conversations about this chain start in the middle, at insight, as though visibility is a given. It isn't.
Visibility is not the same thing as collecting logs. A raw audit line naming a service principal, an OAuth grant, or a sign-in event is telemetry, not visibility, until something has resolved what that entity is, what it can reach, and who if anyone owns it. That resolution step is the taxonomy. Skip it and a team can have enormous volumes of data and still have no real visibility, because nothing has told them which of those million events represents a machine identity behaving exactly as expected and which represents an attacker who just created a service principal to survive a password reset.
Insight only exists once visibility does. A behavioural baseline for a person, or a "this event basically never happens for this identity type" rule for a service principal, is only meaningful once the identity has been typed correctly. And action, revoking a session, rotating a credential, opening a case, is only as good as the insight that triggered it. Get the front end wrong and the team is acting on a false positive, or worse, not acting on a true one. The whole chain stands or falls on the classification step nobody talks about.
Endpoint visibility, AI agents, and why the balance has shifted
Five years ago, the endpoint was the centre of gravity for security visibility. EDR told you what was running, what a process touched, what talked to what on the device, because most attacks eventually had to execute something on a laptop or a server to do damage.
That centre of gravity has moved. As work shifted to cloud and SaaS, attackers stopped needing to touch a monitored device at all. Stolen credentials, phished OAuth consent, and hijacked sessions let an attacker operate entirely inside the identity layer, through an IdP, an email account, or a cloud console, without ever running a process an EDR agent would see. That's the structural reason identity threat detection became its own category rather than a feature of endpoint tooling. A service principal created under a legitimate, low-risk user session produces a risk score of zero on an endpoint sensor, because nothing happened on any endpoint.
AI agents pull some of that attention back towards the endpoint, but not in the old shape. A locally running agent, a coding assistant, a browser automation tool, a local MCP client, holds its credentials and does its acting from a device, so what it can reach and what it actually calls is partly an endpoint-observable fact again. The gap is specific rather than general. Simply opening a browser tab and navigating to an AI tool, for instance, doesn't touch an identity-provider sign-in log, an email system, or an OAuth grant, so none of the usual identity signals fire. Closing that requires a narrow, purpose-built signal at the point of use, not a return to full endpoint monitoring. The distinction matters. What's needed isn't "what did this process do to this file", the EDR-era question. It's "which identity is this agent acting as, and what did it call", an identity question that happens to need an endpoint vantage point to answer.
Where most vendors' taxonomies actually fall short
Look across the identity security market generally and the gaps cluster in a handful of recurring places, regardless of which specific vendor you're looking at.
Native-platform tunnel vision. A vendor built on top of being an identity provider or directory tends to have deep, well-developed classification for identities living on its own platform, and much shallower coverage for everything sitting on someone else's. The result is a taxonomy that's really only complete for organisations willing to go all in on that one vendor's identity plane.
Bolted-on identity from an adjacent category. Vendors that built their reputation in an adjacent category, endpoint, network, or SaaS posture, and are extending into identity through acquisition or integration rather than native design, tend to show it in exactly the areas a taxonomy has to get right early, breadth of SaaS coverage and depth on non-human identity.
Fragmented consoles, no single graph. Identity threat detection, posture management, and privileged access frequently ship as separate products and separate consoles even from the same vendor. That's a taxonomy that exists but doesn't connect, so getting one unified picture of an identity across all three usually means exporting everything somewhere else and reassembling it by hand.
Posture as a percentage, not a graph. A configuration score tells you how compliant a tenant is against a checklist. It doesn't tell you which of those misconfigurations an attacker would actually exploit first, because a percentage has no concept of blast radius, ownership, or reachability, the things a real taxonomy is supposed to carry.
The clock starts at authentication. A taxonomy anchored purely to sign-in and directory events has no visibility into how an identity got compromised in the first place. A socially engineered email that hands over a credential or a session token doesn't touch an auth log until the attacker uses it, by which point the taxonomy has already missed the origin of the attack.
Non-human and agent classification as an afterthought. Human identity taxonomy is mature almost everywhere. Non-human identity taxonomy is newer and thinner, and agent taxonomy, the fastest-growing category of all, is thinner still. Most vendors are extending a human-shaped model to fit machine identities rather than building a model for what machine identities actually are.
OWASP's Non-Human Identity Top 10 is a checklist for exactly this
OWASP published its first Non-Human Identity Top 10 in 2025, and it's worth reading alongside the gaps above, because nearly every entry on it is a taxonomy failure wearing a vulnerability's name. The ten risks are improper offboarding, secret leakage, vulnerable third-party NHI, insecure authentication, overprivileged NHI, insecure cloud deployment configurations, long-lived secrets, environment isolation failures, NHI reuse, and human use of NHI. Grouped by the taxonomy capability each one actually depends on, four patterns fall out.
Improper offboarding, long-lived secrets, and NHI reuse are all lifecycle problems. None of them are catchable unless the taxonomy treats ownership, credential age, and "everywhere this identity is used" as attributes that get tracked for the life of the identity, not facts recorded once at creation and never revisited. An identity record that only says what an identity is, and not who owns it now, how old its credentials are, or how many places it's been reused, will never surface any of these three.
Insecure authentication, vulnerable third-party NHI, and insecure cloud deployment configurations depend on the taxonomy drawing finer distinctions within "non-human" than most models bother with. A pipeline identity authenticating through a CI/CD system, a third-party app holding an OAuth grant, and a standing internal service account all need to be classified as different sub-types, because each has a different expected authentication path and a different normal. Collapse them into one generic machine-identity bucket and a weak or deprecated authentication method on any one of them stops looking unusual.
Overprivileged NHI and environment isolation failures are blast-radius problems. Catching them requires a taxonomy that resolves what an identity can actually reach and which environment it belongs to, not just a static privilege label. A percentage-based posture score can't tell you a service account has more access than its function requires, because that judgement depends on a reachability graph, and it can't tell you the same identity is live in both staging and production, because that depends on an environment attribute the taxonomy has to carry explicitly.
Human use of NHI, and a good share of secret leakage in practice, sit on the boundary the whole taxonomy is meant to police, the line between human and non-human behaviour. A service account being used interactively for manual tasks, or a person pasting a credential somewhere it shouldn't live, are both cases where an identity or a secret is behaving outside its declared type. Catching that needs a classification step that keeps checking behaviour against declared type on an ongoing basis, rather than trusting the label an identity was given at creation and never looking again.
Why a SIEM isn't complete visibility
It's tempting to treat the SIEM as the place all of this gets solved, on the logic that if every system just forwards its events somewhere central, visibility takes care of itself. It doesn't, for a few structural reasons that hold regardless of which tools sit upstream.
A SIEM only has what's been forwarded to it, and forwarding is a configuration and cost decision, not a completeness guarantee. Organisations routinely exclude high-volume, low-perceived-value log sources to control ingestion cost, and a source that isn't wired up simply doesn't exist from the SIEM's point of view. Even when a source is connected, the fields that make it across are often trimmed to control volume further, so what lands in the SIEM can be a reduced version of the original event.
More fundamentally, a SIEM sees events, not entities. It can ingest a line saying a service principal was modified, but it doesn't inherently know what kind of identity that is, what privilege tier it sits in, or who owns it, unless something upstream already resolved that and attached it to the event. The SIEM is a correlation surface over judgements someone else already made. It isn't where those judgements get made. When the identity taxonomy feeding it is fragmented across separate tools and consoles, the SIEM often becomes the place a team is forced to reassemble a single identity picture by hand, stitching events from several sources together after the fact. That's not evidence the SIEM provides visibility. It's evidence the taxonomy upstream didn't.
The timeline itself can have holes, too. Baseline or discovery-style events, the ones that establish what "normal" looked like when monitoring first switched on, are easy to miss entirely if a pipeline is only built to emit changes rather than starting state. A team querying a SIEM for "when did this drift start" can be missing the starting point without realising it.
None of this makes a SIEM useless. It's a genuinely valuable place to correlate identity signals against everything else in the environment. It just isn't, and was never going to be, a substitute for getting the classification right at the source. A SIEM inherits whatever the taxonomy upstream decided an identity was. If that decision was wrong, or fragmented, or simply never made for an entire category like agents, no amount of correlation downstream fixes it.
That's the throughline across all of this, and it's the same throughline OWASP's list makes concrete. Visibility, the real kind, the kind that actually produces insight and action, starts with knowing what you're looking at. The taxonomy is where that starts, and it's where most of the gaps, and most of the OWASP top 10, quietly live.