Identity security in the AI era needs shared control, not IAM alone

At a glance

What this is: The article argues that identity has expanded beyond Active Directory into cloud, NHI, and agentic AI risk, making IAM alone insufficient for security control.

Why it matters: This matters because practitioners now have to govern access, privilege, and lifecycle events across human, machine, and autonomous identities as one operating model.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Silverfort's analysis of identity security in the AI era

Context

Identity security now spans far more than human sign-in flows and directory hygiene. Once cloud services, SaaS applications, service accounts, tokens, and AI agents are all operating in the same environment, the old assumption that provisioning is the same as protection breaks down. The primary keyword here is identity security, but the real issue is governance across every identity type that can touch business systems.

The article frames a familiar problem in a new operating environment: security and IAM teams no longer can treat identity as a back-office administration task. When access exists across Active Directory, cloud directories, and autonomous systems, visibility, ownership, and privilege review become shared controls, not separate projects. That is why identity-first governance now has to include NHI management, agentic AI oversight, and human lifecycle control together.

Key questions

Q: How should security teams build identity governance across humans, machines, and AI agents?

A: Start with a single inventory that records identity type, ownership, access scope, and system relationships across human users, service accounts, tokens, and AI agents. Then align IAM, PAM, and security monitoring around the same data so entitlement review, anomaly detection, and offboarding use one governance picture instead of three disconnected ones.

Q: Why do service accounts and AI agents create more risk than traditional IAM models assume?

A: Because traditional IAM often assumes the subject of review is stable, visible, and human-paced. Service accounts and AI agents can accumulate standing access, operate across systems, and in the case of autonomous agents, change actions within a session. That makes entitlement alone a poor predictor of actual risk.

Q: What breaks when organisations treat provisioning as the same thing as security control?

A: They lose the ability to see whether an identity is still needed, still owned, or still constrained. Provisioning only creates access. Security control requires visibility, review, logging, and lifecycle enforcement so accounts do not persist with privileges that outlive the business need.

Q: Who should be accountable when identity risk spans IAM and security operations?

A: Both teams, but with different responsibilities. IAM owns identity context, ownership, and lifecycle state, while security owns abuse detection, threat correlation, and containment. When those functions stay separate, no one has a complete picture of who or what can actually move through the environment.

Technical breakdown

Why Active Directory no longer defines the identity perimeter

Active Directory still matters, but it no longer contains the identity problem. In hybrid environments, identities are replicated into cloud directories, SaaS apps introduce new trust boundaries, and machine identities often sit outside the controls that were built for human users. The result is not just more identities. It is a fragmented trust model where authentication, authorisation, and monitoring happen across disconnected systems. Static role-based access models struggle here because they were built for predictable, centrally managed trust relationships. Once identity becomes distributed, security has to reason about relationships, not just accounts.

Practical implication: build an identity inventory that covers on-prem, cloud, SaaS, and non-human accounts before attempting privilege rationalisation.

Why non-human identities create control gaps in PAM and IAM

Non-human identities are not exceptional accounts. They are the normal execution layer for workloads, integrations, and automation, which means they often outnumber human identities and accumulate standing privileges. PAM tools help only when they have complete coverage, which many environments do not. The deeper issue is that machine identities are frequently created for function, then left to persist long after their original use case changes. That leaves ownership unclear and review cycles ineffective. Least privilege is harder to enforce when the entitlement graph is large, dynamic, and only partially visible.

Practical implication: tier all privileged non-human accounts by actual authentication activity, not by where a PAM tool already has coverage.

How autonomous AI agents change the identity security model

Autonomous AI agents change the problem from static access control to runtime governance. An agent can select tools, decide when to act, and chain actions without human approval, which means the identity is not merely consuming access. It is initiating and shaping the access path. That creates a different risk pattern from service accounts or scripts, because the behaviour can shift inside a session. Traditional IAM assumes the subject of review is stable long enough to observe and certify. With autonomous execution, the behaviour itself can move faster than the governance cycle.

Practical implication: treat agent activity as a governed execution pathway, not as a normal service identity with a different label.

Threat narrative

Attacker objective: The attacker wants to convert hidden or over-provisioned identity access into broad operational reach across cloud, SaaS, and core business systems.

1. Entry begins with an old API key, over-permissioned service account, or federated identity path that already exists inside the environment.
2. Escalation occurs when the identity can move laterally across disconnected systems faster than IAM or security teams can observe or constrain it.
3. Impact follows when an autonomous or machine-driven actor reaches files, financial systems, codebases, or other crown-jewel resources and uses that access at machine speed.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity security has outgrown IAM as an administration function. The article is right to separate provisioning from protection, because the old IAM model answers who can access what while identity security now has to answer what that access can become under cloud, NHI, and agentic execution. That distinction matters because security decisions increasingly depend on visibility into actual use, not just assigned entitlement. The practitioner implication is that governance must move from account administration to identity risk control.

