The “Who” - Understanding AI Identity in IAM

This article is the first in the series “The Challenges of Generative AI in Identity and Access Management (IAM).”

GenAI is transforming every industry, and security is no exception. It’s very common to talk about AI’s role in security from a perspective of fear - there are hundreds of articles out there concerned about AI hacking systems, faking credentials, or bypassing access controls.

Rather than focusing on that, I’d like to talk about AI in Identity and Access Management (IAM) from a more proactive perspective. The implications of AI in this field should not be understated, yet I believe there are actionable solutions to help you adapt to the challenges and opportunities presented by AI in this field.

In this series of articles, I’ll be doing that by mapping out four fundamental questions, each of which takes on new dimensions in the context of AI identity:

• Who is trying to gain access?
• What actions are they attempting to perform?
• Which resources are they trying to access?
• When Should Access Be Allowed?

By examining these questions in the context of AI, we can evolve our perception of IAM to uphold the standards of the modern, GenAI-filled world of identity and build better, more secure applications.

Beyond just theoretical discussions, this article will also highlight practical implementations of these concepts using tools like ArcJet, Lunar Dev, Permit.io, and others. By examining these questions and tools, we can reimagine IAM to uphold the standards of today’s AI-driven world.

The “Who” (Not the band)

Throughout the years, we’ve created a clear line between the treatment of human and machine identities - for human identities, we had passwords, challenges, tokens, and very short session spans. For machines, we had secrets and secret managers.

This also applied to vulnerabilities. Human identity vulnerabilities were mostly reliant on human error, such as phishing and password theft, while machine identities could suffer from misconfigurations or the improper storage of secrets.

But consider this: what happens when a single entity behaves like both?

Managing and delegating permissions was already hard enough as it is with just human users, and the reality of GenAI has created a new type of identity - one that’s neither fully human nor fully a machine. The creation of these new identities requires us to rethink the question of who (Or What) is trying to gain access into our application in all aspects of IAM - identity security, authentication, and authorization.

A New Type of Hybrid Identity

Think about an AI tool like Grammarly, which interacts directly with sensitive user data. Introduced by the end user, but it acts with no form of machine authentication or authorization, and while it isn’t a traditional machine identity, it also doesn’t function like a human user.

This means we have something completely new on our hands - an AI identity that needs protection more akin to the one we use to protect human identities.

We can also look at the other side of this coin - human identities which adopt machine-like capabilities.

Think of AI-powered tools designed to assist with specialized tasks, such as healthcare or financial analysis. These tools are often accessible to end-users who may not have technical expertise, but, using the conversational interfaces of these tools, they gain the power to perform tasks that were previously limited to bots (Or people with access to the tool’s API).

A user testing an AI tool by asking it probing questions about its underlying systems, like what operations or queries it can perform, can, in some cases, make the bot inadvertently reveal information or grant access to operations it wasn’t explicitly designed to share.

As you can see, this blurring of the boundary between human and machine identities introduces a major challenge. How do we secure systems that now house identities capable of crossing traditional lines?

How Can We Handle These New Identities?

This change undoubtedly requires us to strengthen our identity verification methods. We must incorporate multi-factor authentication, perhaps even multi-dimensional authentication, using passkeys and other modern approaches. But even that might not be enough.

As the binary classification of “human” or “machine” just isn’t enough anymore, we need a more dynamic framework that considers multiple factors.

Instead of relying on verification, like previously, I believe the proper approach to this challenge is through ranking. If before we had a single point of verification of who the user is, followed by a simple authorization decision of allow or deny, we now need to integrate authentication and authorization and consistently rank the type of request and the type of operation being allowed.

Ranking Identities

Luckily, there are many tools that allow us to rank identities based on various different factors. **Arcjet,** an open-source startup that builds application security tools for developers, has a great ranking system tool that can be used specifically for this purpose.

Arcjet allows us to create a system that provides a ranking between 0 and 100 for a bot attempting to use an application:

• *NOT_ANALYZED* - Request analysis failed; might lack sufficient data. Score: 0.
• *AUTOMATED* - Confirmed bot-originated request. Score: 1.
• *LIKELY_AUTOMATED* - Possible bot activity with varying certainty, scored 2-29.
• *LIKELY_NOT_A_BOT* - Likely human-originated request, scored 30-99.
• *VERIFIED_BOT* - Confirmed beneficial bot. Score: 100.

