TL;DR: NIST’s new NCCoE post names five identity and authorization problems that become sharper for agentic AI, from credential sharing and long-lived tokens to broad entitlements, local user accounts and human approval fatigue, according to Aizome research. The real issue is that current IAM assumptions break when agents act through delegated access at runtime, not just through human workflows.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Aizome's blog post: NIST’s five AI agent identity problems point to an access architecture gap, not a prompt-layer issue.
Why it matters: IAM, PAM and governance teams need a model for agent identity, delegated access and runtime authorization before AI agents inherit human credentials and broad entitlements.
Context
Agentic AI changes identity governance because the subject is no longer a user operating a tool, but a software actor taking actions through delegated access. That shift breaks assumptions in IAM programmes that were built around stable human identities, human review cycles and fixed entitlements.
NIST’s concern is not about model quality alone. It is about how AI agents obtain credentials, how much access they inherit, how they are monitored while acting, and whether any accountable identity still exists when decisions are made at runtime.
The governance question is simple: if an AI agent can use tools, access systems and trigger work without a person present for every step, then the access model must be designed around the agent itself, not the human who created it. That is the control boundary most programmes have not yet made explicit.
Key questions
Q: What should teams do when AI agents read and act on the same credentials humans use?
A: Separate machine identity lifecycle from human identity workflows. Credentials used by agents, CI/CD jobs, and automation should have narrow scope, clear ownership, and response paths that do not depend on manual ticket queues or human business hours.
Q: Why do long-lived user tokens create governance risk for AI agents?
A: Long-lived tokens assume access remains valid until a person revokes it, but agent behaviour changes the risk model because the actor can decide and act at runtime. That makes persistent delegation harder to justify, especially when the task is narrow and short-lived. Session-bound authorization reduces the exposure window and fits the way agents actually execute work.
Q: How does purpose-based authorisation work for AI agents?
A: Purpose-based authorisation gives an AI agent access only to the data, tools and actions needed for a declared purpose, such as drafting a report or reconciling records. The purpose is bound to the agent’s runtime session, task scope and policy rules, with approvals, logging and revocation tied to the accountable human or service owner.
Q: How should security teams govern local AI agents that run on developer endpoints?
A: Treat them as NHIs with identity, access, and lifecycle ownership. Inventory each agent, define which user context it inherits, limit its reachable systems, and require approval for commands that modify code, secrets, or network state. If the agent can execute in the same context as the developer, it needs the same level of governance as other privileged machine identities.
Technical breakdown
Why credential sharing breaks accountability for AI agents
When a human gives an AI agent personal or enterprise credentials, the transaction is no longer attributable to a single governed subject. The agent is acting inside the human's trust boundary, but without the human's context, intent or review loop. That creates an identity collapse: the same credential can represent both the operator and the software entity. In practical terms, IAM can authenticate that a request was made, but it cannot tell whether the right actor was authorised to make it. This is why agent identity has to be distinct from human identity, even when the agent is deployed by the same person. See the Agentic AI Identity Guide.
Practical implication: Separate agent identity from human identity and treat delegated access as its own governance domain.
Static API keys and long-lived tokens create hidden agent blast radius
Static credentials are a poor fit for agentic workflows because the credential can outlive the task, the session and sometimes the operator. A long-lived token does not prove possession context or intent, and if an agent stores or forwards it, the blast radius expands quickly across downstream tools. The mechanism is simple: once the secret is exposed, any process that can reuse it can act as the agent. This is not just a secrets issue. It is a lifecycle issue because the same credential is often reused across multiple actions, vendors and environments. See the AI Agent Authorisation Guide.
Practical implication: Move sensitive agent access to short-lived, task-scoped credentials with clear issuance and revocation boundaries.
Broad role entitlements hide intent drift at runtime
Role-based access becomes brittle when an AI agent can choose among multiple tool paths to complete a goal. A role may be technically valid but still too broad for the specific purpose the agent is meant to serve. That gap between what the system can do and what the agent was intended to do is where unexpected actions emerge. In agentic systems, authorisation is not just a provisioning decision. It is a runtime control problem because the agent can combine permissions in ways the original role design did not anticipate. That makes policy intent as important as entitlement scope. See the Agentic AI Security Guide.
Practical implication: Define agent access around declared purpose and enforce policy at the moment of each tool call.
Threat narrative
Attacker objective: The objective is to obtain durable, reusable access that lets an AI-driven workflow act across systems without reliable accountability or scope control.
- Entry begins when a human shares personal or enterprise credentials with an AI agent, allowing the software actor to operate inside an existing trust boundary.
- Escalation follows when static API keys or long-lived tokens are reused across tools, expanding the usable scope beyond the original task.
- Impact occurs when broadly scoped entitlements and weak human review let the agent take actions that are difficult to attribute, contain or reverse.
Breaches seen in the wild
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Identity for agents is becoming a governance primitive, not a feature add-on. The central mistake in many AI programmes is treating the agent as an interface layer while the human remains the only governed subject. That model fails as soon as the agent can authenticate, select tools and act independently at runtime. In practice, this means identity architecture has to move closer to the action path, where authorisation and accountability are enforced together.
Credential sharing is an accountability failure first and a secrets failure second. Once a human lends credentials to an agent, the programme loses the ability to answer a basic question: who actually executed the transaction? That is why this pattern undermines agent identity governance even when the technical access works as intended. The right unit of governance is the agent itself, because accountability collapses the moment identity and operator stop being the same thing.
Long-lived access is the wrong default for machine decision-making. Static tokens assume a predictable user session, but agentic behaviour is event-driven and variable. When access persists beyond the task boundary, the control assumption is already broken. The implication is not merely to rotate faster, but to stop treating persistent credentials as a suitable operating model for software actors that can trigger work on their own.
Broad roles now function as latent autonomy multipliers. The more access an agent can combine, the more its actual behaviour diverges from the narrow purpose it was created for. That creates a governance gap that traditional access reviews will not catch in time. Organisations need to understand that intent is not the same as entitlement, and that distinction becomes operationally material once tool use is dynamic.
Intent-based access: The most useful concept in this discussion is that the permission model should reflect declared purpose, not just technical possibility. NIST’s framing makes clear that the problem is not only who can act, but whether the action still matches the reason the agent exists. Practitioners should treat intent mismatch as a first-class identity risk.
From our research library:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Authorisation Guide
What this signals
Governance programmes built on periodic access review assume privilege stays visible long enough to be certified. Agentic systems can acquire, use and discard access within a task, so review cadence alone cannot establish control over runtime behaviour.
Intent mismatch: The more an agent can act across tools, the more its actual behaviour can drift away from the purpose that originally justified access. That makes runtime policy enforcement the control boundary that matters, not post-hoc review of a completed session.
NHI Mgmt Group's reading is that organisations should expect identity governance to shift from static provisioning to action-level authorisation as AI agents move deeper into production workflows.
For practitioners
- Map every AI agent to a distinct identity Inventory agents separately from human users, assign each one an accountable identity, and stop using shared human credentials for software actions.
- Replace persistent credentials with short-lived access Use task-scoped tokens and bounded issuance windows so agent access expires with the work it was authorised to perform.
- Enforce purpose-based authorisation at runtime Check each agent tool call against declared intent before execution so access scope cannot expand silently during a session.
- Monitor local agent deployments as governed identities Fold workstation-based AI tools into the same inventory, policy and monitoring model as cloud-deployed agents so local usage does not bypass oversight.
- Challenge human-in-the-loop approval fatigue Limit manual approval to exceptions that require judgment, rather than forcing people to rubber-stamp every agent action.
Key takeaways
- AI agents create identity governance problems when they inherit human access instead of carrying their own accountable identity.
- Static credentials and broad roles widen the blast radius of agentic workflows because they outlive the specific task that justified them.
- Runtime purpose checks matter more than periodic review when a software actor can decide, call tools and act inside one session.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · Agentic AI Security Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The post centres on agents inheriting or abusing delegated identity and privilege at runtime. |
| Recommendation — Audit agent workflows for privilege inheritance and block actions that exceed declared purpose. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Agent credential sharing and local credential use are central risks in the source analysis. |
| NHI-07 — Long-Lived Secrets | The analysis highlights static API keys and long-lived tokens as a root cause of agent risk. | |
| Recommendation — Give each agent its own authenticated identity and eliminate shared human credentials. Replace persistent agent secrets with short-lived credentials and task-scoped issuance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and rotation are directly implicated by the static-token problem. |
| Recommendation — Manage agent authenticators so issuance, rotation and revocation are tied to task scope. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Broad entitlements and runtime scope drift are core governance issues in the post. |
| Recommendation — Constrain agent entitlements to declared purpose and verify access at the point of use. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Credential reuse and overbroad access create the attack path described in the analysis. |
| Recommendation — Map exposed agent credentials to credential-access and lateral-movement hunting priorities. | ||
Key terms
- Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
- Purpose-based Authorisation: A policy model that checks why an action is being taken, not just who is taking it. In identity programmes, this matters when delegated systems or AI agents can act quickly and broadly, because consent and intent must be tied to a specific transaction rather than assumed from account ownership.
- Credential Sharing: Credential sharing is the practice of giving the same login details, API key, token, or certificate to multiple people, systems, or agents. In IAM and NHI governance, it breaks individual accountability, weakens least privilege, increases blast radius, and makes revocation, audit, and anomaly detection harder across cloud and application environments.
- Intent Drift: A mismatch between the original purpose of an agent session and the outcome produced by a later chain of actions. It matters because each step can be individually permitted while the overall behaviour still becomes unsafe or non-compliant.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org