Why LLM Permission Checks Are Always Too Late: The Critical Blind Spot in AI Agent Access Control

The Question Engineers Should Really Be Asking

Most people searching for "LLM access control best practices" have already shipped their Agent and now want to know what to log. That gets it exactly backwards. Logs tell you what happened; access control decides what can happen. If the control point is in the wrong place, your logs are just an inventory of losses.

The question worth asking isn't "what should I log" — it's "where should the decision be made."

What AI Agent Security Actually Is

At its core, AI Agent security is about constraining what an autonomous or semi-autonomous LLM system can do with the credentials it holds. It's not prompt filtering, and it's not model alignment. It's the same class of problem any privileged integration faces: an actor with a token makes a request, and you need to determine which requests are legitimate.

The difference is that this actor is non-deterministic. Traditional services call endpoints hardcoded in the source; an Agent calls endpoints the model decides on the fly based on text — text that may come from untrusted sources. That single difference invalidates every assumption in traditional permission models.

Prompt Injection is essential background for understanding the attack scenario in this article. It refers to attackers embedding malicious instructions into text the model will read (user input, retrieved documents, email bodies, web content, etc.), causing the model to mistake those instructions for part of a legitimate task. Unlike traditional code injection, prompt injection exploits the model's lack of structural distinction between "instructions" and "data" — to the model, both are just token sequences. Indirect Prompt Injection is especially dangerous because the malicious text doesn't pass through the user's hands; it enters the context via external data the Agent reads, often without the user's knowledge. The customer service Agent example in this article is exactly this case: a hidden instruction in a customer message hijacks the tool selection process. It's worth emphasizing that prompt filtering cannot fundamentally solve this problem, because bypass techniques are endless and model behavior is non-deterministic; the real line of defense is the permission boundary — even if the model is manipulated, it should not have the ability to perform unauthorized operations.

The Attack Surface: A Concrete Scenario

Imagine a customer service Agent equipped with three tools: read customer records, issue refunds, send email. The integration authenticates with a single service token, and that token can do all three.

The Agent reads a customer message. Hidden inside is an instruction the model treats as part of the task. The model immediately calls the refund tool, with the amount and account number taken from that message.

The token is valid, the call format is legitimate, there's no malformed data in the request path. The only thing wrong is this: the model was allowed to select a tool that the caller should never have triggered in the first place.

This isn't a hypothetical vulnerability class — it's the direct consequence of "giving an Agent a single credential covering all its capabilities." The blast radius of one injected instruction equals the authorization scope of that credential.

Why the Conventional Approach Fails

Most implementations put permission checks inside the tool handler. The flow looks roughly like this:

1. Authenticate the Agent
2. Send tool definitions to the model
3. The model selects a tool and generates parameters
4. The handler validates the caller and executes

Step 4 is already too late. By the time the handler runs, the tool has already been selected and the parameters have already been constructed from model output. You can reject the call, but untrusted text has already driven the tool selection process itself. Any side effects produced before the check occurs — including downstream calls the handler makes during validation — are already outside your control.

The vulnerability isn't a wrong condition somewhere. It's the ordering itself.

TOCTOU (Time-of-Check to Time-of-Use) is the classic security model for understanding the claim that "the ordering itself is the vulnerability." It describes a situation where a system checks that some condition holds at one point, but by the time the object protected by that condition is actually used, the state may have changed, rendering the check ineffective. In traditional software, TOCTOU often manifests as a file permission check being followed by the file being swapped before it's opened. In the LLM Agent context, it operates at the logic level: the permission check happens inside the tool handler (the use point), while the decision driving that use (the model selecting the tool and generating parameters) was already made when the context was contaminated. The assumption the check relies on — "the call being checked is legitimate" — was already false before the check. So the fix isn't to write a stricter validation; it's to move the check forward, before the decision is made, so malicious input can never enter the decision step. This also explains why "rejection happens before parameter evaluation" is a hard requirement.

Move the Decision Ahead of the Model

The control point should sit between identity resolution and tool exposure. The correct sequence is:

1. Resolve the caller's identity from the request, not from model output
2. Map that identity to an explicit tool whitelist
3. Expose only the whitelisted tools to the model
4. Reject any tool name not on the list before parameters are evaluated
5. Log the decision, tool name, parameters, and result

Two properties are critical. First, the whitelist is derived from the caller's identity — the model cannot escalate its own privileges. Second, rejection happens before parameter evaluation, so malformed or malicious parameters never reach the handler.

Monitoring builds on top of this. Every allow and every deny is an event, and the denials are the interesting ones — they mean something tried to step outside its scope. A spike of denials from the same identity is a signal worth alerting on.

The Principle of Least Privilege (PoLP) is the theoretical foundation for deriving whitelists from identity. It requires that any subject be granted only the minimum set of permissions necessary to accomplish its task, and that permissions should converge rather than expand over time and context. In multi-tenant or role-based systems, this typically means permissions are bound to identity (who the caller is) rather than to the resource or the process itself. What this article argues against is precisely the coarse-grained authorization of "giving an Agent a single service token covering all capabilities" — it lets one credential hold read, refund, and send-email capabilities simultaneously, effectively nullifying the Principle of Least Privilege. Deriving whitelists from identity means different callers can reach different tool sets even when sharing the same Agent runtime, limiting the blast radius of a single point of compromise to that identity's rightful scope. Regular whitelist review is also an expression of the PoLP requirement for "continuous convergence."

Implementing It with RESK

reskSecure enforces the whitelist at the boundary, before tool definitions are handed to the model. You declare which tools each identity can call, and reskSecure rejects everything outside that set. The model simply never sees tools it isn't authorized to call, so it has no way to choose them.

ReskPoints records the decision flow. Each record carries the identity, tool name, parameters, and whether the call was allowed or denied. Audit trails and alerting surfaces are therefore centralized in one place, instead of being reverse-engineered from application logs after an incident.

Together they cover both halves of the problem: reskSecure makes the decision, ReskPoints records it. Using either alone isn't enough. A whitelist with no visibility into denials is blindness; logs with no enforcement are just a diary.

The Checklist

• Resolve the caller's identity from the request, never from model output
• Derive the whitelist from identity, not from a global Agent configuration
• Reject tool names not on the whitelist before parameter evaluation
• Expose only whitelisted tools to the model
• Log every allow and every deny, including identity, tool name, parameters, and result
• Alert on denial spikes per identity
• Review whitelists on the same cadence as other privileged access

One-line Summary

The flaw in Agent security is ordering, not judgment: permission checks must move ahead of the model's tool selection.

Paragraph Summary

The article argues that people searching for "LLM access control best practices" often get it backwards: logs record what already happened, while access control determines what can happen. AI Agent security is fundamentally about constraining what a non-deterministic system with credentials can do, and its attack surface lies in untrusted text driving on-the-fly tool selection and parameter construction. Most implementations put permission checks inside tool handlers — too late — because the vulnerability stems from check ordering, not judgment logic. The correct approach places whitelist decisions between identity resolution and tool exposure: resolve identity from the request rather than model output, derive a tool whitelist from identity, expose only whitelisted tools, and reject out-of-scope calls before parameter evaluation. Denials are more valuable than allows, and denial spikes from the same identity should trigger alerts. reskSecure handles boundary enforcement while ReskPoints records the decision flow — neither alone is sufficient.