Identity-first threat detection now spans human, NHI and AI identities

At a glance

What this is: This is a Permiso Security article about an award win and the case for identity-first threat detection across human, non-human, and AI identities.

Why it matters: It matters because IAM, PAM, and security teams need detection that tracks how identity behaves across cloud and SaaS boundaries, not just how endpoints or networks look in isolation.

Context

Identity-first threat detection treats identity as the primary signal for spotting abuse across cloud and SaaS environments. In this article, Permiso Security argues that attacks now move across human users, service accounts, and AI agents too quickly for endpoint-first or network-first monitoring to keep up.

The governance gap is cross-identity visibility. If a security programme can only observe one identity type at a time, an attacker can pivot from a stolen human credential to a service account and then into an AI execution path without losing coverage from their point of view.

Key questions

Q: How should security teams govern access across human, NHI, and AI identities?

A: Security teams should govern all three through a shared lifecycle and policy layer, but with different operating rules for each actor type. Humans need review and approval flows, NHIs need ownership, rotation, and offboarding discipline, and AI agents need continuous control over actions, permissions, and escalation paths. The key is to keep governance consistent without forcing one workflow onto every identity class.

Q: Why do endpoint and network tools miss identity-based attacks so often?

A: Because those tools frequently see the traffic or process after the attacker has already authenticated with legitimate access. Identity-based abuse often looks normal at the endpoint level, especially when the actor is using stolen credentials, a service account, or a session token. The failure is not alert volume. It is the absence of identity context at the point of decision.

Q: What breaks when human, service account and AI agent activity are monitored separately?

A: The attack chain breaks only on paper, not in the environment. Separate monitoring creates blind spots during pivots, because each identity type appears harmless in isolation even when the same attacker controls them in sequence. That is how persistence survives and why one compromised identity can lead to another without triggering a coherent investigation.

Q: Should organisations treat AI SOC agents like governed identities?

A: Yes, because the practical risk is delegated access, not just model output. If an AI agent can read evidence, prepare actions, or trigger connected tools, it needs scoped permissions, defined task boundaries, and revocation when the workflow ends. That is the identity control model SOC teams already use for other non-human actors.

Technical breakdown

How identity graphs unify human, NHI and AI telemetry

A Universal Identity Graph links each identity to its permissions, relationships, and runtime behaviour, so detections can evaluate context rather than isolated events. In practice, that means a human account, service account, OAuth token, IAM role, or AI agent is not treated as a separate alerting silo. The detection model can correlate what the identity is, what it can reach, and whether current actions deviate from its baseline. This matters because modern intrusion paths often look normal within one surface and suspicious only when the full identity chain is visible.

Practical implication: build detection around a unified identity model so pivots between identity types remain visible.

Why identity-first detection beats endpoint-first correlation

Endpoint and network tools often see attacks after the adversary has already authenticated and begun using legitimate access. Identity-first detection moves the decision point earlier by watching who is acting, what privileges are in play, and whether the behaviour fits the identity’s normal operational pattern. This is especially relevant for credential theft, service-account abuse, and session hijacking, where the malicious activity can blend into ordinary cloud traffic. The value is not more telemetry but better semantic context around access and action.

Practical implication: correlate runtime behaviour to identity state before relying on endpoint or network indicators as the main signal.

Why AI agents enlarge the detection surface

AI agents add a third identity category because they can act through permissions, tools, and execution roles that are distinct from both humans and traditional machine identities. That does not mean every tool-using system is autonomous, but it does mean detection must account for AI identities as governed actors with their own access paths. When agents interact with cloud workloads, SaaS data, or CI/CD systems, the security question becomes whether their actions are expected for that identity and context. Without that layer, agent activity can look like ordinary automation until it becomes harmful.

Practical implication: inventory AI agents as governed identities and alert on unexpected access or tool use.

Threat narrative

Attacker objective: The attacker’s objective is to control identity paths well enough to persist, move laterally, and reach data or operational systems without losing access.

1. Initial access begins with stolen credentials, compromised service accounts, or hijacked identity sessions rather than malware or network exploitation.
2. The attacker then uses the legitimate identity to move through cloud, SaaS, CI/CD, or on-premises systems while blending into approved access patterns.
3. Persistence and lateral movement follow when the adversary pivots from one identity type to another, preserving access even as individual accounts are detected.
4. Impact occurs when the attacker controls enough identity context to access data, extend privileges, or continue operations across otherwise separate environments.

