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

What is AI agent security?

AI agent security is the discipline of constraining what an LLM-driven agent can do to real systems. The model itself is not the boundary. The boundary is the set of tools the agent can call, the credentials those tools use, and the checks that run before a call executes. If you treat the prompt as a security control, you have no control at all.

Best practices for implementing LLM access controls and monitoring

The question engineers actually ask is where to put the check. The answer is the tool boundary, in the request path, outside the model.

A request to an agent typically flows: user input, model reasoning, tool selection, tool execution, result returned to the model. The model controls the middle steps. You control the edges. Access control belongs between tool selection and tool execution, and monitoring belongs around both.

Three practices follow from that ordering:

1. Authenticate the caller before the model sees anything.
2. Authorize the specific tool and the specific resource after the model selects a tool but before it runs.
3. Log the tool call with its arguments and its result, not just the final answer.

If authorization is expressed in the system prompt, it is a suggestion. A model that is persuaded to ignore the suggestion still calls the tool. The check must be code that runs whether or not the model cooperates.

Attack surface, concretely

Consider an agent with a tool that reads files and a tool that sends email. The email tool uses a service credential with broad send rights. A user pastes text into the agent that contains an instruction to read a configuration file and email it to an external address. The model, following the injected instruction, selects the read tool, then the email tool. Both calls are legitimate from the tool layer point of view. The credential is valid. The API accepts the request.

The failure is not that the model was fooled. Models will be fooled. The failure is that the tool layer had no notion of which resource the caller was allowed to read, or which recipient the caller was allowed to send to. The permission was scoped to the tool, not to the caller and the resource.

This is not theoretical. It is the ordinary consequence of giving an agent a credential and letting the model choose arguments.

The mechanism that stops it

The mechanism is least privilege enforced at the tool boundary, with three properties.

First, the credential used by a tool is scoped to the minimum the tool needs. A read tool gets read access to a named set of paths, not to the filesystem. A send tool gets send rights to a named set of recipients.

Second, the authorization decision is made per call, using the authenticated caller identity and the concrete arguments the model produced. The decision happens after argument generation and before execution. This is the only point where you know both who is asking and what is being asked.

Third, every call is logged with caller, tool, arguments, decision and result. Monitoring is not a dashboard added later. It is the record that makes the authorization decision auditable and lets you detect a pattern of denied or unusual calls.

Ordering is the whole design. Authenticate, authorize, execute, log. Any reordering weakens the control. If you log after execution without authorizing before it, you have an audit trail of the damage.

Implementation with RESK

RESK provides two pieces for this.

reskSecure enforces least privilege on agent tool permissions. It sits at the tool boundary and evaluates each call against the caller identity and the requested resource before the tool executes. This is where the authorization decision lives, outside the model.

ReskPoints gives you the monitoring record: tool calls with their arguments and outcomes, so that denials and unusual patterns are visible rather than inferred from final answers.

A practical integration keeps the model unchanged. You wrap tool execution so that every call passes through reskSecure, and you emit a ReskPoints record for the decision and the result. The model still chooses tools. It no longer chooses whether the call is allowed.

For the related question of how tool permissions are scoped in practice, see our article on AI agent tool permissions.

Checklist

• Authenticate the caller before the model processes input.
• Scope each tool credential to the minimum resource set it needs.
• Authorize every tool call after argument generation and before execution.
• Base the decision on caller identity and concrete arguments, not on the prompt.
• Log caller, tool, arguments, decision and result for every call.
• Review denied calls as a signal, not as noise.
• Keep authorization code outside the model so it runs regardless of model behaviour.

Enforce least privilege on your agents with reskSecure.