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 aren’t 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 article discusses some of the current identity and authorization practices that present substantial security challenges for agentic AI systems. Many of the challenges aren’t new and, put simply, are the same issues that have plagued identity management systems for decades. This article is intended as a reminder that as we sprint toward agentic implementations, deploying and building on existing foundational identity standards and best practices will better prepare implementers for future challenges.

The topics covered here are drawn from public comments on the recent concept paper from the National Cybersecurity Center of Excellence (NCCoE), “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization,” 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 nonrepudiation as a core security feature, such as in financial transactions or the sharing of health information.

For organizations to have confidence in transactions, agents must 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 Multisystem Environments (WIMSE) and Identity Assertion JWT Authorization Grant build on these protocols to add new capabilities.

The ‘secure path’ will also need to be the ‘easy path,’ or credential sharing and impersonation will continue to proliferate.

Consumer-facing scenarios present a greater challenge because enterprises have little to no control over the agentic identity and might struggle to distinguish an agent from a human, especially if user credentials are shared with the agent, allowing for user impersonation. Although 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 its early phases. Broadly, there’s 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 don’t 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.

Although 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 between 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, and in widely accessible places such as configuration files, markdown files, and logs.

These problems aren’t 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—that 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 nonhuman users alike. While these standards need to evolve to provide optimal capabilities for agentic IAM systems, the ability to implement essential prerequisites—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. Although zero trust implementations are increasingly common, principles like just-in-time access and least-standing privilege aren’t widely 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 might use unexpected tools or data, leading to unintended damage, such as deleting entire datasets or code bases. 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 must consider not only tightly scoping agentic authorizations to align with business value and risk tolerance, but also ensure proper credential and token management throughout 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, focus on 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 seek 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 undermine nonrepudiation and expose 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 affects the ways in which agents can be identified, authenticated, and authorized. Although 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 the human in the loop

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. But 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 nonrepudiation for agentic actions, but relying too heavily on HITL mechanisms introduces a severe risk of consent fatigue.

Relying too heavily on HITL mechanisms introduces a severe risk of consent fatigue.

This notion is well documented by the phenomenon of multifactor authentication (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 nonrepudiation and accountability it was meant to provide.

But HITL frequency isn’t 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 useful in keeping an agent’s actions in line with expectations and focused on providing value to the user. But it can 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. Standards might not exist to govern this challenge, but the agentic ecosystem is currently forming best practices to alleviate HITL concerns. The MCP protocol specifically warns against using elicitation for sensitive information, and 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 HITL 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 throughout enterprises.

The established IAM standards and best practices of today are the foundation on which we’ll build the secure and scalable agentic protocols of the future.

These efforts to develop IAM standards and protocols will inform the NCCoE’s Software and AI Agent Identity and Authorization project. We look forward to collaborating with industry stakeholders as well as outside stakeholders on how existing and emerging identity standards and technologies can be applied in practical agentic architectures and determining where additional guidance could be needed.

Like other projects, the NCCoE plans to release a portfolio of resources, including blog articles, 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 will highlight some of the identity and authorization principles necessary for durable agentic design.

Comments on this project can be sent to [email protected].

Published Aug. 27, 2026, in the NIST Cybersecurity Insights blog.