AI Security Begins with Workload Identity

When I hear the breathless and wide-eyed debates about the complexity, perhaps even impossibility, of securing Artificial Intelligence (AI), my thoughts go back to the 11th century and the words of wisdom from St Francis of Assisi: 

"Start by doing what's necessary; then do what's possible; and suddenly you are doing the impossible."

Not to dismiss the unique security challenges that AIs, especially agentic AI, may pose, but there is some good news amongst the uncertainty. We are not starting from scratch, and many of the tools we need to do what is necessary and possible are already available. If we start there, we could be doing the impossible in no time at all. 

‍

Do what’s necessary

AI security is deeply intertwined with identity. Without AI identity, answering the question at the heart of the debate - “How can we ensure that an AI only has access to the information it needs, at the right time, and for the right reason?” - is impossible. AI is just software with some special characteristics (more about that later), and running software results in many different workloads. The good news is, we already know how to provision identities to workloads, whether they are used for training or inference. Standards, like SPIFFE, provide flexible, platform-neutral mechanisms for attesting workloads, assigning identifiers dynamically, provisioning credentials and –critically–, keeping them up to date to prevent outages. Once AI workloads are credentialed, they can authenticate themselves to existing systems using standard credentials like X.509 certificates or JWT tokens. They can use these credentials to authenticate directly, or use them to obtain additional credentials to interact with legacy systems. We have taken the first necessary step - ensure every AI workload has an identifier and credential. 

‍

Do what’s possible

Authentication is not authorization, and this is certainly true about AI as well. The good news is that most existing systems that an AI might interact with already have authorization capabilities in place. This may be as simple as an Access Control List (ACL) or as sophisticated as the latest policy-based authorization systems. At a technical level, once the AI workload has an identity, it becomes possible to write policies to limit what the AI workloads can access, and every authorization request can be logged and used as evidence to prove compliance. This does assume that an enterprise is already in a position to exercise and operate least-privilege access in some or all of their systems using one or more access control systems. Organisations that are already investing in reduced or least-privilege access systems (dare we say Zero-Trust Architectures?) are well on their way to reduce access not just for humans and workloads, but also for AIs. Although least privilege with fine-grained authorization is hard, it is possible, provided you do what is necessary first. We can take the next step. 

‍

Do the impossible

Now, on the one hand, AI is just workloads, but they are also unlike any workloads we had before. In some ways AI workloads are like humans: You never know what they will do next. So, is controlling access for these kinds of non-deterministic systems impossible? Let’s explore some of that unpredictability. 

The first aspect of unpredictability that tends to come up in conversations about agentic AI is perhaps more of a desirable feature than a bug. What if users can give an agentic AI a task, and then let the AI figure out how to solve it? How do we allow it to find solutions on its own without granting it broad, standing, access? The answer comes back to the authorization systems. If we allow an agentic AI to discover resources and then dynamically request access, access may be temporarily granted, subject to policy, which may require human oversight, assisted by, yes, another AI to cope with the volume. This would be useful for human access as well.

A second aspect of AI’s unpredictable behaviour is that it may divulge information it should not. One solution that works for humans may work for AI. Simply limit the information available to an AI in the context of a request it is trying to fulfill from a user (or another AI). This is where human and workload identities meet - in the authorization system. The authorization decision of whether an AI should have access to a dataset when responding to a request depends on all the different entities that will have access to the response. Identity chaining, and preserving context of all the identities presented as part of a request, becomes an important input to the authorization system. 

Accommodating unpredictable behaviour is not impossible. We already do it for humans, at a much smaller scale. However, we have to evolve our systems to make discoverability and dynamic access requests part of the underlying compute fabric to ensure authorization systems can scale, while acknowledging that AIs are different from humans in key aspects regarding knowledge, ability and, perhaps most importantly, accountability. But that is for a future post.

‍

Securing AI starts with workload identity

By starting with what’s necessary (AI workload identity) and doubling down on the possible (fine-grained least-privilege authorization) we will be in a position to extend existing capabilities and do the impossible (securing AI) before we know it. 

Have you credentialed your AI workloads yet?

Pieter Kasselman, Workload Identity Enthusiast

‍

If you’re looking for practical ways to implement AI workload identity and fine-grained authorization, SPIRL can help. Learn more about how to get started. 

‍