Best practices for implementing LLM access controls and monitoring

The question

Engineers ask a specific question about LLM access controls: where does the control belong, and what does it actually check? This article answers that. It assumes you already run agents that call tools, and that you already know what a prompt injection is.

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 authority it holds. It is not model alignment. It is not content filtering. It is the same problem as any other privileged workload: identity, scope, and audit.

The difference is that an agent decides its own next action. A traditional service calls a fixed set of endpoints. An agent chooses which tool to call based on text it just read, and that text can come from a user, a document, a web page, or another agent.

The attack surface, concretely

Consider an agent with three tools: read a ticket, read a customer record, and send an email. The user asks it to summarize a ticket.

The ticket body contains text that looks like an instruction. The agent reads it as part of its task. It now has a plausible reason to call the customer record tool and the email tool.

Nothing was exploited in the classic sense. No credential was stolen. The agent used authority it already had. The failure is that the authority was granted for the session rather than for the call.

This is the core failure mode. Session wide authority plus untrusted input equals unintended tool use. It is not theoretical because untrusted input is the normal case for any agent that reads documents, tickets, or web content.

The mechanism that stops it

The control belongs in the request path, between the agent and the tool. Not in the prompt, not in the system message, not in a policy document.

Every tool invocation is evaluated against three things:

1. The caller identity. Which agent, on behalf of which user, in which session.
2. The tool scope. Which specific tool, with which parameters, against which resource.
3. The task context. What the agent was asked to do, and whether this call is consistent with it.

The decision is made per call. Authority is granted for one invocation and then discarded. A later call starts from zero.

This ordering matters. If you evaluate once at session start, the decision is made before the agent has read the input that will drive its behavior. If you evaluate per call, the decision is made with the full context of what the agent is about to do.

Monitoring is the second half. For every call, record the decision, the scope that was checked, and the outcome. A single denied call is noise. A pattern of denied calls from one agent, or one tool, or one user, is a signal worth acting on.

A concrete failure mode

An agent is asked to summarize a support ticket. The ticket contains injected text instructing the agent to forward the thread to an external address.

With session wide authority, the agent already holds the email tool. It calls it. The call succeeds. The audit log shows a successful send by a legitimate agent.

With per call evaluation, the email call is checked against the task context. The task was summarize, not send. The call is denied. The denial is logged with the agent identity, the tool, and the reason.

The difference is not the model. It is where the control sits and how often it runs.

Implementation with RESK

reskSecure enforces least privilege on agents by evaluating tool calls in the request path. Each call is checked against identity, scope, and task context before it reaches the tool. Authority is not carried across calls.

ReskPoints provides the monitoring layer. It records each decision and outcome so you can see denied calls, repeated attempts, and unusual tool usage per agent. The two together give you enforcement and visibility on the same path.

Start by inventorying the tools your agents can call. Then define scope per tool. Then route calls through reskSecure and read the ReskPoints data for the first week before you tighten anything.

Checklist

• List every tool your agents can call.
• Define the minimum scope each tool needs.
• Move the authorization decision into the request path.
• Evaluate per call, not per session.
• Include caller identity, tool scope, and task context in the check.
• Log every decision and outcome.
• Review denied calls weekly.
• Treat repeated denials from one agent as an incident.
• Re check scope when a tool gains new parameters.

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

For the related topic of tool level permissions, see the article on AI agent tool permissions.