Best practices for implementing LLM access controls and monitoring

The question engineers actually ask

When a team ships an agent, the first question is usually about the model. Which model, which prompt, which temperature. The question that decides whether the system is safe to run in production is different: what is this agent allowed to do, and who decides that at the moment it tries to do it.

This article is about that second question. It covers what AI agent security means in practice, where access control belongs in the request path, the failure mode that appears when it is placed wrong, and how to implement it with RESK.

What is AI agent security

AI agent security is the set of controls that govern what an autonomous or semi-autonomous agent can do with the tools it has been given. It is not the same as model alignment, and it is not the same as prompt injection defense, although the two overlap.

An agent is a loop. It receives a goal, decides on an action, invokes a tool, observes the result, and decides again. Security lives at the point where the decision becomes an action. Everything before that point is intent. Everything after is consequence.

That framing matters because it tells you where to put the control. You cannot reliably control intent expressed in natural language. You can control the invocation of a tool.

Best practices for implementing LLM access controls and monitoring

Start from the invocation, not from the prompt.

Identify the caller. Every tool call should carry an identity for the agent, not just for the human who started the session. A single user token shared across every agent in a fleet gives you no way to scope permissions or to attribute an action after the fact.

Scope permissions to the task, not the agent. An agent that can read a repository does not need to be able to push to it for every task. Permissions should be granted for the duration of a task and revoked when the task ends.

Decide before execution. The permission check must sit in front of the tool call. A check that runs after the call returns is a log entry, not a control.

Monitor on the same path. If the allow and deny decisions are recorded by a different system than the one that makes them, the two will drift. The decision point and the observation point should be the same component.

Record the reason. A deny without a reason is hard to debug and hard to tune. A deny with the rule that fired is actionable.

Attack surface, concretely

Consider an agent with three tools: read a file, write a file, and send an HTTP request. The task is to summarize a document.

The agent reads the document. The document contains text that instructs the agent to send its contents to an external endpoint. The agent, following the instruction it found in the data, calls the HTTP tool.

Nothing in the model stopped this. The model did what the text told it to do. If the only control in the system is a prompt that says do not exfiltrate data, the control failed at the moment the data was untrusted input.

Now consider the same scenario with a permission layer in front of the tool invocation. The task is summarize. The permission set for that task includes read and does not include send. The HTTP tool call is denied before it executes. The agent receives a denial, the side effect does not happen, and the denial is recorded with the rule that fired.

The difference between the two scenarios is not the model. It is the ordering of the check relative to the invocation.

The mechanism that stops it

The mechanism is a policy decision point in the request path, between the agent runtime and the tool. The agent does not call the tool directly. It requests the call. The decision point evaluates the request against the permissions granted for the current task and returns allow or deny. Only on allow does the tool execute.

This has three consequences worth stating plainly.

First, the decision is deterministic. It does not depend on the model behaving well. It depends on the permission set, which is data you control.

Second, the decision is observable. Every request produces a record, whether it was allowed or denied. That record is the monitoring signal.

Third, the decision is auditable. You can answer the question of what an agent did and why it was permitted, after the fact, from the records the decision point produced.

Implementation with RESK

reskSecure is the enforcement layer. It sits between the agent runtime and the tools, evaluates each tool invocation against the permissions granted for the task, and returns allow or deny before the tool executes. It is where least privilege is enforced rather than described.

ReskPoints is the observation layer on the same path. Because it records the decisions reskSecure makes, the monitoring data and the enforcement data are the same data. You do not reconcile two systems that disagree about what happened.

For the permission model itself, see the companion article on AI agent tool permissions, which covers how tool scopes are defined and granted.

Checklist

• Every tool call carries an agent identity, not only a user identity.
• Permissions are scoped to the task and expire with it.
• The permission check runs before the tool executes, not after.
• Denials are recorded with the rule that produced them.
• Monitoring reads from the same path that enforces, so the two cannot drift.
• The default is deny. A tool is available because it was granted, not because it was not blocked.

If you can answer yes to all six, you have access control. If you can answer yes to the first five and not the sixth, you have monitoring with a permission-shaped hole in it.