NHI Mgmt Group analysis

Identity-first detection is becoming the right abstraction layer for modern breach visibility. The article reflects a reality we have seen repeatedly: attackers do not stay inside one telemetry domain long enough for endpoint-only or network-only detection to remain reliable. A unified identity view is now the only practical way to preserve context as access moves across cloud, SaaS, CI/CD, and on-premises environments. Practitioners should treat identity as the correlation key, not a supplementary attribute.

Cross-identity pivoting is the operational gap that legacy detection stacks miss. A breach that starts with a human credential and then shifts into a service account or AI execution role can look benign if each identity is monitored in isolation. That is not a tuning problem. It is a model problem, because the attack path itself depends on identity transitions that most stacks do not represent as a single chain. Security teams should re-evaluate whether their detection architecture can preserve identity continuity across the full access journey.

AI agents expand the identity perimeter without changing the governing logic of access. Agentic behaviour matters here only insofar as it creates a new governed actor that can hold and exercise permissions. The article points to a broader shift: identity control is no longer only about humans and service accounts, but about every runtime actor that can authenticate, act, and pivot. The practical conclusion is that identity security programmes must extend their detection model before AI-driven access paths become normalised.

Universal Identity Graph is the named concept that captures the new detection requirement. The point is not graphing for its own sake. It is that a single representation of identities, permissions, and runtime behaviour makes cross-surface threat detection possible when the attacker’s route is itself identity-based. That is where identity security, cloud detection, and AI governance now meet. Practitioners should judge detection platforms by whether they preserve that continuity.

What this signals

Cross-identity continuity is now the detection requirement that matters most. Security teams should assume attackers will move from one identity type to another as soon as a single account or session becomes noisy. That means detection programmes need to preserve identity lineage across cloud, SaaS, CI/CD, and on-premises controls instead of treating each surface as a separate investigative island.

Identity-first monitoring changes how practitioners should think about coverage gaps. The issue is no longer whether a tool can see an event, but whether it can still explain the event after an attacker changes identity context. Programmes that cannot connect human, NHI, and AI activity in one view will keep finding the breach at the pivot point rather than at the first misuse of access.

For practitioners

• Map detection around a unified identity model Correlate human users, service accounts, API keys, OAuth tokens, IAM roles, and AI agents in one detection view so pivots do not break the investigation chain.
• Track identity behaviour at runtime Use baseline behaviour for each identity to flag when access patterns, tool use, or privilege reach drift beyond what the identity normally does.
• Separate identity-type coverage gaps Test whether your current stack can see a compromise move from a human account into a service account and then into an AI agent without losing context.
• Inventory AI agents as governed actors Assign ownership, access scope, and monitoring thresholds to AI identities so their actions are evaluated as part of the identity programme, not left inside generic automation logs.

Key takeaways

• Identity-first threat detection treats identity as the primary signal, because attackers now pivot through human, non-human, and AI access paths instead of staying on one surface.
• The article argues that endpoint and network stacks miss important stages of identity-based abuse when a compromise shifts from one identity type to another.
• Practitioners should judge detection platforms by whether they preserve identity continuity across cloud, SaaS, CI/CD, and on-premises environments.

Key terms

• Identity-first fraud prevention: Identity-first fraud prevention is the practice of detecting and stopping abuse by using identity evidence before a transaction completes. It links onboarding, login, device signals, and behavioural analytics so controls respond to suspicious identity patterns rather than only to financial or payment anomalies.
• Universal identity graph: A unified representation of identities, their relationships, and their permissions across environments. In practice, it lets security teams connect humans, machine identities, and AI agents to the actions they perform and the resources they can reach.
• Identity Pivot Path: A route an attacker can follow from one compromised system into broader identity, cloud, or administrative access. These paths matter because they reveal whether a single intrusion can become domain-wide control or remain contained.
• Runtime Behaviour Baseline: The expected pattern of activity for an identity while it is operating in production. It goes beyond entitlement lists by comparing actual actions, timing, and access paths, which is critical when valid credentials can still be abused.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.