Zero indicates something that cannot be analyzed, one represents a very dangerous bot (a bot pretending not to be a bot), and 100 represents a safe bot, like a cURL call.

As you can see, this ranking allows us to make a smarter decision than just identifying whether something is a bot or not, and outright blocking it, as sometimes we might want to allow bot access. This is the case, for example, with bots running a cURL or some other automated script - there’s no reason for us to deny it access.

But this still isn’t enough - we need more factors to calculate this ranking. Let’s look at three types of ranking that can improve authentication and add more dimensions to this decision:

• Ownership: Does the user or entity own the data they are trying to access? For example, if a human user owns a dataset, their associated AI agent could inherit limited access to it.
• Relationships: Relationship-Based Access Control (ReBAC) provides permissions based on contextual connections. For instance, a user with direct ownership of a resource might receive full access, while an indirect relationship could warrant limited access. Ranking systems can help define and enforce these nuanced permissions.
• Conditions: Dynamic, context-driven conditions—such as time, location, or behavior—add another layer of security. For instance, even if a bot appears safe, a request originating from a suspicious IP address could trigger a restriction.

A Relationship-based system can be expanded even further in this context, enhancing existing policy checks to account for AI-specific relationships - aka a check_agent approach. For example:

Traditional Check with Permit.io:

permit.check(identity, action, resource)

AI / Delegation specific “Check-Agent”:

permit.check( {	
⁠                key: agent_identity,
				attributes: {"on_behalf": [user_identity] }
			   },
			   action,
			   resource )

This dual-layer validation ensures:

• Baseline permissions for the AI agent.
• Relationship-driven permissions tie the agent’s access to the human it represents.

Note that the “on_behalf” attribute can be used for both delegation to human and machine agents or services. The attribute can be both part of the fixed context (e.g., this is the personal agent of this human, and it always acts on their behalf; and volatile - i.e., this agent or service is acting on behalf of this human (or other service), just this once.

By integrating ownership, relationships, and conditions into IAM systems, we can go beyond traditional methods of authentication and authorization. These approaches enable us to address the complexities of AI identity, whether it involves machines behaving like humans or humans with machine-like capabilities.

Implementation

Addressing the complexities of AI identity requires not just theory but actionable steps to build systems capable of handling hybrid identities. So let’s talk implementation.

Conditions, Relationships, and Ownership can be implemented in straightforward ways or through policy languages like Rego, Cedar, or others.

Let’s consider how these principles could be applied in practice:

1. A user interacts with an application that uses the ArcJet agent for bot ranking. The agent assigns a score to the request based on predefined criteria, such as whether it’s from a bot or a human.
2. The application then integrates with
   OPAL (Open Policy Administration Layer)
   , an open-source tool we created for managing policy systems in application authorization. OPAL has two key components:
   
   • A server that stores and manages policy configurations, conditions, and permissions.
   • A client (policy engine) that connects to external resources like risk-scoring products or graph databases.
3. For example, the OPAL client might connect to:
   
   • A risk-scoring product to evaluate the likelihood of a threat.
   • A graph database to map relationships between users, entities, and resources, enabling relationship-based access control (ReBAC).

We can further streamline enforcement by incorporating tools like OPAL’s check function.

check(
 { id: "user123", botScore: 35 },
 "assign",
 "document:documentA"
);

This function integrates authentication factors directly into the ranking process every time an identity-related question arises. By doing so, enforcement becomes not only smarter but also more dynamic, capable of adapting to changes in user behavior, access conditions, and relationships.

Rethinking the Question of Who - Basic Guidelines:

1. Always challenge assumptions. Avoid static sessions and continuously re-evaluate authentication and authorization.
2. Use ranking over simple verification. This will help us better understand what is known about the user and what isn’t.
3. Accept the blurred border between humans and bots. Instead of categorically blocking or accepting bots, recognize new identities in software and secure them appropriately.
4. Combine authentication and authorization. Move beyond the traditional separation where authentication verifies identity and authorization defines permissions. Instead, they should be integrated into a unified system that ranks users and tracks their allowed actions.

This approach brings us closer to a fully integrated, proactive IAM framework that effectively addresses the complexities of AI identity. However, understanding who is only the first part of the equation. The next critical question to explore is what these identities can do once they gain access.

For that, stay tuned for our next article in the series: The “What” - Adopting Proactive Access Control.

Until then, if you have questions or want to learn more about IAM, Join our Slack community, where there are hundreds of devs building and implementing authorization.