Traditional IAM controls assume a stable subject, a bounded action, and a predictable execution path. GenAI breaks those assumptions because the same user can trigger different outputs, data retrieval, and downstream actions depending on context, meaning authorisation has to operate continuously across the interaction.
Why This Matters for Security Teams
Traditional IAM was built for people who sign in, do a task, and stop. GenAI workflows do not behave that way. A single prompt can trigger retrieval, tool calls, code execution, and data movement across systems that were never designed to share a trust boundary. That is why static roles, long-lived tokens, and one-time approval models routinely miss the real risk surface.
The practical problem is not just access, but agency. Once a model can chain tools, the security question becomes whether each step is still appropriate in context, not whether the original user had a role that looked acceptable at login. NIST’s NIST AI 600-1 GenAI Profile reflects this shift toward continuous governance, while NHIMG research on LLMjacking shows how quickly exposed AI credentials are abused in the wild.
In practice, many security teams encounter over-privileged GenAI access only after an agent has already retrieved data, invoked a tool, or reused a secret outside its intended context.
How It Works in Practice
For GenAI, the control point moves from the initial login to the runtime decision. The safer pattern is to treat the model or agent as a workload identity, then grant permissions only for the specific task, time window, and data scope required. That usually means short-lived tokens, ephemeral secrets, and policy checks that run at request time rather than at session start.
Current guidance suggests combining workload identity with context-aware authorisation. In practice, that can include OIDC-bound workload tokens, SPIFFE-style identity for services and agents, and policy-as-code engines that evaluate the prompt intent, destination tool, sensitivity of the data, and current environment state before allowing an action. This is materially different from RBAC, which answers “who is this?” but not “what is this agent trying to do right now?”
NHIMG’s The State of Secrets in AppSec is a useful reminder that secrets hygiene remains fragile even in mature programs. When GenAI systems can read from code repositories, ticketing systems, or knowledge bases, a leaked token is not just a credentials issue, it becomes an execution path. That is why JIT provisioning matters: credentials should exist only long enough for the task, then be revoked automatically.
- Use a distinct workload identity for each agent, service, or pipeline.
- Issue credentials per task, not per team or application.
- Evaluate tool calls against real-time policy, not only static group membership.
- Restrict retrieval scope so the model only sees the minimum data needed.
- Log each action separately so downstream steps can be traced and revoked.
Where this breaks down is in legacy automation stacks that share a single service account across multiple pipelines, because the runtime cannot distinguish one agent’s legitimate action from another’s borrowed authority.
Common Variations and Edge Cases
Tighter runtime control often increases integration overhead, requiring organisations to balance safety against developer velocity and system complexity. That tradeoff is especially visible in multi-agent environments, where one agent may call another, inherit partial context, or hand off a task across tools.
There is no universal standard for this yet, but best practice is evolving toward context-scoped permissions and continuous evaluation. For example, a customer-support assistant may need read-only access to ticket records, while a code-generation agent may need ephemeral repository write access only during a bounded deployment step. Those are not equivalent risks, even if both are “AI apps.”
The same logic applies to incidents. NHIMG’s DeepSeek breach illustrates how exposed data and embedded secrets can turn AI systems into high-value attack surfaces. Once an agent can discover, copy, and reuse material across systems, static IAM no longer contains the blast radius. That is why current guidance increasingly favours Zero Standing Privilege, short TTLs, and policy checks that are aware of the action, not just the subject.
In highly regulated environments, these controls can also conflict with audit expectations if teams cannot prove why a given tool call was approved. The practical answer is not broader standing access, but stronger telemetry and decision logging tied to each runtime authorisation.
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 | LLM05 | Covers excessive agency and unsafe tool use in GenAI workflows. |
| CSA MAESTRO | A2 | Addresses agent identity, tool access, and continuous governance. |
| NIST AI RMF | Supports governance of autonomous AI risk across the workflow. |
Use AI RMF governance to define ownership, logging, and runtime accountability for GenAI actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
