LLM access controls and monitoring: where the control belongs in the request path

Access control for LLM applications is usually discussed as a model problem. It is not. It is a request path problem. The model proposes an action, and something downstream either authorizes it or does not. If that something is missing, no amount of prompt engineering replaces it.

This article looks at the mechanism, a concrete failure mode, and the ordering that makes monitoring useful rather than decorative.

What are the best practices for implementing LLM access controls and monitoring? The honest answer starts with a distinction. There are two different trust boundaries in an LLM application, and they need different controls.

The first boundary is between the user and the model. Here you control who can send prompts, what context they can attach, and what the model is allowed to see. This is familiar application security work.

The second boundary is between the model and the tools it can call. This is where most incidents live, and where most monitoring is thin. The model does not execute anything. It emits a structured request to call a tool with arguments. The runtime decides whether to honor it.

Consider an agent with three tools: read a document, query a database, and send an email. The user is authorized for all three. A retrieved document contains text that instructs the model to send the contents of the database to an external address. The model follows the instruction and emits a tool call.

Nothing was broken. Authentication passed. The user was permitted to use the email tool. The database query was permitted. The only thing that failed was the absence of a check between the model proposal and the execution, on the arguments rather than just the tool name.

This is why tool level allow lists are necessary but not sufficient. Permitting a tool is not the same as permitting every argument that tool can receive.

A second failure mode is ordering. Many stacks log the prompt and the completion, then execute the tool call. The log shows what the model said. It does not show what was executed, with which arguments, on behalf of which identity. When an incident is reviewed, the record is incomplete at exactly the point that matters.

The control belongs between tool selection and tool execution. Concretely, the runtime should do four things in this order.

First, resolve the caller identity independently of the model. The model must not be able to assert who it is acting for. Identity comes from the session, not from the prompt.

Second, evaluate the proposed tool call against a policy that includes the tool name and the arguments. A policy that only checks the tool name cannot distinguish a read from an exfiltration.

Third, execute only after authorization succeeds. This ordering is the whole point. Authorization that runs after execution is an audit trail, not a control.

Fourth, record the decision, the caller, the tool, and the arguments before the result is returned. The record must exist even when the call is denied, because denials are the signal you want to monitor.

Monitoring built on this record answers questions that prompt logs cannot. Which tools are being called with arguments outside their normal shape? Which identities are triggering denials? Is a single session producing an unusual sequence of tool calls?

reskSecure is the enforcement point for this boundary. It evaluates the proposed tool call against policy before execution, so the decision happens in the request path rather than in a log afterwards. Policies can be scoped to the tool and to the arguments, which is what closes the gap described above.

ReskPoints gives you the observability layer over those decisions. Because every authorization decision is recorded with the caller and the arguments, you can monitor denials and argument patterns rather than reconstructing them from prompt text.

The two are meant to be used together. Enforcement without observation gives you a control you cannot tune. Observation without enforcement gives you a record of what already happened.

For the permission model itself, see the companion article on AI agent tool permissions, which covers how to scope what an agent is allowed to do before you wire up enforcement.

The model will keep proposing actions. The runtime is where you decide which ones happen.