This is the third in a three-part series taking a look at the need to support use cases for non-human identities and more lately, the rise of agentic identity too. The rise of non-human identities has seen a focus on their initial discovery, but we require a more end-to-end approach to improve security and productivity.

Word Wars: What are non-human identities?

• Machine Identities, Workloads or NHI?
• Human Problems Multiplied by NHI Scale

Machine identities. Workloads. Non-human identities. Are they the same? Are they subtly different? Does it matter? The last 5 years have seen a huge shift in attention towards entities which are essentially operating without skin and bones.  Whichever definition we use (and let’s stick with non-human identities (NHI)) we need to understand what they are and more importantly how they can be secured. NHIs typically refer to digital identities assigned not to people, but to machines, systems, and software entities that interact within an organisation’s technology environment. These include service accounts, APIs, applications, containers, cloud workloads, and increasingly AI agents. 

Unlike human users, NHIs often operate autonomously and at scale, accessing systems, exchanging data, and executing processes without direct human intervention. As organisations adopt cloud-native architectures and automation, NHIs now vastly outnumber human identities and frequently hold persistent or elevated privileges. This makes them both critical to business operations and a growing source of risk, particularly when they are poorly managed, over-permissioned, or lack proper lifecycle governance. Effectively securing NHIs requires the same level of visibility, control, and continuous assurance as human identities if not more.

It is interesting to note that the definition question is likely related to a lack of understanding of how big and complex the issue really is. However we face several challenges in trying to first understand and secondly start to protect this new world. Our human-centric set of identity and access management (IAM) concepts whilst complete in theory, are rarely so in practice. We have to remain content with ghost accounts, excessive permissions and poor MFA enrolment to name just a few people-related IAM issues. The second, is how do we take these concepts and IAM design ideas we have matured from the human world and apply them to NHI? Do we need to?

We do need to, but I will revisit that point later. We first have to understand we are facing a cascading problem - with issues in two different implementation patterns. If we consider attackers are using information flows and access journeys to fulfil their data exploitation, ransomware and cyber crime activities we can start to build a better picture of what needs to be solved from a detection, observability and security controls point of view.

Lateral movement, privilege escalation and abuse will likely involve the use of multiple different accounts - from the same user, different users and a broad array of API keys, service accounts and more. So the vulnerabilities in any part of that access flow will be exploited by internal and external adversarial activity. So a human ghost account with excessive permissions can lead to a static credential that is linked to an API that accesses a backend SQL database and so on.

The result is an increased blast radius of impact, with attack life cycle entry points emerging at multiple different parts of the enterprise. From public facing login pages, to developer operations through to static credentials left in version control systems or poorly implemented and misconfigured infrastructure policies. The attack surface has increased and NHIs are a major part of that.

You can’t protect what you can’t see

• Removing Invisibility
• Discovery & Observability

A critical challenge in modern identity security is the invisibility concept of NHIs and agentic identities. These identities are often created ad hoc and do not have a central authoritative source similar to what exists in the human-centric IAM world. They are embedded in code, or provisioned by automation pipelines, and then persist long after their original purpose is forgotten. 

Because they are rarely tied to a human owner (and therefore lack lifecycle controls), they accumulate excessive privileges and become prime targets for exploitation. The first step in securing them is comprehensive discovery: building a complete, continuously updated inventory of all NHIs across cloud, on-prem, and application environments. This aspect is often overlooked. NHIs are likely to exist in a hybrid world - of on-premises but also SaaS and cloud service provider environments. So any inventory process must look to uncover their existence across all locations.

Removing this invisibility allows organisations to enforce ownership, apply least-privilege access, rotate credentials, and monitor behaviour. Without this visibility, identity security remains fundamentally incomplete because you cannot govern, secure, or reduce risk for identities you cannot see. That seems an obvious proposition but can be startling to realise many organisations do not have this as an initial phase of management.

Building a reliable inventory of NHIs requires treating identity discovery as a continuous, multi-layered data aggregation problem, not a one-off audit. In practice, this means combining signals from infrastructure, applications, identity systems, and code to construct a living identity graph.

To make this inventory meaningful, organisations need to apply correlation and enrichment:

• Map identities to owning teams or systems
• Link credentials to the workloads or services that use them
• Identify privilege levels and access paths

From an ownership perspective there are several emerging patterns that can help here. Analysis of activity within systems and network paths can help to understand what non-human identities, workloads and agentic identities are actually doing. From there, it can become easier to map target systems and resources into departments, teams and individuals. This may also require analysis of the permissions being used. What is the permission called, what description does it have and perhaps which team or person is involved in the certification process. All of these pieces of information can be used to help identify ownership - and potential NHI risk.

From a permissions and privilege perspective, the strategic goal is to deliver both the principle of least privilege (PoLP) alongside just in time access request and fulfillment. The former is associated with collapsing the permission-set to be as small as necessary to complete a specific activity or task. The latter is making sure this permission-set is only associated with an NHI at the time of need not to be permanently associated, or that is known as “standing privilege”.

