LLM requests vary too much for static permissions to carry the full load. A single credential may be used in different contexts, but the risk changes with the user, metadata, environment, and intended use, so authorisation has to evaluate each request before it reaches the model.
Why LLM authorisation has to happen per request
Static permissions are too coarse for LLMs because the same credential can drive very different actions depending on who is asking, what data is in scope, which connectors are available, and whether the request is read-only or can trigger side effects. Request-level authorisation lets you evaluate the full context before the model, tool, or retrieval step acts.
An LLM is not one fixed workflow. It may answer a general question, retrieve internal records, call an API, or draft an action for another system, and each of those has a different risk profile. A permission model that only checks the identity once at login cannot distinguish a harmless request from one that would expose sensitive data or execute an unsafe tool action.
That context matters because LLM sessions are often reused across prompts, tools, and data sources. A user may be entitled to see one dataset but not another, or allowed to ask the model general questions but not to have it retrieve confidential content from a connector. Request-level authorisation closes that gap by deciding, at the moment of use, whether the request is permitted in this exact context.
For LLMs, this is especially important where the model is embedded in retrieval or agentic workflows. Permission-aware RAG is a good example of why retrieval must respect user entitlements at request time, not just at authentication time, and why over-sharing has to be blocked before it reaches the model.
Where static permissions break down in practice
Static permissions assume the access decision is stable, but LLM usage is highly variable. The same user might ask for a public summary, then a private analysis, then a connector-backed lookup, all under the same session. If the system only checks a standing role or token scope, it misses the differences in intent, target data, and operational impact.
That creates two common failure modes. First, overbroad standing access allows the model to retrieve or generate more than the user should see. Second, underbroad static access forces teams to grant larger permissions than needed so the product keeps working, which expands blast radius. Request-level checks let teams keep the standing credential small while making the actual decision at the moment of the request.
This is also why downstream controls such as connectors, retrieval filters, and tool permissions cannot be treated as enough on their own. They are part of the control stack, but the authorisation decision still has to be made against the specific prompt, user, environment, and allowed action. Otherwise a credential that is safe for one context becomes unsafe in the next.
When the model can invoke tools or external services, the authorisation question is no longer just “can this user log in?” It becomes “can this request read that record, call that API, or trigger that action right now?” That is the difference between a static access grant and a contextual decision.
What good request-level authorisation looks like for LLM systems
Good design separates authentication from authorisation. Authentication proves who or what is making the request; request-level authorisation decides what that request is allowed to do, given the current context. In LLM systems, that context usually includes the user, tenant, prompt content, target resource, connector, environment, and whether the action is read, write, or execute.
The practical test is whether the control can answer “yes” or “no” for each request without relying on a standing assumption that past permission is still sufficient. If the answer depends on data sensitivity, workflow state, or whether a tool call would create side effects, the system needs per-request policy evaluation.
That policy should also be narrow enough to preserve usability. The goal is not to reauthenticate on every token, but to make the model’s effective authority conditional on the specific request. In mature implementations, that means least privilege at the request layer, explicit policy for tool invocation, and separate enforcement for retrieval, generation, and action execution.
Agentic AI security guidance is useful here because it treats identity and privilege as runtime control points, not just setup-time configuration. For teams building copilots or agents, that is the right mental model: the request is the unit of trust, not the user session.
Risk and Threat Considerations
Static permissions increase exposure when prompts, tools, and data sources vary at runtime. A credential that looks harmless at login can become high risk once the model is allowed to retrieve sensitive data, invoke external systems, or chain actions across connectors.
Failure mechanism: The system reuses one standing permission set across requests, so an attacker, over-privileged user, or misrouted workflow can turn a low-risk session into unauthorized data access or unintended action execution.
Impact: The likely result is data leakage, excessive access, or unsafe side effects at machine speed, especially when the model can read internal content or call tools without a fresh contextual check.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Request-level authorization controls which functions an LLM request may invoke. |
| Recommendation — Enforce function-level checks before any model-triggered action or tool call. | ||
| NIST Zero Trust (SP 800-207) | Never trust, always verify | LLM requests need continuous contextual verification rather than static trust. |
| Recommendation — Verify each LLM request against current context before granting access or execution. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Static permissions overgrant; request-level authorization narrows authority at use time. |
| IA-5 — Authenticator Management | A single credential may be reused across changing LLM contexts and must be tightly governed. | |
| Recommendation — Limit each request to the minimum access required for that specific task. Manage credentials so standing access does not exceed the intended request scope. | ||
| OWASP ASVS | V8 — Authorization | The question is fundamentally about authorization decisions applied to each request. |
| Recommendation — Apply authorization checks at the point of each sensitive request. | ||
Practitioner Guidance
What to verify: Confirm that policy is evaluated on each request before retrieval or tool execution, and that the decision can vary by user, tenant, resource, and action type. If the same standing grant always produces the same outcome, the control is probably too coarse for LLM use.
What good looks like: The model can answer benign prompts without broad access, but any request that crosses a sensitivity boundary, changes state, or touches a connector is checked against current context and denied by default when the policy is unclear.
Practitioner takeaway: For LLMs, the safe pattern is conditional authority, not permanent entitlement; keep the credential stable, but make the permission decision specific to each request.
Related resources from NHI Mgmt Group
- Why do agentic systems need runtime authorisation instead of static permissions?
- When should organizations transition from static to dynamic credentials?
- What breaks when network controls are used instead of request-level policy for machine access?
- Why do AI systems need request-level logs instead of only dashboards?