Why do dormant permissions become riskier when employees use generative AI?

Why This Matters for Security Teams

dormant permissions are not harmless just because they sit unused in a directory or role catalogue. The moment a generative AI tool can search, summarise, draft, extract, or act on behalf of a user, old access can become active exposure in a new workflow. That is why static role reviews often miss the real risk: the entitlement still looks acceptable, but the session context has changed. Current guidance from NIST AI 600-1 Generative AI Profile and OWASP NHI Top 10 both points toward runtime control of AI-enabled access, not just periodic entitlement cleanup.

NHIMG research shows why the issue is not theoretical: in the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope. That same pattern can apply when a worker prompts an AI assistant with an old mailbox privilege, a stale database role, or a long-forgotten document repository permission. The AI does not need to change the entitlement to create a bigger blast radius; it only needs to reuse it more efficiently.

In practice, many security teams encounter the exposure only after sensitive data has already been repackaged into a summary, export, or downstream action rather than through intentional privilege escalation.

How It Works in Practice

The practical failure mode is simple: dormant access becomes dangerous when AI turns “rarely used” into “machine-speed reusable.” A person may have had read access to a finance folder for months without issue, but an AI assistant can ingest that content, combine it with chat history, and surface it into a broader task flow. That can expose data to another team, another system, or another model prompt without any obvious entitlement change. The problem is amplified when an AI agent has tool access and can chain actions across email, storage, ticketing, and databases.

Security teams should think in terms of workload identity, context-aware authorisation, and JIT issuance. Instead of relying only on RBAC, current best practice is evolving toward intent-based decisions evaluated at request time. That means the platform should ask not only “does this user have access?” but also “is this AI session authorised to do this exact action right now, for this purpose, with this dataset?” This is where NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 are useful: both reinforce governance, access discipline, and continuous control of identities that act without human pacing.

• Issue short-lived credentials per task, not broad static tokens that live across sessions.
• Bind AI actions to workload identity so the system can prove what the agent is, not just what secret it holds.
• Evaluate policy at request time, with context such as data sensitivity, destination system, and intended action.
• Revoke or narrow access when the task ends, rather than waiting for the next access review cycle.

For broader risk framing, the Ultimate Guide to NHIs — Key Challenges and Risks and the Top 10 NHI Issues both show how over-permissioning and secret sprawl combine to create hidden exposure. These controls tend to break down in legacy environments where a single service account is shared across many workflows because there is no clean way to separate human intent from machine execution.

Common Variations and Edge Cases

Tighter access controls often increase operational overhead, requiring organisations to balance reduced exposure against slower workflows and more policy maintenance. That tradeoff becomes sharper in AI-heavy environments, especially where agents need to call multiple tools in sequence. In those cases, a blanket denial model can frustrate users, while broad permissions can create silent overreach. There is no universal standard for this yet, but current guidance suggests using the smallest practical window of access and the narrowest practical scope for each task.

One edge case is delegated access. A user may legitimately need access to sensitive data, but the AI should not automatically inherit the full breadth of that access. Another is long-running agentic workflows, where a short-lived token expires before the agent finishes. The answer is not to make the token longer lived by default; it is to redesign the workflow so each stage requests only the permissions it needs. For governance and design patterns, NHIMG’s Microsoft Azure OpenAI service breach shows how quickly weak access boundaries can turn into broad data exposure, while DeepSeek breach illustrates the hazard of secrets and sensitive records being present where they should not be.

For teams building agentic systems, the right question is not whether a permission exists, but whether the AI should be allowed to reuse it in this moment. That is the difference between dormant access and dangerous access, and it is where the risk often hides in plain sight.

Related resources from NHI Mgmt Group

• How should security teams govern API keys used for generative AI access?
• What makes agentic AI an NHI governance issue?
• When does a machine identity become a compliance problem?
• Why is NHI governance critical in the age of AI attacks?