Because they blur the line between a user, an application, and an acting system. An LLM may sit inside a workflow, inherit credentials, and execute actions that look operational rather than interactive. That means IAM has to account for delegation paths, while PAM must consider ephemeral, task-scoped privilege instead of only human admin sessions.
Why This Matters for Security Teams
LLMs change IAM and PAM because they do not behave like static users or ordinary service accounts. They can receive prompts, call tools, retrieve data, and trigger actions in ways that create delegation chains security teams did not design for. That shifts the control question from “who logged in?” to “what authority was granted, for how long, and through which path?”
That matters because traditional access reviews are often built around named people, fixed roles, and visible session boundaries. LLM workflows can obscure those boundaries by embedding access inside orchestration, retrieval, or agent handoffs. Current guidance from the NIST Cybersecurity Framework 2.0 still applies, but it has to be interpreted through a model of dynamic, task-scoped authorization rather than simple user entitlement. The identity problem is no longer only authentication, but also how the system proves authority at each step of execution.
In practice, many security teams encounter this only after an LLM workflow has already inherited broad access and performed an action that no human explicitly approved.
How It Works in Practice
Operationally, the challenge starts when an LLM is placed inside a business process and given access to APIs, data stores, or administrative tools. The model itself may not “hold” a password in the traditional sense, but the surrounding application often does, and the LLM can instruct or invoke that application to use those credentials. That creates a control gap between identity issuance, session management, and action authorization.
Good practice is to separate the model from standing privilege. Instead of granting broad access to the workflow, teams should design task-specific service identities, strict tool allowlists, short-lived tokens, and explicit approval gates for high-risk actions. Logging must also capture prompt inputs, tool calls, and downstream changes so the organisation can reconstruct the full delegation path. This is where NIST AI Risk Management Framework and NIST AI 600-1 Generative AI Profile are useful, because they push teams toward governance, traceability, and human accountability around AI-enabled decisions.
- Use separate identities for the model runtime, orchestration layer, and human operator.
- Apply just-in-time authorization for sensitive actions, not persistent admin rights.
- Bind each tool call to a logged business purpose and approval context.
- Inspect prompts and outputs for injection paths that could redirect privilege.
- Correlate AI activity with SIEM and PAM telemetry so misuse is detectable.
Where LLMs can read from one system and write to another, the safest pattern is to treat every write as a privileged action, even if it originated from a conversational request. This guidance tends to break down in highly automated environments with legacy shared accounts and weak API segmentation because the model can inherit more authority than the control plane can reliably observe.
Common Variations and Edge Cases
Tighter privilege controls often increase orchestration overhead, requiring organisations to balance speed and usability against blast-radius reduction. That tradeoff becomes sharper in environments where LLMs are embedded in customer support, DevOps, or security operations, because those workflows need fast action but also strict containment.
Best practice is evolving on whether an LLM should ever be treated as an identity in its own right. There is no universal standard for this yet, but current guidance suggests treating the model as an execution component that operates under a governed system identity, with human accountability preserved for high-impact decisions. The OWASP Top 10 for Agentic Applications 2026 and MITRE ATLAS adversarial AI threat matrix both reinforce the need to consider prompt injection, tool abuse, and adversarial manipulation as real access risks, not only model-quality issues.
Edge cases matter. Shared browser sessions, long-lived API keys, and autonomous agents that chain multiple tools can cause PAM controls to fail silently if they only monitor interactive admin logins. In regulated environments, that also raises audit questions about who approved the action and whether the action was proportionate to the task. The most fragile designs are those that assume the LLM is “just another app” while allowing it to operate with the privileges of a privileged operator.
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 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST AI 600-1 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC | Identity and access control must cover delegated AI execution paths. |
| NIST AI RMF | GOVERN | AI governance is needed to assign accountability for model-triggered actions. |
| NIST AI 600-1 | GenAI profiles stress traceability and operational controls for LLM systems. | |
| OWASP Agentic AI Top 10 | Agentic AI risks include prompt injection and tool abuse that affect authorization. | |
| MITRE ATLAS | Adversarial AI techniques explain how models can be manipulated into unsafe actions. |
Map AI workflows to access control, log delegation, and remove standing privilege.
