There’s been a question running through the back of my mind for some time.
What exactly are practitioners like us trying to identify, authenticate, and authorize when it comes to non-human identity? What is the core “thing” we aim to represent and manage access for?
Before diving into the realm of non-human identity, let’s first take a quick tour through the space of human identity. However, I promise, we will come back to the non-human part.
Human Identity
User access has become a well-defined problem:
Imagine you’re attending an industry event.
You go through a familiar checklist:
• Who are you? (Identification).
• Please show your driver’s license. (Authentication).
• Let’s check if you’re on the guest list. (Authorization).
In most cases, it’s straightforward and efficient. But let me ask you a couple deeper questions: Who are you? Are we identifying (and later authenticating) your body, DNA, mind, or something else?
This might feel a bit perplexing, so let’s break it down.
Identity and Twin Paradoxes
Do identical twins share the same identity? Clearly not. While their DNA matches, they remain distinct individuals. This demonstrates that we don’t identify people based solely on DNA – a concept clear even without this example.
Consider this: If you lose a limb or receive an organ transplant, your body changes significantly. Are you still you? The obvious answer is yes. This suggests we don’t identify the body in its entirety – perhaps just certain parts that hold more significance.
What if you experience total amnesia? Does that change your identity? This is a harder question. While your personal sense of self might shift dramatically, systems that identify you – such as a bank returning your deposit – remain unaffected. Even significant changes to mind or memory don’t seem to fundamentally alter how you’re identified.
Thus it becomes clear that identity isn’t strictly tied to DNA, body, or even mind.
Pushing the Boundaries
We’ve barely touched on edge cases, but even these push us into uncharted territory.
Let’s go sci-fi for a moment. Consider the following thought experiments:
- What if you were disassembled atom by atom and reassembled somewhere else? Are you still you? (I think even some Star Trek characters feel pretty uneasy about it 😊.)
- What if an exact copy of you was created? Is the copy you or someone entirely different?
- What if you swapped minds with someone else? Who is who after the switch?
At this point, things get messy. Grappling with these questions can be uncomfortable, but they reveal a deeper truth.
For most people, the connection between mind, brain, and body remains stable throughout their lives. Our entire system of identification and authentication relies on this stability.
In practice, we depend on this consistency, bundling the mind, brain, and body into a convenient construct we call “human identity.” It’s a framework that works well in most cases – but it inevitably overlooks the messy edge cases that challenge our assumptions.
With the basics out of the way, let’s take it to the next level.
Non-Human Identity
Remember the sci-fi edge cases I mentioned earlier? Welcome to a world where those scenarios are no longer theoretical — they’re reality.
What constitutes the identity of an application? What should it represent? And what stable, unchanging elements – similar to the body-brain-mind connection – can we use to define non-human identity?
This isn’t a trivial question. The edge cases that are rare in human identity are front and center in non-human identity challenges. For instance, is a different version of your software the same entity or a new one? Is an exact replica truly identical, or does it represent something distinct? Does running the same software in a different environment – or even a different place in the same environment – make a meaningful difference?
Instead of retracing the logic we used for human identity, let’s take another approach. We could start with the smallest unit of execution – say, an executable process – and assign it an identity.
Imagine mapping the entire world of non-human identities as a hierarchical structure. For example:
I struggled to find widely adopted terminology to describe this. Let me call it the process global path for the rest of the article, referring to the hierarchical, precise definition of where it runs.
Taking it further, you might argue that even a single process could run multiple distinct jobs. In that case, we’d need to subdivide it further – adding yet another layer to the hierarchy.
At first glance, this approach seems promising. It provides a practical way to associate identity with a highly specific process global path. It’s granular and logical.
Hooray! It might feel like we’ve cracked the code on non-human identity. Let’s even assume we’ve solved the daunting problem of authenticating these identities across countless environments (an extremely difficult problem, by the way).
But here’s the catch: Identification and authentication are means, not the ultimate goal. The ultimate goal is access control.
Let’s say you could theoretically identify and authenticate every process in existence. The next question is: How do you determine whether Process Qux running on EC2 Instance Baz (mentioned earlier) is authorized to perform specific actions? This is where things get messy for non-human identity.
For human identities, granting access is often a manual process – someone decides a person is authorized and adds them to a list. Computer processes, however, are far more ephemeral. They can appear and disappear in seconds. Clearly, there’s no way to manually manage access for each process. This must be entirely automated.
But automation raises new challenges:
What defines the subject of authorization? Saying “Process Qux on EC2 Instance Baz” is inadequate – both the process and the compute instance are ephemeral and can be replaced instantly. The process global path will vary for each new instance. Does this mean that if it’s respawned, it loses access? What attributes of this non-human entity should we rely on to make authorization decisions?
Does the process-to-instance association even help? For human identities, people are the primary actors. For non-human identities, we often focus on a higher level – like a distributed application running across broad infrastructure, without considering underlying compute instances.
In these cases, the application as a whole may be the entity of interest, not the underlying processes or compute instances.
The Real Challenge: Granularity and Differentiation
The core issue isn’t just about identifying and authenticating the “lowest common denominator” (as we often do with human identity). It’s about determining the right level of granularity that aligns with how people conceptualize the application – and figuring out how to differentiate that entity from others.
Identifying and authenticating the lowest-level components might be fine for certain tasks. However, for access control, we need a way to group these low-level identities into higher-level constructs that align with what we think of as applications, workloads, or services.
This shifts the challenge from simple identification to establishing stable, useful criteria for authorization decisions. What attributes can we rely on to differentiate non-human entities meaningfully?
Non-Human Differentiation
Attribute-based access control (ABAC) offers a practical solution. Instead of relying on roles (which require long-term static identities), ABAC uses entity attributes to group ephemeral entities into more stable, long-term constructs tied to authorization policies. This approach aligns with the fluid nature of non-human entities and their operational environments.
From a practical standpoint, organizations will need to determine the level of granularity that best suits their operational and security model. There’s no one-size-fits-all solution.
For instance:
- In one context, the entity might be a job running within a CI pipeline (a ‘child’ process of a worker).
- In another, it could be a distributed application spanning multiple regions.
Despite these differences, some fundamental attributes are likely universally important when defining non-human identity for authorization:
- Provenance: Proof that the entity is the correct software (e.g., container image, executable binary).
- Configuration: Ensuring the non-human entity has the expected configuration, which influences its behavior.
- Environment: Granting access only to software running in trusted environments with assured integrity.
Zero-Trust Sidetrack
You may have noticed my reference to a “trusted environment,” which may seem contradictory to zero-trust principles.
However, a key component of zero trust is asserting the trustworthiness of a client device. Google’s BeyondCorp framework highlights this, introducing the notion of the Trust Inferrer to evaluate device trustworthiness:
“BeyondCorp doesn’t gate access to services and tools based on a user’s physical location or the originating network; instead, access policies are based on information about a device, its state, and its associated user.”
This underscores that an entity operating in a more trusted environment – such as one with physical controls and secured, monitored virtualization – is naturally more trustworthy than the same entity running on completely untrusted infrastructure. While not the sole factor in risk mitigation, it plays a significant role in shaping access decisions.
Bridging Identity and Authorization
To reiterate, non-human identities could be defined at extremely low levels for certain tasks. However, solving the authorization problem requires grouping these lower-level entities into higher-level concepts that align with how we conceptualize them. These groupings allow us to think in terms of applications, workloads, or services – providing a more intuitive and manageable framework for access control.
Finally, returning to the original question, “What are you?” – the most practical answer for non-humans seems to be a combination of provenance, configuration, and (trusted) environment.
The Workload IAM Company
Manage Access, Not Secrets
Boost Productivity, Slash DevSecOps Time
No-Code, Centralized Access Management