Of course, none of this should be treated as a one-off or periodic event like legacy access review and identity governance projects. This has to be managed via an on-going and continuous concept, as new NHIs emerge, new systems are being accessed and new controls need to be complied with.

Baseline behaviour

• Define Good
• Identify Deviations

Before starting to tackle behaviour analysis, it is important to complete the discovery and ownership phases - namely as that helps to define a taxonomy. This taxonomy needs to cover both the types of NHIs - which is broad and growing - as well as the relationships that exist between NHIs, other NHIs, assets, actions and paths. For each asset or resource access, we need to understand key data points: the who, what, where, when and how. This telemetry should be as fine-grained as possible and not just post-event log collection. Ideally in-flight network and process related activity can provide real fine-grained information to allow for sophisticated analysis. Whilst there is likely to be a learning period, the baselining is not a one-off event. It requires a continual process in order to both identify drift in realtime, but also help adapt baseline behaviour models to legitimate change.

So if the first stage is to observe NHI, service and API activity for a set period of time to create a baseline of activity the second - and most valuable  is to use that baseline to detect deviations, drift and activity of interest. It is important to make some initial control assumptions at this point, as this helps to identify deviations from what? What is deemed to be a secure control point, standard operating model, stable risk position and so on. We can focus this analysis phase on three questions:

1. How do the permissions assigned relate to permissions being used?
2. Has behaviour deviated from the original baseline?
3. How does behavior compare to others?

The first point is rapidly becoming the key to making access assignments both risk aligned but also productivity optimized. Clearly over permissioning has been a huge challenge in the human-centric identity governance and administration space for nearly 3 decades. Access reviews do not adequately address the underlying concern of working out who should have which access. A lack of context and poor permissions descriptions are just two of the often numerous issues that result in poorly executed reviews. Access requests and initial setup processes are often not risk aligned either, with permissions being copied from “model” or “working” accounts. By understanding actual usage, permissions can initially be downsized based on the tasks being completed - and if permissions are removed erroneously perhaps as they are only used sparingly just in time request processes with rapid or even auto-approval flows can get human and non-human accounts working again seamlessly.

Any change in behaviour needs to be first identified and then in turn risk assessed. Not all changes in behaviour are malicious - and indeed may well be legitimate based on project work or changes in workflow. However they need identifying, with the appropriate contextual analysis being overlaid in order to triage and design response functions. Comparison to other accounts in similar standing (perhaps working in the same function, system, task or workflow) is useful to help downsize potential analysis.

“Good” in this sense is typically adherence to both internal and external controls and audit requirements, multiplied by deviations from the baseline behavior. The risk associated with the baseline behaviour must also be considered with comparison to both assets being accessed, blast radius of potential compromise and an understanding of exploitation likelihood.

Detect, respond & recovery

• Rogue Intent
• Containment and Response

“Detection” of high risk be it associated with identity data and permissions or actions can be complex and introduces some nuanced concepts. I have touched a little on detection engineering basics already but finding something of malicious intent can be hard as there are often no specific thresholds. Hygiene and data related detection can be more structured and repeatable. We can have a set of controls that we look for compliance against. The classic search for orphan accounts, dormant accounts and excessive permissions and again this needs to occur for all identity types from humans (staff, contractors and partners) as well as non-human identities, workloads, services and more latterly agentic AI.

When it comes to runtime behaviour, as an industry we have become quite good at applying controls during and before authentication. Risk-based authentication, adaptive-authentication and contextual authentication are all terms that often get used interchangeably. Whilst there are subtle differences, the consistent aspect being that more information is being used during the login-phase to make more fine-grained decisions. This “information” is not always identity-centric - taking into account device characteristics, location, time of day and transaction related meta-data too. 

When it comes to NHIs we are faced with two issues: how to deliver the same high assurance during the authentication phase, as well as removing the blind spots post-auth. Having not achieved this for humans, we can see the cascading of risk across humans and NHIs. An almost double blind spot.

Issues like privilege abuse and escalation, session interference and access token manipulation all typically occur post-auth and are common pivot points to both extend access and support lateral movement to other accounts and access paths.

The above are just some of the examples of attack techniques that can occur once an initial authentication event has taken place - and attacks will be switching between humans and NHIs and chaining techniques together across the two environments.

Of course once something of malicious intent has been identified what can and should be done? As the signals we can collect increase, the options for response become more fine grained too. Simple allow/deny options can be expanded due to having more high fidelity signalling, comparisons to known threat actor groups and more specificity around attribution. 

Summary

The expansion of NHI and agentic identities has amplified the risk associated with access. The issues with human-centric identity management focused on excessive permissions, weak authentication and lack of post-auth monitoring have cascading effects into the world of workloads and services. Downstream services, APIs and data sources are now being accessed by humans, non-humans and a combination of the two. To that end it is becoming essential to remove blind spots associated with NHI discovery and observability.

‍