The Identity Problem Hiding in AI Agent Deployments

___ Blog Featured Recent Video Category Start Free Trial The Identity Problem Hiding in AI Agent Deployments OAuth tokens don't tell you who's really making the request — or on whose behalf. June 24, 2026 • Atul Tulshibagwale • Next-Gen Identity Security• Securing AI As organizations rush to deploy AI agents across enterprises to handle HR cases, write and execute code, and manage customer interactions, they very often need to grant them access to sensitive systems and data. Unlike a human employee who authenticates once and acts within a well-understood role, an AI agent may act on behalf of multiple users simultaneously, be instantiated and terminated dynamically, and invoke other agents to complete subtasks — all without a human in the loop to provide real-time oversight. This creates an identity problem that the industry has not yet solved. When an AI agent accesses a resource such as a database, an API, or a file, the system receiving that request needs to know the actor and user principal behind it, and what the nature of the relationship is between the agent and the user it represents. Without this information, organizations cannot enforce fine-grained access controls, produce meaningful audit trails, or detect when an agent is acting outside its intended scope.  As AI expands across organizations, the absence of a standard way to express this identity context is an active risk that grows with every new agent deployment. In this blog post, we’ll examine the implications of the lack of standardization for information in OAuth access tokens, and steps the industry can take toward standardization. OAuth Tokens Today OAuth access tokens are used to not only identify the authenticated user, AI agent, or workload; they are also used to determine what that particular access request is or is not permitted to do. The data that an application has access to at any moment in time is dependent on the scopes or other context included in the OAuth access token. This blog post focuses on identifying the principal(s) in an access request that uses an OAuth access token.  We’re used to issuing OAuth access tokens to individual principals, whether they are humans or applications. When issuing tokens to a human, it was sufficient to encode the type of client application being used within the token. When applied to AI agents, the MCP core spec recommends using OAuth 2.1 to issue access tokens. The tokens may be issued with the user as a subject (using, say, the OAuth code flow) or to the agents themselves (using, say, the client credentials grant). The Importance of Agent Identity Agentic AI usage can be broken into four patterns from an identity point of view: Interactive: The user uses an interactive AI client that determines the actions to be taken. The user is available to provide consent if required. Offline: The user kicks off a task to an AI client, and the user is no longer available until the task completes. Automated: The AI agent(s) run autonomously; they are kicked off by automated workflows, instantiated and terminated as required, or left continuously running and assign themselves tasks based on a task queue. Transitive: One AI agent (using any of the three patterns above, and this fourth one) invokes another AI agent to complete its task. The agent’s identity becomes increasingly important as its autonomy, because an interactive use case is only slightly different from a user using their browser. However, the more the agent determines its own actions, the more its identity matters for access decisions. Why OAuth Tokens Can’t Accurately Represent Agent and User Identities When the access token is issued to the agent, there is no place in the commonly used JWT format (RFC 9068) to insert the user on whose behalf the agent might be acting. RFC 9068 defines standard claims for JWT-formatted OAuth access tokens, including subject, client, and scope, but was designed for single-principal scenarios and defines no claims for agent instance identity or the relationship between an agent and the user it is acting for. When the OAuth access token is issued to the user, the client identity (i.e., the agent identity) is encoded in the “client_id” field of the token. This “client_id” value identifies the registered client application — the type of agent — but OAuth has no standardized mechanism to identify a specific instance of that agent. What we’re lacking is a standardized way to express the agent instance identity and the user identity in an OAuth access token. Even when we specify both identities, the relationship between the user and the agent is not captured anywhere. The relationship between Claude Code and the programmer who initiated a task that caused Claude Code to get a token to access GitHub, for example, is very different from the relationship an autonomous agent has with the user whose HR case it picks up in its workflow. In the former example, the user might be delegating a specific aspect of their permissions (e.g., performing an action in GitHub) to the agent (Claude Code). In the latter example, the human’s relationship with the agent is more distant, in that if the agent has general permissions to access salary data, it should only be allowed to access the specific user’s salary when working on that user’s case. In short: OAuth access tokens have no standardized fields for agent instance identity, user identity, and the relationship between them. A note on what is meant by “instance” here. In conventional RESTful architectures, an instance refers to a specific running process — an API server may have multiple instances within the same data center or across regions. In the AI agent case, since the agent needs to maintain conversation context across multiple interactions, “instance” is better understood as a logical concept: a specific ongoing task or session, rather than a particular running process. There are other relationships between users and agents that are not necessary to capture in access tokens. For example, if an HR manager requests that a set of AI agents be provisioned and employed for handling HR cases, the relationship between that manager and the AI agent is not captured in the above example. As a part of provisioning such agents, IT may determine general permissions for the agents (i.e., roles or entitlements). Those will likely overlap with the roles of the manager that requests having such agents, but they are otherwise independent. The agent, when it runs, uses permissions that it has been granted when it was provisioned, and its relationship with the person who provisioned or sanctioned the agent does not matter during its runtime. Why This Matters Within these AI workflows, it is important to identify the instance of the application (or AI agent), the human on whose behalf it is acting, and what the delegation or other relationship is between this application and the human. This is because the same client software (e.g., Claude) could be running substantially different tasks in relation to many different users, so each instance may have a different set of permissions. The RFC 8693 standard defines token exchange, which allows one principal to obtain a token on behalf of another, but it doesn't address the richer relationship context needed for agentic workflows. A lack of standardization of this information in the OAuth access token will result in various systems expecting this data in different places, adding processing logic differently for each system, not accounting for agent identity, user identity, or their relationship in making authorization decisions, or misinterpreting the information in the token. These will result in systems making coarse-grained authorization decisions and ultimately giving too much access. In agentic call chains, this can lead to the “confused deputy problem” whereby a downstream system gets more access and such greater access is abused. What Needs to Be Done At the IIW April 2026 “un-conference,” where a small group of passionate participants discussed this topic, the general consensus was that AI use cases are going to need this, and unless we standardize it, there are going to be divergent implementations that cause incompatibility. It is imperative to get together and specify how to capture agent instance identity, user identity, and their relationship, whether through fields within an OAuth token, or an adjacent mechanism such as a separate assertion or introspection extension. It’s worth noting that the Client ID Metadata draft also has a notion of “client id” that is separate from the client ID in RFC 8693. That draft addresses client metadata at the authorization request layer, upstream of the access token, and so is out of scope here. Additional Resources Interested in learning more? Join us at Fal.Con 2026, where these conversations take center stage. CrowdStrike 2026 Global Threat Report AI threats have reached a critical turning point. Access the definitive look at the cyber threat landscape. Download Related Content Next-Gen Identity Security | Jun 15, 2026 CrowdStrike Announces Continuous Identity for AI Agents Next-Gen Identity Security | Jun 10, 2026 CrowdStrike Expands Identity Leadership with OpenID and IDPro Next-Gen Identity Security | Jun 08, 2026 CrowdStrike and Zscaler Bring Continuous Identity to Zero Trust Access Categories Agentic SOC 52 Cloud & Application Security 146 Data Security 25 Endpoint Security & XDR 359 Engineering & Tech 87 Executive Viewpoint 180 Exposure Management 121 From The Front Lines 204 Next-Gen Identity Security 74 Next-Gen SIEM & Log Management 113 Public Sector 42 Securing AI 39 Threat Hunting & Intel 219 CrowdStrike Falcon Platform Ready to protect your business? Try CrowdStrike free today Start free trial Subscribe Sign up now to receive the latest notifications and updates from CrowdStrike Subscribe See CrowdStrike Falcon in action Explore demos Copyright © 2026 CrowdStrike Privacy Request Info Blog Contact Us 1.888.512.8906 Accessibility Privacy Preference Center Privacy Preference Center Your Privacy Strictly Necessary Cookies Performance Cookies Functional Cookies Targeting Cookies Your Privacy When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences, or your device, and is mostly used to make the site work as you expect. The information does not usually identify you directly, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to learn more and change our default settings. Blocking some types of cookies may impact your experience of the site and the services we are able to offer. More information Strictly Necessary Cookies Always Active These cookies are necessary for the website to function and cannot be switched off in our systems. They may be set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies may process limited personal information, such as technical or device identifiers, where necessary to ensure the security, functionality, and integrity of the website or web portal. Such processing is strictly limited to what is required for these purposes and is not used for advertising or marketing. Cookies Details Performance Cookies Performance Cookies These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore does not identify you. If you do not allow these cookies, your visit to our website will not be included in our analytics, and our ability to monitor website performance and make improvements will be reduced. Cookies Details Functional Cookies Functional Cookies These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly. Cookies Details Targeting Cookies Targeting Cookies These cookies may be set on our site by our advertising partners. They assign a unique identifier to your browser or device and may track your activity across sites to build a profile of your interests and show you relevant adverts on other sites. If you do not allow these cookies, you will still see ads, but they may be less relevant to you. Cookies Details Cookie List Consent Leg.Interest checkbox label label checkbox label label checkbox label label Clear checkbox label label Apply Cancel Confirm My Choices Allow All