Implementing LLM access controls and monitoring: where the check belongs

The question engineers actually ask

Search traffic for LLM access controls and monitoring is mostly implementation intent. The people arriving are not asking what an agent is. They are asking where the check goes, what it checks, and what gets logged. This article answers that in order: the concept, the concrete attack surface, the mechanism that stops it, and the implementation steps with RESK.

1. What is AI agent security?

AI agent security is the discipline of constraining what an autonomous or semi-autonomous LLM system can do with the tools, data and credentials it has been given. It differs from classic application security in one important way: the set of actions is not fixed at build time. A model chooses tool calls at runtime based on context that an attacker can influence through retrieved documents, tool output, or user input.

That means the security boundary cannot be the prompt. A prompt is input to the model, not a gate in front of the tool. The boundary has to sit between the model decision and the effect.

2. Best practices for implementing LLM access controls and monitoring

The specific question is how to implement controls and monitoring. The answer starts with ordering.

1. Identify the agent, not just the user. Every tool call should carry the identity of the agent making it, so permissions can be scoped per agent rather than per model endpoint.
2. Authorize before execution. The check must run on the requested tool and its arguments before the tool runs. A check after the fact is monitoring, not access control.
3. Scope narrowly. Grant each agent only the tools and data ranges it needs for its task. Broad grants turn a single injected instruction into a wide blast radius.
4. Log the decision with the call. Record what was requested, what was allowed or denied, and why. A log that only records successful calls cannot show you attempted abuse.
5. Monitor the denials, not only the successes. Denied calls are the signal that something is probing the boundary.

These are the practices. The rest of this article is about where they live in the request path.

3. Attack surface, concretely

Consider an agent with two tools: a document reader and a ticket writer. A retrieved document contains an instruction to read a sensitive record and open a ticket containing its contents. Nothing in the user request asked for that. The model, following the injected instruction, calls the reader, then calls the writer.

If the only control is a system prompt telling the model not to do this, the outcome depends on the model resisting the injection. That is not a control you can test or enforce. If the only control is post-hoc logging, you learn about the exfiltration after the ticket exists.

The failure mode is not exotic. It is a chained tool call where the second call is authorized only because the first one succeeded. The attack surface is the ordering between tool calls, and the fact that each call is evaluated in isolation.

4. The mechanism that stops it

The mechanism is enforcement at the tool call boundary, before execution, against the agent identity and the requested scope.

Concretely, the request path becomes: model proposes a tool call, the call is intercepted, the agent identity and requested tool and arguments are evaluated against policy, and only then does the tool execute or the call get denied. The decision is logged with the call.

This stops the chained-call failure because the second call is evaluated on its own merits, not on the success of the first. If the writer tool is not in the agent scope for that data range, the call is denied regardless of what the model decided.

Monitoring complements this by recording denials as first-class events. The boundary enforces. The log tells you what the boundary saw.

5. Implementation with RESK

RESK provides two pieces for this.

reskSecure is the enforcement layer. It sits at the tool call boundary and evaluates each call against the agent identity and scope before execution, so least privilege is enforced rather than suggested. The policy decision is attached to the call and logged.

ReskPoints are the instrumentation points where agent activity is observed. They give you the visibility needed to monitor denials and trace chained calls, so the enforcement layer and the monitoring layer describe the same events.

For the permission model that underpins this, see the related article on AI agent tool permissions at /blog/ai-agent-tool-permissions.html. The short version: permissions belong to the agent, and the check belongs at the call.

6. Checklist

• Every tool call carries an agent identity.
• Authorization runs before tool execution, not after.
• Each agent has the narrowest tool and data scope it needs.
• Denied calls are logged as events, not dropped.
• Chained calls are evaluated individually, not inherited from prior success.
• Monitoring reads the same decision log that enforcement writes.

If you are implementing this now, start with the boundary: enforce least privilege on your agents at https://resk.fr/projects/resksecure.html.