They reduce the gap between request, approval, and execution, which can improve adoption and reduce workaround behaviour. But they also move more identity work into runtime decision paths, so controls must be enforced where the work occurs. That means governance shifts from a separate review function to a workflow-integrated control model.
Why This Matters for Security Teams
AI assistants change IAM and IGA operating models because they compress work into runtime. A user no longer submits a request, waits for a review, and then acts later with a separate entitlement. The assistant can propose, request, and execute access-related actions in the same workflow, which means identity governance must move closer to the point of action. That shift is visible in NHI incidents such as the LLMjacking report, where exposed credentials are abused quickly once they exist in the wild.
This matters because traditional IAM assumes a relatively stable human user with predictable access patterns, while assistants behave like software workloads that vary by prompt, context, and tool chain. In practice, that makes request-and-approve models too slow for adoption and too weak for control if the approval is detached from execution. The governance problem is not just who asked, but what the assistant is about to do, with which secrets, and under what runtime conditions. Current guidance aligns more closely with NIST Cybersecurity Framework 2.0 thinking than with legacy ticket-based access management. In practice, many security teams encounter policy bypass only after assistants have already normalised shadow workflows.
How It Works in Practice
The operating model changes when identity decisions become contextual and ephemeral instead of static and periodic. For AI assistants, the safer pattern is to treat the assistant as a workload identity, not a human surrogate, and to issue permissions only for the task being performed. That usually means just-in-time access, short-lived tokens, and policy evaluation at request time rather than broad entitlements reviewed on a calendar.
Practically, teams are moving toward a stack where the assistant authenticates with workload identity, receives scoped access for a bounded action, and is continuously checked against policy-as-code. Standards and implementation guidance increasingly point in this direction. For example, NIST Cybersecurity Framework 2.0 reinforces governance and access control as operational functions, while NHIMG research on DeepSeek breach shows how rapidly exposed secrets can become a broader control failure. Best practice is evolving, but the practical direction is clear:
- Use runtime authorization for each tool call or data access, not one-time approval for the whole assistant session.
- Issue short-lived secrets and revoke them automatically when the task ends.
- Bind access to workload identity and execution context, not to a generic service account.
- Log the prompt, tool invocation, approval context, and policy decision as one event chain.
This model works best when the assistant has a narrow scope and a predictable set of tools, because policy can then be expressed precisely enough to evaluate in real time. These controls tend to break down when assistants are allowed to chain tools across multiple systems with no consistent identity boundary, because the governance context fragments across each hop.
Common Variations and Edge Cases
Tighter runtime control often increases operational overhead, requiring organisations to balance speed and adoption against approval rigor and policy maintenance. That tradeoff is especially visible when assistants support high-volume internal workflows, where too much friction causes users to revert to manual workarounds.
There is no universal standard for this yet. Some environments can rely on strong session-level controls and task-scoped tokens, while others need deeper guardrails such as approval gates for high-risk actions, break-glass paths, and continuous monitoring of assistant tool use. The right model depends on whether the assistant is only recommending actions or actually executing them. If it can create, modify, or exfiltrate data, then IAM and IGA must account for execution authority, not just access request intent.
Edge cases also emerge when assistants operate across multiple identities, tenants, or APIs. In those environments, a single governance workflow may not be enough, because the decision is split between the human requester, the assistant runtime, and the downstream service account. NHIMG analysis of the Azure Key Vault privilege escalation exposure illustrates how apparently narrow access can expand through role chaining. The lesson is simple: when assistants can act, not just advise, identity governance must be built into the execution path itself.
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 CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agentic systems need runtime controls because assistants act autonomously. |
| CSA MAESTRO | GOV-1 | MAESTRO covers governance for agentic workflows and tool-mediated execution. |
| NIST AI RMF | AI RMF is relevant because assistant behaviour changes identity risk at runtime. |
Treat assistant actions as high-risk runtime events and enforce scoped, contextual authorization.
