Best practices for implementing LLM access controls and monitoring

Most teams start LLM access control at the prompt. They add a system message, a content filter, maybe a moderation endpoint. That covers the text the model produces. It does not cover what the model does. When an agent can call tools, every tool call is a separate request with its own permissions, and the prompt guard does not see it.

This article is about where the control actually belongs and what to monitor once it is there.

What is AI agent security?

AI agent security is the set of controls that govern what an autonomous or semi-autonomous LLM system is allowed to do, not just what it is allowed to say. The unit of control is the action: a tool invocation, an API call, a database write. The question is not whether the model produced a safe sentence. The question is whether this specific agent, in this specific context, is permitted to perform this specific action with these specific arguments.

That framing changes the architecture. A prompt filter sits in front of the model. An access control sits between the model and the tool.

The specific question: access controls and monitoring

Best practices for LLM access controls and monitoring come down to two properties:

1. Every action is authorized at the point of execution, against a policy that names the agent, the tool, and the arguments.
2. Every authorization decision is logged with enough context to reconstruct what happened.

If either property is missing, the system is either over-permissive or unauditable. Most incidents involve both.

Attack surface, concretely

Consider an agent with three tools: read a document, summarize it, and send an email. The prompt guard checks the user input. The agent reads a document that contains an instruction to forward its contents to an external address. The model complies and calls the email tool.

The prompt guard saw a normal user request. The email tool saw a normal tool call. Nothing in the path checked whether this agent, in this session, was allowed to send email to an external domain. The failure is not a jailbreak in the classic sense. It is a missing authorization check between the model and a side effect.

The same shape appears with database tools, file writes, and any tool that mutates state. The model does not need to be tricked into saying something harmful. It only needs to be tricked into calling a tool it was always allowed to call.

The mechanism that stops it

The control belongs at the tool boundary, not at the prompt. Concretely:

• Each tool declares the permissions it requires. The email tool requires a send scope and a recipient domain scope.
• The agent is issued a policy that names which tools it may call and under which constraints. The policy is evaluated per invocation, not per session.
• The arguments are part of the decision. Sending to an internal domain and sending to an external domain are different decisions.
• The decision is logged before the tool executes, with the agent identity, the tool name, the arguments, and the outcome.

This is least privilege applied to agents. It does not depend on the model behaving well. It depends on the policy being enforced where the side effect happens.

Monitoring follows from the same log. You are not looking for bad text. You are looking for authorization decisions that fall outside the expected pattern: a tool called by an agent that never called it before, an argument outside the declared scope, a burst of denials followed by a success.

Implementation with RESK

RESK provides two pieces for this.

reskSecure enforces least privilege on agents. You declare the tools and the scopes they require, bind them to an agent policy, and the policy is evaluated at the tool boundary. The decision is made against the agent identity and the call arguments, so an over-permissioned tool does not silently inherit session trust.

ReskPoints records the authorization decisions. Each point captures the agent, the tool, the arguments, and the outcome, so the monitoring signal is the decision log rather than the model output. You can query it to answer which agent called which tool, and which calls were denied.

Together they cover the two properties from earlier: authorization at execution, and a log that reconstructs it.

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

For the tool permission model in more depth, see the related article on AI agent tool permissions: https://resk.fr/blog/ai-agent-tool-permissions.html

Checklist

• Every tool declares the scopes it requires.
• Every agent has a policy naming the tools it may call and the argument constraints.
• Authorization is evaluated per invocation, not per session.
• Arguments are part of the decision, not just the tool name.
• The decision is logged before the tool executes.
• Monitoring watches authorization decisions, not only model output.
• Denials and out-of-pattern calls are reviewed.

If you cannot answer which agent called which tool with which arguments, the control is not in place yet.