LLM access controls and monitoring: why the permission check happens too late

The question engineers actually ask

Search traffic for best practices on LLM access controls and monitoring is mostly people who already shipped an agent and now want to know what to log. That is the wrong end of the problem. Logging tells you what happened. Access control decides what can happen. If the control is in the wrong place, the log is just a record of the damage.

This article is about where the control belongs, what breaks when it is misplaced, and how to implement it with reskSecure and ReskPoints.

What AI agent security means here

AI agent security is the discipline of constraining what an autonomous or semi-autonomous LLM system can do with the credentials it holds. It is not prompt filtering. It is not model alignment. It is the same problem as any other privileged integration: an actor with a token makes requests, and you must decide which requests are legitimate.

The difference is that the actor is non-deterministic. A traditional service calls the endpoints its code names. An agent calls the endpoints the model names at runtime, based on text that may come from an untrusted source.

The attack surface, concretely

Consider a support agent with three tools: read a customer record, issue a refund, send an email. The integration authenticates once with a service token that can do all three.

Now the agent reads a customer message. The message contains instructions that the model treats as part of its task. The model calls the refund tool with an amount and an account number taken from that message.

The token was valid. The call was well-formed. Nothing in the request path was malformed. The only thing that went wrong is that the model was allowed to choose a tool the caller was never entitled to invoke.

This is not a hypothetical class of bug. It is the direct consequence of giving an agent one credential that spans every capability it might ever need. The blast radius of a single injected instruction equals the scope of that credential.

Why the usual placement fails

Most implementations check permissions inside the tool handler. The flow looks like this:

1. Authenticate the agent.
2. Send the tool definitions to the model.
3. Model selects a tool and produces arguments.
4. Handler validates the caller and executes.

Step 4 is too late. By the time the handler runs, the tool has been selected and the arguments have been constructed from model output. You can reject the call, but you have already let untrusted text drive tool selection. Any side effect that occurs before the check, including downstream calls the handler makes while validating, is outside your control.

The ordering is the vulnerability.

The mechanism that stops it

Move the decision ahead of the model. The control belongs between identity resolution and tool exposure.

1. Resolve the caller identity from the request, not from the model.
2. Map that identity to an explicit allowlist of tool names.
3. Expose only the allowlisted tools to the model.
4. Reject any tool name that is not on the list before arguments are evaluated.
5. Record the decision, the tool name, the arguments and the outcome.

Two properties matter. First, the allowlist is derived from the caller, so the model cannot widen its own scope. Second, the rejection happens before argument evaluation, so a malformed or hostile argument never reaches a handler.

Monitoring sits on top of this. Every allow and deny decision is an event. A deny is the interesting one: it means something tried to reach outside its scope. A spike in denies from one identity is a signal worth alerting on.

Implementation with RESK

reskSecure enforces the allowlist at the boundary, before tool definitions are handed to the model. You declare which tools each identity may invoke, and reskSecure rejects anything outside that set. The model never sees a tool it is not entitled to call, so it cannot select one.

ReskPoints records the decision stream. Each entry carries the identity, the tool name, the arguments and whether the call was allowed or denied. That gives you the audit trail and the alerting surface in one place, rather than reconstructing intent from application logs after an incident.

Together they cover the two halves of the problem: reskSecure decides, ReskPoints records. Neither is useful alone. An allowlist with no record of denials is blind. A log with no enforcement is a diary.

Checklist

• Resolve caller identity from the request, never from model output.
• Derive the tool allowlist from the identity, not from a global agent config.
• Reject non-allowlisted tool names before arguments are evaluated.
• Expose only allowlisted tools to the model.
• Log every allow and deny with identity, tool name, arguments and outcome.
• Alert on deny spikes per identity.
• Review allowlists on the same cadence as any other privileged access.

Enforce least privilege on your agents: https://resk.fr/projects/resksecure.html