Back to the Future: Why Agentic AI Needs a Strong Identity Foundation
As AI matures, enterprises and customers are rapidly deploying agents seeking to unlock the next level of automation and productivity. Agentic AI shows potential to handle a multitude of use cases, from buying personal items on Amazon to customer service applications to enterprise security and software development. However, early agentic deployments are repeating a familiar pattern: prioritizing feature development and immediate value over security.
This strategy is understandable. Strategic, financial and technical leaders want to demonstrate ROI for their AI investments. Enterprises are under pressure to innovate and drive organizational efficiencies. Individuals are seeking automated and personalized experiences. Moreover, agentic AI introduces a novel frontier of security challenges that “model-only” guardrails are not yet fully equipped to solve. While building a fully mature security framework in a fast-moving landscape takes time, reverting to outdated security practices risks eroding the core value AI agents provide.
This post will discuss some of the current identity and authorization practices that present substantial security challenges for agentic AI systems. Many of the challenges discussed are not new and, put simply, are the same issues that have plagued identity management systems for decades. This post is intended as a reminder that as we sprint towards agentic implementations, deploying and building on existing foundational identity standards and best practices will better prepare implementers for future challenges.
The topics covered in this post are drawn from public comments on the recent NCCoE Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization Concept Paper, and from extensive engagement with stakeholders in the agentic AI ecosystem. The goal of this NCCoE work is to accelerate the adoption of agentic AI by demonstrating how cybersecurity standards and best practices can reduce risk and realize agentic AI value.
Credential Sharing
Security professionals have been telling users since the advent of passwords not to share their credentials. Doing so violates a core tenet of Identity and Access Management (IAM): enabling accountability by verifying both the identity and permissions of the individual or service attempting to complete a transaction. Credential sharing is a bad idea in all contexts.
And yet, individuals giving their personal and enterprise credentials to agents has quickly become a common pattern for enabling agent access to data, applications, and services. Sharing credentials – between humans or agents – creates accountability gaps that can result in any number of security, privacy, and legal issues. This is particularly true for sectors that require non-repudiation as a core security feature, such as in financial transactions or the sharing of health information.
For organizations to have confidence in transactions, agents need to be treated like first-class entities with their own unique identifiers, credentials, and associated entitlements that are bound to and by the identity of the user or system operating the agent. Both enterprises and IAM service providers are aligned in this notion, with many technology vendors building systems that support agentic identity registries, credentials, rights delegation, policy management, and governance. Many agentic AI use cases can be accommodated by leveraging existing modern authorization patterns already used for sharing, or “delegating” access to digital tools. For enterprise deployments, protocols such as Secure Production Identity Framework for Everyone (SPIFFE) and OAuth 2.0 provide mechanisms that address agentic identification and authorization challenges. While emerging standards such as Workload Identity in Multi-System Environments (WIMSE) and Identity Assertion JWT Authorization Grant build on these protocols to add new capabilities.
Consumer-facing scenarios present a greater challenge as enterprises have little to no control over the agentic identity and may struggle to distinguish an agent from a human, especially if user credentials are shared with the agent, allowing for user impersonation. While standards bodies such as Fast Identity Online (FIDO) are looking at ways to issue agent authenticators that can be bound to user identities, this work is still in early phases. Broadly, there is recognition that for consumer scenarios, the “secure path” will also need to be the “easy path” or credential sharing and impersonation will continue to proliferate.
Static and Long-lived Credentials
Equipping agents with long-lived API keys or access tokens for third-party services is often the fastest way to stand up an agentic proof-of-concept or workflow. However, bearer tokens and static API keys do not prove identity, meaning any person or service with access to the key can call the API. API keys provide broad, unscoped access to the API’s services and lack the ability to establish more granular authorization for how an agent can interact with a service. While long-lived bearer tokens can provide some scoping information, they carry no cryptographic proof possession. Any person, system, or service that gains access to the token can present it. Agents that carry API keys and bearer tokens across networks, tools, and resources expose agent owners and downstream applications to an ever-growing risk that the key or token will be leaked or obtained by an unauthorized third party. Furthermore, credentials such as API keys and tokens are often left unprotected, in-the-clear, in widely accessible places such as configuration files, markdown files, and logs.
These problems are not new. The loss and misuse of static and long-lived tokens have been the root cause of numerous, substantial security incidents over the years. But the ubiquity of AI technology and its cross-cutting application to any number of use cases has put pressure on many individuals and organizations to deploy and test agentic functionality, with little regard for identity best practices. While short-lived (ephemeral) agents are commonly deployed, not all realize that agentic credentials and authorizations need to reflect that ephemerality. Fortunately, foundational standards are already here – notably OAuth 2.0, SPIFFE, and credentials conveyed as JSON Web Tokens, X.509, and many others – provide a critical starting point on which agentic systems can build. Additionally, sender constraining protocols such as Demonstrated Proof-of-Possession (DPoP) can mitigate many token theft scenarios for human and non-human users alike. While these standards will need to evolve to provide optimal capabilities for agentic IAM systems, the ability to implement essential pre-requisites – such as dynamic, tightly scoped, audience-restricted tokens and credentials – exists today. To help enterprises secure tokens, NIST recently released the DRAFT NISTIR 8587 focusing on token management best practices.
Broadly Scoped Access
While API keys and static bearer tokens are notorious for granting overly broad access, migrating to modern authorization systems and protocols doesn’t automatically solve the problem. IAM professionals have consistently battled to implement granular authorizations, policy enforcement, and access controls to advance a principle of “least privilege.” As a result, the level of granularity that can be applied to many access control scenarios has improved over time yet broad, role-based entitlements – whether from legacy technology, entitlements creep, or poor implementation patterns – remain a challenge. While zero trust implementations are increasingly common, principles like just-in-time access and least standing privilege are not ubiquitously operational.
Agents are set to exacerbate this problem. The speed, scale, and capacity of agentic operations can far surpass that of humans. Driven by broad, high-level instructions and probabilistic reasoning, agents can unpredictably seek, probe, and execute multiple paths to achieve their goals. Given broad access, they may use unexpected tools or data, leading to unintended damage, such as deleting entire datasets or codebases. Even with strictly limited authorization, an agent’s opportunistic nature can drive it to exploit vulnerabilities or find orphaned credentials to escalate privileges.
To prepare for agentic adoption, enterprises need to consider not only tightly scoping agentic authorizations to align with business value and risk tolerance but also need to ensure proper credential and token management across the enterprise. Here too, vendors and standards are evolving to meet the challenge. Concerns over static, coarse-grained scopes contained in traditional access tokens prompted the creation of Rich Authorization Requests (RAR), which allow for dynamic, granular authorizations. Other specifications, such as Transaction Tokens, are looking at ways to promulgate authorization context across human and agentic call chains to help ensure that authorization is attenuated as it’s delegated. Open Identity Foundation’s Authorization API (AuthZen) specification enables a standardized API for communicating with external policy enforcement and decision points, opening the door to more scaled, granular authorization.
Deploying Agents with Local User Accounts
Both enterprises and individuals are looking to capture agentic value by deploying agents quickly and conveniently. One common model is deploying agents locally and giving them local user credentials and entitlements, allowing agents to aid in tasks, such as software development, building presentations, and creating spreadsheets and documents. While this deployment model is convenient, and many developers prefer to work locally, giving agents local account access allows the agent to both impersonate the user and act with broadly scoped access. Agents running commands with user authorization undermines non-repudiation and exposes the organization to potential downstream consequences when an agent performs actions without the full understanding or consent of the user. Additionally, local agentic deployments make it hard to have a centrally managed agentic identity repository and encourages other challenging IAM practices such as static credentials that are stored in local files.
Although the IAM community is still coalescing around preferred and standardized agentic deployment models, it’s clear that the infrastructure upon which an agent resides greatly impacts the ways in which agents can be identified, authenticated and authorized. While many believe that cloud deployments will offer greater security services that can take advantage of hardware roots of trust and natively segmented or containerized architectures, local agentic deployments will persist. Local agents and their reasoning models need to be deployed within a hardened and secured harness (one example here), allowing users and organizations to constrain the agent upfront and leverage controls similar to cloud deployments. Local agents might also be deployed in a sandbox, such as a tightly controlled container, where the agent can safely execute code and run terminal commands while limiting the surface the agent can interact with.
Relying on Human-in-the-Loop
While measures like binding an agent identity to a human, attenuating delegated rights, and tightly scoping authorizations all help ensure an agent acts in line with individual and organizational expectations, many still see Human-in-the-Loop (HITL) as a fundamental element of agentic control. As agents navigate complex workflows, they frequently require access to new data sources or external tools. It’s tempting to ask the human for access approval to support accountability and non-repudiation for agentic actions, but relying too heavily on HITL mechanisms introduces a severe risk of consent fatigue.
This notion is well documented by the phenomenon of MFA “bombing” (or MFA fatigue). Just as threat actors overwhelm users with authentication push notifications until the victim blindly approves a malicious login, overly chatty agents condition users to reflexively click “allow” just to keep their automated workflow moving. When users become habituated to thoughtlessly approving access requests, HITL undermines the non-repudiation and accountability it was meant to provide.
But HITL frequency is not the only concern. Through mechanisms such as elicitation, as in the Model Context Protocol (MCP), agents can request additional human input on how best to complete a given task. This mechanism is very useful in keeping an agent’s actions in line with expectations and focused on providing value to the user, but it may also be used to request user credentials or other sensitive information. In these scenarios, elicitation empowers the agent to impersonate the user and potentially promulgates unauthorized use of sensitive information. Again, this undermines core IAM tenets.
Like IAM solutions of the past, durable agentic identity and authorization design requires enterprises to consider both the usability and security considerations for HITL. While standards may not exist to govern this challenge, the agentic ecosystem is currently forming best practices to alleviate HITL concerns. The MCP protocol specifically warns against using elicitation for sensitive information, while AI model providers are working on usable solutions, such as approved “flight plans” (one example here) for agentic actions that can remove sensitive information from a prompt and help reduce consent fatigue.
Conclusion
Agentic AI generates novel IAM challenges. Solutions to those challenges will be built on a foundation of best practices that the IAM community has been honing, advocating, and implementing for years. Falling back to poor practices – such as credential sharing, relying on static tokens, granting overly broad access, and overusing Human-in-the-Loop approvals – will only resurrect vulnerabilities that the IAM community has spent decades trying to eliminate. Perhaps one of the most important actions any organization can take when preparing for the agentic future is to do a clear-eyed evaluation of its current IAM practices, systems, and capabilities against current standards and best practices. Issues, challenges, and gaps in current capabilities will only be exacerbated by agentic scale deployed across enterprises.
The established IAM standards and best practices of today are the foundation upon which we will build the secure and scalable agentic protocols of the future.
These efforts to evolve IAM standards and protocols will inform the NCCoE’s Software and AI Agent Identity and Authorization project. We look forward to collaborating with industry and other stakeholders on how existing and emerging identity standards and technologies can be applied in practical agentic architectures and determining where additional guidance may be needed.
Like other projects, the NCCoE plans to release a portfolio of resources, including blog posts, an online resource hub and NIST publications to support the adoption of IAM standards and best practices for software and AI agents. Our next blog post in this series will highlight some of the identity and authorization principles necessary for durable agentic design.
Comments on this project can be sent to AI-identity [at] nist.gov (AI-identity[at]nist[dot]gov)
About Author
