Best practices for implementing LLM access controls and monitoring

Why prompt-level controls are not access controls

When an LLM calls a tool, the model is not the actor. The model produces a structured request. The agent runtime resolves that request into a concrete operation and executes it against a backend. The authorization question is not what the model said. It is whether this agent, on behalf of this user, in this session, should be allowed to perform this operation.

That question cannot be answered inside the prompt. A system prompt that says do not delete production data is a suggestion to a probabilistic component. An access control is a deterministic decision made by code that the model cannot talk its way past.

This article covers the specific question of how to implement access controls and monitoring for LLM-backed agents. It assumes you already run agents with tool access and you need to put a boundary around them.

The attack surface, concretely

An agent with tools has three surfaces that matter for access control.

Tool invocation. Every tool the agent can call is an entry point. If the tool set is broad and the credentials behind it are broad, a single malformed or manipulated tool call can reach operations the user never intended. The risk is not that the model is malicious. The risk is that the model is steerable by content it reads, and the tool layer trusts the model output.

Credential scope. Agent runtimes commonly execute tool calls with a service credential, not the end user credential. That is convenient and it collapses the permission model. The backend sees one identity for every user, so per-user authorization is lost at the exact point where it matters.

Action ordering. A tool call is often a sequence: resolve, validate, execute. If validation happens after execution, or if the log is written after the side effect, you have monitoring that describes damage rather than preventing it. Ordering is a security property.

None of this is theoretical. It is the normal shape of an agent integration built for speed. The controls below are how you change that shape.

The mechanism that stops it

Access control for agents works when three things are true at the tool boundary.

1. The caller is identified. The runtime must know which user and which agent session originated the tool call, and it must pass that identity to the policy decision. An anonymous service identity is not a caller.

2. The credential is scoped to the operation. Instead of one broad service credential, the tool call receives a credential limited to the specific operation and resource. Least privilege is enforced by what the credential can do, not by what the prompt asks.

3. The decision is logged before execution. The policy decision, the caller, the tool, and the target are recorded before the side effect happens. If the decision is deny, execution does not occur. Monitoring then reflects intent and outcome, not just aftermath.

Put together, this is a policy enforcement point at the tool boundary. The model proposes. The boundary decides. The backend executes only what was allowed.

A concrete failure mode

Consider an agent that summarizes documents and has a tool to fetch a document by identifier. The tool executes with a service credential that can read every document in the store. A user asks the agent to summarize a document they own. The agent, following content in a retrieved document, calls the fetch tool with an identifier belonging to another user. The backend returns it, because the service credential is allowed. The summary is produced and returned to the first user.

No exploit code was written. No credential was stolen. The access control was absent at the only place it could have helped: the tool boundary. The fix is not a better prompt. The fix is that the fetch tool receives a credential scoped to the requesting user, and the policy decision is evaluated and logged before the fetch executes.

Monitoring that is worth the name

Monitoring for agents should capture the decision, not only the request. At minimum, log the caller identity, the agent session, the tool name, the target resource, the policy outcome, and a timestamp, in that order relative to execution. Alert on denies and on scope changes. A deny is a signal that something tried to cross a boundary. A scope change is a signal that the boundary moved.

Implementation with RESK

RESK provides two pieces for this.

reskSecure is where the policy enforcement lives. It gives you the control point at the tool boundary so that agent tool calls are authorized against the caller and the operation before execution, with least privilege enforced on the credential rather than requested in the prompt. You can read more at https://resk.fr/projects/resksecure.html.

ReskPoints covers the monitoring side, so that decisions and their outcomes are recorded and reviewable. Together they let you answer two questions after the fact: what was allowed, and what was attempted and denied.

For the related topic of how tool permissions are modeled, see the article on AI agent tool permissions at /blog/ai-agent-tool-permissions.html.

Checklist

• Identify the caller at the tool boundary, not only at the API edge.
• Scope every tool credential to the operation and resource it needs.
• Evaluate the policy decision before the side effect, never after.
• Log caller, session, tool, target, and outcome for every decision.
• Alert on denies and on credential scope changes.
• Treat the prompt as untrusted input to the tool layer, not as a control.
• Review the tool set regularly and remove tools the agent does not need.

The model will keep being steerable. The boundary is what makes that survivable.