Why do static RBAC and pre-approval controls fail for GenAI?

Why static RBAC breaks down for GenAI

Static RBAC is designed to answer a coarse question: is this identity allowed to reach a system, role, or broad function? GenAI needs a finer one: is this specific prompt, retrieved context, tool call, or output safe right now? That gap is why static role assignment often grants too much by default and still misses unsafe action paths.

GenAI systems change the security decision at runtime. A user may be authorised to use a chat application, but the model’s response can vary with prior messages, embedded instructions, retrieved documents, and tool availability. A role model that only checks login-time membership cannot express those shifting conditions with enough precision.

That is also why pre-approval often disappoints. Approval can say a person may use GenAI, or may connect a data source, but it cannot reliably judge whether a later query will expose sensitive context, induce a harmful tool invocation, or combine benign inputs into an unsafe action. The decision point moves from access to behaviour.

Where the control boundary shifts at runtime

The practical issue is that GenAI is not a single static transaction. It is an execution chain, often combining conversation state, retrieval, policy prompts, plugins, APIs, and downstream systems. In that chain, risk is created by the interaction between what the model sees and what it is permitted to do, not just by the identity that opened the session.

IAM and IGA basics help frame the limitation clearly: RBAC works well for stable entitlements, but GenAI decisions often need per-request authorisation, context-aware policy, and tighter separation between use of the system and use of the actions behind it.

For that reason, the useful control question becomes whether the model can be constrained at the point of action. If a prompt can trigger retrieval of documents, invocation of tools, or execution of business workflows, the control has to evaluate the request in context. Static approval alone does not provide that decision quality.

What stronger control patterns have to cover

AI Agent Authorisation Guide shows the direction of travel: task-scoped access, just-in-time permission, and per-action policy decisions are a better fit when a system can act on behalf of a user or choose tools dynamically. Those patterns do not replace identity controls, they narrow them to the action that is actually being attempted.

Permission-Aware RAG Guide is the clearest example for retrieval-heavy GenAI. If the retriever ignores document permissions, a model can surface data the user should never have seen. The relevant decision is therefore not just “can this user access the app?”, but “can this query retrieve this corpus item, and should the model be allowed to use it?”

That is why mature GenAI access control usually needs layered enforcement: identity at entry, permissions on retrieval, policy at tool invocation, and logging on the resulting action. Static RBAC can remain one input to that design, but it cannot be the final gate for a system whose behaviour is shaped by changing context.

Risk and Threat Considerations

Static RBAC and pre-approval create a false sense of safety when the actual exposure is prompt- or context-driven. The main risks are over-broad retrieval, unintended tool use, policy bypass through conversation manipulation, and downstream data leakage or action execution that was never reviewed at approval time.

Failure mechanism: The control is evaluated too early and too coarsely. An identity may be approved for GenAI use, but the model later receives sensitive retrieved content, malicious instructions, or a tool-eligible request that the original role decision never anticipated.

Impact: Organisations can expose confidential data, trigger unauthorised workflow actions, or create an audit trail that wrongly suggests the original approval covered the specific behaviour that actually occurred. In practice, the gap is most serious where GenAI can read, transform, or execute beyond the original user intent.

Practitioner Guidance

What to verify: Verify that your control model distinguishes access to the GenAI interface from permission to retrieve data, call tools, or commit actions. If those are bundled into one role, you do not yet have a runtime control model, you have a coarse entry check.

Decision rule: If the model can influence data exposure or business actions after the session starts, move from static approval to per-request policy evaluation with scoped retrieval and bounded tool permissions.

Practitioner takeaway: Treat RBAC and pre-approval as admission controls, not behaviour controls. GenAI governance becomes credible only when each meaningful action is checked in context, at the moment it is about to happen.

Related resources from NHI Mgmt Group

• Why do static security controls often fail against GenAI systems?
• When should organizations transition from static to dynamic credentials?
• Why do static access controls fail for AI agent governance?
• Why do traditional IAM controls fail for GenAI workflows?