What Makes You… You? A Philosophical Take on Non-Human Identity – Source: securityboulevard.com

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.