Standing privilege is the real attack surface, not directory membership alone. The most dangerous identities are often the ones that already work, already authenticate, and already persist across systems long after their original purpose is gone. That is why machine identities and legacy directory paths deserve the same scrutiny as privileged human accounts. The practitioner implication is that ownership, usage, and lifecycle state must be tied together before access can be considered controlled.

Runtime behaviour breaks the old assumption that access is stable long enough to review. That assumption was designed for human-paced access certification and predictable service accounts. It fails when the actor is autonomous because the identity can select actions, choose tools, and execute within a single session without waiting for approval. The implication is not merely that control coverage must improve. It is that review-based governance no longer fits the behaviour it is trying to certify.

Identity inventory is now a security control, not a housekeeping exercise. Once organisations lose sight of what identities exist and which systems they can touch, they lose the ability to segment, prioritise, and contain abuse paths. This is especially true when shadow IT, SaaS growth, and AI agents create access paths that neither IAM nor security fully owns. The practitioner implication is that cross-functional identity inventory becomes the starting point for prevention, not just detection.

Shared accountability between CIO and CISO teams is the only workable model. The article correctly points out that IAM and security cannot operate in separate lanes when identities span human, machine, and autonomous use cases. One team owns provisioning context, the other owns abuse context, and neither has a complete picture alone. The practitioner implication is that identity governance must be run as a joint operating model with common metrics and common escalation paths.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• Only 23.5% of security professionals are unsure about the biggest threat to their non-human identities, indicating a significant awareness gap.
• To go deeper: Review Ultimate Guide to NHIs for the governance model that closes the gap between inventory, privilege, and lifecycle control.

What this signals

Ephemeral trust debt: the more organisations rely on short-lived tokens, delegated access, and machine-issued credentials, the more they accumulate hidden governance debt when ownership, logging, and offboarding lag behind issuance. With 59.8% of organisations already seeing value in dynamic ephemeral credentials, the programme risk is not whether the control exists but whether its lifecycle is actually governed.

The next maturity jump is not another isolated IAM control. It is a programme that can connect access inventory, privileged activity, and identity lifecycle evidence across human and non-human estates, then surface exceptions before they become lateral movement paths. That is where shared governance starts to outperform separate IAM and security workflows.

For practitioners

• Build a complete identity inventory Map every identity type across Active Directory, cloud directories, SaaS, service accounts, API keys, certificates, and AI agents. Include ownership, system relationships, and current usage so you can see where access exists but governance does not. Use this as the baseline for privilege review and containment planning.
• Tier privileged identities by actual activity Do not rely on PAM coverage alone. Rank privileged accounts by authentication frequency, reachable systems, and business impact, then identify which identities have standing access that should be narrowed or time-bound. This creates a realistic queue for review and remediation.
• Unify IAM and security alert engineering Share intended-user context from IAM with actual-user and abuse context from security teams so SIEM and SOAR workflows can flag anomalous access faster. Focus on crown-jewel systems, latent access termination, and contractor accounts that still exist after their business purpose has ended.
• Apply identity-first monitoring to machine and agent access Add fine-grained logging, behavioural MFA, and identity-first threat detection for systems that are accessed by workloads or agents. The goal is to detect when access patterns drift beyond the expected execution path before privilege abuse becomes lateral movement.

Key takeaways

• Identity security now has to govern humans, service accounts, and AI agents as one attack surface, not three separate programmes.
• The biggest risk is not identity volume alone but standing privilege, hidden ownership, and runtime behaviour that outpaces review cycles.
• Practitioners should start with a full identity inventory, then tie privilege, logging, and lifecycle control to the systems that matter most.

Key terms

• Identity inventory: An identity inventory is the authoritative list of every human, machine, and autonomous identity in an environment, together with ownership, permissions, and system relationships. It is the starting point for governance because you cannot review, segment, or retire identities you cannot see.
• Standing privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. In hybrid environments it often becomes the default for service accounts, integrations, and admins, which increases the blast radius when identities are compromised or outlive their business purpose.
• Identity-first security: Identity-first security treats identity signals as a primary control plane for risk management, rather than only as a login function. It combines inventory, privilege, logging, lifecycle, and behavioural context so organisations can evaluate what access exists and what that access can do.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 programme maturity, it is worth exploring.

This post draws on content published by Silverfort: identity security in the AI era and the collision of Active Directory, cloud, NHI, and AI agents. Read the original.