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

The question

Teams ask for best practices for implementing LLM access controls and monitoring. The usual answers are about prompts, system messages, and guardrail models. Those are useful, but they are not access controls. An access control is a decision about whether a principal may perform an action on a resource. If that decision is expressed only as text the model reads, the model can be argued out of it.

This article is about architecture: where the control belongs in the request path, and why that placement is the difference between a policy and a suggestion.

What AI agent security means here

AI agent security is the discipline of constraining what an autonomous or semi-autonomous system can do with the credentials and tools it has been given. The model is one component. The agent is the whole loop: model output, tool selection, tool execution, observation, and the next turn.

That loop is why agent security differs from model security. A model that produces a bad sentence is an embarrassment. An agent that produces a bad tool call is a side effect: a row written, a message sent, a file read, a payment initiated. The blast radius is in the tools, not in the tokens.

Attack surface, concretely

Consider a support agent with three tools: read a customer record, issue a refund, and send an email. The agent runs with a single service credential that can do all three.

An attacker does not need to break the model. They need to get text into the context that the model treats as an instruction. That can arrive through a retrieved document, a ticket body, a web page the agent fetches, or a previous tool result. Once it is in context, the model may select the refund tool with an attacker-chosen amount.

Nothing in that path is exotic. The failure is structural: the credential the agent holds is broader than the task it is performing, and the decision to call the tool is made by the same component that can be influenced by untrusted input.

A second failure mode is ordering. Many implementations validate after the tool call has been dispatched, or validate the model output as text rather than the resolved tool invocation. By the time the check runs, the side effect exists. Logging then records the outcome, not the decision, which makes the incident hard to reconstruct.

The mechanism that stops it

The control belongs at the boundary between the model and the tool executor. Concretely, the request path should be:

1. Model emits a structured tool call.
2. The call is intercepted before dispatch.
3. The call is resolved to a principal, a tool, and a resource scope.
4. A policy decision is made against that principal and scope.
5. Only an allow reaches the executor. A deny returns a typed error to the agent loop.
6. The decision, the arguments, and the result are recorded on the same boundary.

Two properties matter. First, the decision is made outside the model, so untrusted context cannot rewrite it. Second, the decision happens before execution, so a deny has no side effect to undo.

Scoping is the other half. Instead of one credential that can do everything, each tool call is evaluated against the narrowest scope that satisfies the task. A refund tool call carries an amount and a customer identifier; the policy can constrain both. A read tool call carries a record identifier; the policy can constrain which records are visible to this principal.

Monitoring follows the same boundary. The useful signal is not the final answer text. It is the sequence of tool calls, the principal behind each one, the decision, and the arguments. That is what lets you answer, after an incident, which calls were allowed, which were denied, and what changed.

Implementation with RESK

reskSecure is the enforcement point for this boundary. It sits between the agent and the tool executor, resolves each tool call to a principal and a scope, and returns an allow or deny before dispatch. Because the check is outside the model, it does not depend on the model following instructions.

ReskPoints is the observability layer on the same boundary. It records the tool calls, the decisions, and the arguments, so the monitoring view reflects what the agent actually attempted rather than what it reported.

The practical effect is least privilege that is enforced. You can give an agent a narrow scope, watch the denials, and widen only where the evidence supports it. That is a different posture from granting broad access and hoping the prompt holds.

For the related question of how tool permissions are modeled, see the article on AI agent tool permissions.

Checklist

• Identify every tool the agent can call and the credential behind it.
• Move the authorization decision to the boundary between model output and tool dispatch.
• Resolve each tool call to a principal, a tool, and a resource scope before execution.
• Deny by default, and return a typed error to the agent loop on deny.
• Constrain arguments, not just tool names, where the tool takes a resource identifier or an amount.
• Record the decision, the arguments, and the result on the same boundary.
• Review denials regularly and widen scope only with evidence.
• Treat retrieved content and tool results as untrusted input to the loop.

Enforce least privilege on your agents with reskSecure.