Identity security and IAM: where enterprise risk now concentrates

At a glance

What this is: This is an analysis of identity security as a distinct discipline within IAM, focused on where identity-driven risk concentrates across human, non-human, and third-party access.

Why it matters: It matters because IAM teams now need continuous visibility into entitlements, toxic combinations, and privileged actions, not just periodic access approvals.

👉 Read SafePaaS's analysis of identity security, IAM, and governance

Context

Identity security is the part of IAM that asks what an identity can do right now, not just whether it can log in. That matters because cloud services, SaaS, and hybrid work have weakened the old network perimeter, and access risk now lives in entitlements, roles, and transaction rights. For IAM and NHI governance, the practical problem is continuous drift between approved access models and what exists in production.

SafePaaS frames this as a governance issue that sits alongside IAM rather than replacing it. That framing is directionally correct: IAM handles authentication and access enablement, while identity security focuses on excessive privilege, conflicting access, and activity that creates business risk. For NHI practitioners, the same logic applies to service accounts, API keys, tokens, certificates, and AI agents because these identities often change outside human lifecycle controls.

Key questions

Q: How should security teams govern non-human identities alongside IAM?

A: Security teams should treat non-human identities as first-class governed identities with named ownership, explicit purpose, and defined revocation paths. IAM can authenticate them, but governance must control who approves them, what they can do, and when their access expires. The practical test is whether a service account or AI agent can be reviewed and removed as deliberately as an employee entitlement.

Q: Why do service accounts and AI agents create different identity risk than employees?

A: Service accounts and AI agents create different risk because they are not managed through HR lifecycle events, yet they often hold broad technical permissions and can act at machine speed. That makes ownership, monitoring, and revocation harder to sustain with human-centric controls. Risk rises when their access is persistent, poorly documented, or spread across multiple platforms.

Q: How do teams know if identity security controls are actually working?

A: Identity security controls are working when teams can show a current view of high-risk entitlements, detect privilege drift quickly, and remove access before exposure spreads. A useful sign is reduced time between entitlement change and policy review. Another is fewer unresolved conflicts between approved access and actual production permissions.

Q: What should organisations do first when identity risk is growing faster than reviews?

A: Organisations should start by narrowing coverage to a small set of critical systems, then define the highest-risk roles, identities, and entitlement combinations inside them. That creates a practical baseline for monitoring and remediation. Once the risk model is stable, expand to adjacent systems and non-human identities rather than trying to govern everything at once.

Technical breakdown

Why identity now functions as the enterprise perimeter

When users and workloads authenticate from unmanaged networks, the location of the connection becomes less useful than the power of the identity itself. Identity security therefore shifts attention to authentication assurance, entitlement scope, and the ability to detect misuse in real time. The core architectural issue is that access decisions are no longer enforced by a fixed network boundary. They are distributed across SaaS, cloud control planes, applications, and automation layers. That creates a wider trust surface, especially where privileged actions can trigger transactions or configuration changes.

Practical implication: Treat identity as the control point and design monitoring around what each identity can actually change, access, or approve.

How identity governance and identity security differ in practice

Identity governance is primarily about policy, lifecycle, and review. It defines who should have access, how that access is approved, and when it should be removed or revalidated. Identity security focuses on the risk content inside those entitlements, including excessive privilege, conflicting roles, and combinations that undermine segregation of duties. In practice, governance can tell you that access is approved while security tells you that the approved access is still dangerous. That distinction is important in environments where entitlements accumulate faster than review cycles.

Practical implication: Use governance for lifecycle control and identity security for risk scoring, exception detection, and entitlement prioritisation.

Why non-human identities expand the monitoring problem

Non-human identities behave differently from employees because they are provisioned by code, integrations, or platform workflows instead of HR-driven processes. They may span multiple systems, operate at machine speed, and trigger actions without a human in the loop. That makes them harder to observe with user-centric assumptions such as business hours, department, or physical location. The technical failure mode is not simply more accounts. It is more identities whose purpose, authority, and activity pattern are not captured well by conventional identity management models.

Practical implication: Model service accounts, tokens, and AI agents as governed identities with explicit ownership, scope, and monitoring rules.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.

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 is now a risk-reduction discipline, not a reporting layer. The article correctly separates identity security from core IAM because the operational problem is no longer just provisioning and authentication. Enterprises need continuous assessment of entitlement risk, toxic combinations, and misuse potential across systems that change faster than review processes. That means the control objective has shifted from compliance evidence to live exposure reduction. Practitioners should treat identity security as an active control plane, not a retrospective audit function.

