The Perimeter Moved
For years, security spending assumed the network was the boundary. Build a strong enough wall — firewalls, VPNs, network segmentation — and the bad actors stay outside. That model made sense when applications lived in a data centre and staff logged in from an office.
It doesn't describe how businesses run now. Your data sits across a dozen SaaS products, three cloud accounts, and an assortment of internal tools. Staff, contractors, and automated services reach them from anywhere, over the public internet, using credentials and tokens. There is no wall left to defend. The thing an attacker needs is no longer a way through the firewall — it's a valid login.
That is why identity has quietly become the primary attack surface. Most serious breaches now start not with an exotic exploit but with a credential: a phished password, a leaked API key committed to a public repository, a session token lifted from a compromised laptop, an over-privileged service account nobody remembered existed. Once an attacker holds a legitimate identity, much of your traditional tooling waves them straight through — because from the system's point of view, they are you.
AI identity security is the discipline of watching that surface: every user, group, permission, API key, access token, OAuth grant, and service account — and flagging the ones that have drifted into danger, whether through abuse, neglect, or misconfiguration.
Why Identity Is the Attack Surface Now
Three shifts made credentials the soft centre of most organisations.
Everything is remote and federated. Single sign-on ties dozens of applications to one identity provider. That's convenient, and it's also a single point of catastrophic failure: compromise the identity provider, or one privileged account within it, and the blast radius is your entire estate rather than one application.
Machines outnumber humans. For every employee, a typical mid-sized company has many non-human identities — service accounts, CI/CD pipelines, integration users, bots, and increasingly autonomous AI agents that hold their own credentials. These rarely get the scrutiny a human account does. Nobody offboards a service account when a project ends. Nobody notices when its permissions quietly expand.
Standing access accumulates. Permissions are easy to grant and awkward to remove. Someone needs admin access for a one-off migration and keeps it for two years. A department is given broad access "to be safe." Over time the gap between what people can do and what they need to do grows into a wide, unmonitored liability.
The result is an estate where the genuinely dangerous accounts are hidden in plain sight among thousands of legitimate ones. Finding them by hand is not realistic. This is where automated monitoring earns its place.
Identity Threat Detection and Response (ITDR)
The industry name for this discipline is ITDR — identity threat detection and response. Strip away the acronym and it's a straightforward idea: treat identities the way a good detection engine treats network events. Establish what normal looks like for each account, then alert when behaviour or configuration drifts away from it.
An AI-driven ITDR layer continuously ingests identity data from your identity provider, cloud IAM, and SaaS applications, and builds a picture of each account: what it is, what it can do, and how it typically behaves. Against that baseline, models watch for the patterns that precede or accompany abuse. A few of the most valuable:
- Privilege escalation — an account suddenly gaining rights it never had, or a low-privilege user probing for higher access. A support account that acquires the ability to modify billing overnight is worth a hard look.
- Dormant users and unused admins — accounts that haven't logged in for 90 days but still carry live, often privileged, access. These are pure liability: full attack value, zero legitimate use.
- Shared accounts — one credential used by several people, or from several locations at once, defeating any hope of accountability and making anomaly detection nearly impossible.
- Weak or reused passwords — credentials that appear in known breach corpora, or that never rotate.
- Anomalous access patterns — a login from an unusual country, at an unusual hour, from a device never seen before, or a service account that suddenly reaches for data it has never touched.
The point of AI here is not novelty; it's scale and judgement. A rule can catch a login from a new country. It takes a model to weigh that against the account's history, role, and the twenty other signals around it, and decide whether it's the CFO travelling or an attacker with a stolen token.
The Two Risks Most Businesses Underestimate
Two categories deserve their own treatment because they're both common and badly handled: over-privileged service accounts and long-lived API keys.
We covered the human side of this in AI agent security under the heading of excessive permissions — the pattern where an integration is built against an admin key "to move fast" and never narrowed down. Identity security is where that pattern comes home to roost across the whole organisation, not just a single agent.
A service account is an identity used by software rather than a person. It logs in silently, often has no MFA, and frequently holds broad permissions because someone found scoping tedious. It never goes on holiday, never gets offboarded, and rarely appears in an access review. If its key leaks — into a log file, a repository, an error message — an attacker gets a durable, high-privilege foothold that behaves like normal automation. Nobody's phone buzzes.
Long-lived API keys are the same problem in a different shape. A key issued three years ago, still valid, still granting write access, sitting in a config file on a server that changed hands twice — that is a breach waiting for a discovery. AI identity monitoring flags these directly: keys that never rotate, keys that carry far more scope than their usage justifies, keys tied to service accounts that no active project depends on.
Here is the shape of what an identity engine surfaces, and why each finding matters:
| Finding | What it looks like | Why it's dangerous |
|---|---|---|
| Dormant admin | No login in 90+ days, retains admin rights | Full privilege, zero oversight — ideal target |
| Over-privileged service account | Broad write access, used for one narrow task | Small leak becomes large breach |
| Long-lived API key | Valid for years, never rotated | Durable foothold if exposed |
| Shared credential | One login, many users or locations | No accountability, breaks anomaly detection |
| Privilege escalation | Account gains new high-value rights | Classic attacker move mid-intrusion |
| Weak or breached password | Appears in a known breach corpus | Trivial to guess or reuse |
None of these require a clever exploit. Each is an ordinary account that has drifted into a dangerous state — which is exactly why manual review misses them and continuous monitoring catches them.
Enforcing Least Privilege at Scale
Everyone agrees with least privilege in principle: every identity should hold the minimum access it needs, and nothing more. The trouble is doing it across thousands of accounts and tens of thousands of permission assignments that change every week. As a one-off audit it's exhausting; as a permanent state it's impossible by hand.
AI helps in two directions. First, it measures the gap — comparing granted permissions against permissions actually used over a meaningful window. An account with fifty rights that has exercised six of them in six months is a right-sizing candidate the system can propose automatically, rather than a human having to notice. Second, it watches the drift — so when access quietly expands, or a temporary grant outlives its purpose, that change is surfaced instead of silently accumulating.
The goal isn't zero standing access on day one; that's rarely realistic. It's a steady, measurable reduction in unnecessary privilege, with the riskiest gaps — dormant admins, unused write access, orphaned service accounts — closed first. Least privilege becomes a maintained state rather than a heroic quarterly project that slips the moment attention moves elsewhere.
Where Identity Overlaps With Cloud and Compliance
Identity security doesn't live in isolation, and a well-built platform treats it as one input among several rather than a standalone silo.
The clearest overlap is with cloud posture. Cloud IAM — AWS roles and policies, Azure role assignments, GCP service accounts — is simultaneously a cloud misconfiguration concern and an identity concern. An over-permissive IAM role is exactly the kind of thing cloud security posture management flags, and it's also an identity risk. The strongest signal comes from correlating the two: a public-facing resource and an over-privileged role attached to it is a far sharper finding than either alone.
The second overlap is with compliance. Access reviews, least-privilege enforcement, dormant-account cleanup, and MFA coverage are not just good security — they're explicit control requirements under SOC 2, ISO 27001, and similar frameworks. Every dormant admin closed and every access review completed is evidence, and an identity engine that already holds this data can feed compliance automation directly, so the control is satisfied and the auditor's evidence is generated as a by-product rather than a separate scramble.
This is the argument for building identity security inside an AI-native security platform rather than as a bolt-on: the same finding serves detection, posture, and compliance at once, and correlation across those domains is where the genuinely dangerous cases reveal themselves.
What Good Looks Like
A well-run identity security capability has a recognisable shape:
Full inventory. Every human and non-human identity is discovered and catalogued — including the service accounts and integration users that usually escape notice. You can't monitor what you haven't found.
Behavioural baselines. Each account has a sense of normal, so anomalies are judged in context rather than against a blanket rule.
Dormancy tracking. Unused accounts, especially privileged ones, are surfaced automatically and on a schedule, not discovered during an incident.
Permission-usage analysis. Granted access is continuously compared against used access, turning least privilege into a maintained state.
Key and token lifecycle. API keys and tokens are tracked for age, scope, and rotation, with long-lived and over-scoped credentials flagged.
Correlation with cloud and compliance. Identity findings join up with posture data and feed compliance evidence rather than sitting in a separate console nobody opens.
Questions to Ask
"Do we have a complete inventory of non-human identities?" If the answer covers employees but goes vague on service accounts and API keys, that's the blind spot. Machine identities are where the neglected risk usually lives.
"How would we know if a dormant admin account were used tomorrow?" A good answer describes baselining and alerting. "We'd see it in the logs eventually" is not detection.
"How do we measure the gap between granted and used permissions?" If least privilege is only ever a manual audit, it's already out of date. It should be a continuously measured metric.
"How old is our oldest still-valid API key, and who owns it?" If nobody can answer, that's the finding.
What It Costs and How Long It Takes
Identity monitoring is one of the higher-value, lower-effort modules in a security platform, because the data sources are relatively concentrated — an identity provider, cloud IAM, and the main SaaS applications — rather than sprawling across every server and container.
A first useful version — inventory of human and machine identities, dormant-account and unused-admin detection, and basic anomalous-access alerting — is typically a matter of a few weeks of focused work once the underlying data collection is in place, not months. The deeper capabilities — full behavioural baselining, permission-usage analysis at scale, and correlation with cloud posture and compliance — build on that foundation over subsequent phases. As with the rest of the platform, the sensible path is to ship the inventory and the obvious wins (dormant admins, orphaned keys) early, because those alone materially reduce risk, then layer sophistication on top. The most expensive mistake is treating identity as an afterthought bolted on at the end, when it should be one of the first things you can see clearly.
Related guides
- Building an AI-native security operations platform
- AI cloud security posture management (CSPM)
- Building the security detection engine
- AI compliance automation: mapping evidence to frameworks
- AI agent security: what business owners need to know
- Our AI development services
We Build Identity Monitoring Into the Platform
Identity security is one of the modules we like to ship early, because it turns an invisible, sprawling risk into something you can actually see — every account, every key, every dangerous drift, in one place. We'd start by building the inventory and surfacing the obvious liabilities: the dormant admins, the orphaned service accounts, the API keys nobody has rotated since launch. From there it grows into behavioural baselining, least-privilege enforcement, and correlation with your cloud posture and compliance evidence.
If you're weighing how to bring identity risk under control — whether for your own estate or as part of a security product you're building — we're happy to walk through what that looks like for your specific setup.
Talk to us about your platform — no commitment, just a conversation.
Frequently Asked Questions
What is AI identity security?
It's the practice of continuously monitoring every identity in your organisation — users, groups, permissions, API keys, access tokens, OAuth grants, and service accounts — and using AI to flag the ones that have drifted into a dangerous state. That includes privilege escalation, dormant admin accounts, shared credentials, weak or breached passwords, over-privileged service accounts, and long-lived API keys. The AI's job is to establish what normal looks like for each account and judge anomalies in context, at a scale that manual review can't match.
What does ITDR mean?
ITDR stands for identity threat detection and response. It applies the same logic a detection engine uses for network events to identities instead: baseline each account's normal behaviour and configuration, then alert when either drifts in a way that suggests abuse or neglect. It's the identity-focused counterpart to the broader detection layer in a security platform, and in practice the two feed each other.
Why is identity considered the new perimeter?
Because the network boundary that security once defended has largely dissolved. Data lives across cloud accounts and SaaS products, accessed from anywhere over the public internet using credentials and tokens. An attacker no longer needs to breach a firewall — they need a valid login. Most serious breaches now begin with a compromised credential rather than a network exploit, which makes the collection of identities, not the network edge, the surface that actually needs defending.
What is the risk with service accounts and API keys?
Service accounts and API keys are non-human identities that run silently, often lack MFA, and frequently hold far broader permissions than their task requires because scoping them properly was skipped. They rarely appear in access reviews and are almost never offboarded. If a key leaks — into a log, a repository, or an error message — an attacker gains a durable, high-privilege foothold that looks exactly like normal automation, so nothing raises an alarm. Long-lived keys that never rotate compound the problem. This is the same excessive-permissions risk that affects AI agents, scaled across the whole organisation.
How does identity security relate to least privilege?
Least privilege means every identity holds only the access it genuinely needs. The hard part is maintaining that across thousands of accounts as permissions change weekly. AI identity security supports it by measuring the gap between granted and actually-used permissions — surfacing right-sizing candidates automatically — and by watching for drift, so temporary grants that outlive their purpose and quietly expanding access get flagged rather than silently accumulating. It turns least privilege from an exhausting periodic audit into a continuously maintained state.
How does identity data help with compliance?
Access reviews, dormant-account cleanup, least-privilege enforcement, and MFA coverage are explicit control requirements under frameworks like SOC 2 and ISO 27001. An identity engine already holds the data that proves those controls are operating, so it can feed compliance automation directly — every dormant admin closed and every access review completed becomes audit evidence generated as a by-product rather than a separate manual effort. The overlap with cloud IAM posture strengthens both: an over-permissive role is a finding for cloud posture, identity security, and compliance at once.