Non-human identity governance is the named gap this article points to. Service accounts, tokens, certificates, and AI agents do not fit neatly into HR-driven lifecycle workflows, yet they increasingly carry transactional authority. That creates a governance gap where ownership is unclear, privilege accumulates, and activity is harder to interpret. For the field, the implication is straightforward: NHI governance must be explicit, not inferred from human identity processes. Practitioners should build controls around ownership, scope, and revocation, not around job changes.

Standing privilege remains the structural problem behind most identity risk. When access is granted broadly to keep work moving, manual review usually arrives after the exposure has already spread across roles and systems. The article’s emphasis on excessive access and conflicting permissions aligns with that reality. Identity security becomes useful when it exposes persistent privilege as a design flaw rather than an administrative exception. Practitioners should prioritise entitlement minimisation before they try to optimise review cadence.

Identity risk management only works when security, IT, and audit operate from the same evidence set. The article’s maturity model points in the right direction: current access visibility, prioritised risk rules, timely monitoring, and cross-functional reporting. Without shared evidence, each team sees a different version of the same entitlement state. That is a governance failure, not a tooling problem. Practitioners should align on a single risk model for both human and non-human identities before adding more review steps.

Continuous identity assessment is becoming the baseline expectation for cloud and AI-heavy environments. As applications, automations, and third-party access expand, periodic certification alone cannot keep pace with entitlement drift. The article’s roadmap structure is practical because it starts with visibility in critical systems, then expands by risk. That sequence matches how mature identity programmes reduce blast radius. Practitioners should phase coverage by business criticality and identity type rather than by organisational convenience.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows why identity security cannot rely on periodic review alone.
• For lifecycle control, the NHI Lifecycle Management Guide explains how provisioning, rotation, and offboarding should be tied to ownership and revocation.

What this signals

Identity security is becoming a programme design issue, not just a control selection issue. As environments shift toward cloud and automation, teams need one operating model for human and non-human identities, or entitlement drift will keep outrunning governance. The programme signal is clear: control coverage has to be continuous, risk-based, and anchored in business-critical systems first.

With 70% of organisations granting AI systems more access than human employees, per the 2026 Infrastructure Identity Survey, the governance gap is structural. Existing IAM processes were built for users and service accounts that changed slowly. Security teams should prepare for more autonomous identities, tighter ownership rules, and faster revocation paths across cloud and SaaS estates.

For practitioners

• Map identity security to business-critical systems first Start with the applications that can move money, expose regulated data, or change production state. Build a current inventory of entitlements, roles, and high-risk identities so you can see where excessive access sits today.
• Flag toxic access combinations and conflicting roles Define the role and entitlement combinations that break segregation of duties or create unauthorised transaction paths. Review those combinations continuously, not just during quarterly certifications.
• Create explicit governance for non-human identities Assign owners, business purpose, and revocation paths for service accounts, API keys, tokens, certificates, and AI agents. Do not let machine identities inherit governance from employee workflows that never reach them.
• Monitor entitlement changes as security events Treat role changes, privilege expansion, and new integrations as events that deserve detection and response. Feed those changes into security operations so the programme can react before access drift becomes persistent exposure.
• Phase coverage by risk, not by convenience Begin with the identities and systems that create the largest blast radius, then expand to adjacent platforms and third-party access. This keeps the programme measurable while avoiding broad but shallow coverage.

Key takeaways

• Identity security is the part of IAM that measures what an identity can do right now, which makes it central to cloud-era risk management.
• Non-human identities, broad entitlements, and stale access create the largest governance gaps because they change faster than manual review cycles.
• Practitioners should start with high-risk systems, define ownership for every machine identity, and monitor privilege drift as a security event.

Key terms

• Identity Security: Identity security is the discipline focused on the risk carried by an identity's active entitlements, not just whether authentication succeeds. It looks for excessive privilege, conflicting access, and high-impact actions that can be abused in production systems.
• Non-Human Identity: A non-human identity is any machine- or software-based identity that authenticates to systems and can perform actions on behalf of a process, service, or agent. This includes service accounts, API keys, tokens, certificates, and AI agents that need ownership and lifecycle control.
• Toxic Access Combination: A toxic access combination is a set of permissions or roles that becomes dangerous when held together, often because it bypasses segregation of duties or creates an unauthorised transaction path. The risk is cumulative, so individually acceptable rights can still produce an exposure when combined.
• Entitlement Drift: Entitlement drift is the gap that forms when real production access changes faster than policy, review, or documentation. It appears when access accumulates, roles expand, or integrations are added without a matching governance update, leaving the approved model out of sync with actual privilege.

Deepen your knowledge

Identity security and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a control model for service accounts, API keys, and AI agents, it is worth exploring.

This post draws on content published by SafePaaS: identity security, IAM, and governance across cloud and business applications. Read the original.