LLM access controls and monitoring: why the tool boundary decides your security posture

Access control for LLM systems is often discussed as a prompt problem. It is not. The prompt is an input to a model that has no security boundary of its own. The boundary lives in the code that decides which tools the model may call and with what scope.

This article covers what AI agent security means in practice, the specific question of how to implement LLM access controls and monitoring, the concrete attack surface, the mechanism that stops it, and a checklist you can apply to an existing agent.

What is AI agent security?

AI agent security is the discipline of constraining what an agent can do, not just what it can say. An agent is a model plus a set of tools plus a loop. The loop lets the model choose a tool, observe the result, and choose again. Each tool is a capability: read a file, query a database, call an internal API, send a message.

Security therefore has two halves. The first is authorization: which capabilities may this caller reach through this agent. The second is observability: can you reconstruct, after the fact, which capability was invoked, under which scope, and with what outcome. Neither half is provided by the model.

Best practices for implementing LLM access controls and monitoring

The question most teams actually ask is narrower: where do I put the control, and what do I log. The answer follows from the request path.

A tool call has a fixed order of operations. The caller is identified. The agent is resolved. The tool is selected. The tool executes. The result returns to the model. Access control belongs before execution, on the tool selection step. Monitoring belongs on the same step, so that a refusal and a success are recorded by the same code path.

If you check scope after the model has already selected a tool, the selection was made by the component you are trying to constrain. That is the ordering mistake to avoid. Identity and scope must be resolved first; the model call happens inside that resolved scope.

A second practice is to treat each tool as its own permission, not the agent as a whole. An agent that can read and write should not grant write because it was granted read. Scope belongs to the tool invocation.

A third practice is to log per call rather than per conversation. A conversation level log tells you the agent was used. A call level log tells you which tool ran, under which scope, and whether it was refused.

Attack surface, concretely

The attack surface is the set of tools the agent can reach and the scope each one carries. A retrieval tool that can read the whole index gives the model the whole index. A database tool with a broad credential gives the model that credential. Prompt instructions do not shrink either scope.

The failure mode is not exotic. An agent is given a tool for convenience during development. The tool holds a service credential. The agent is later exposed to untrusted input. Nothing in the prompt prevents the model from selecting that tool, because the prompt is not an enforcement point. The credential was always reachable; the exposure simply made it reachable by an attacker.

This is why access control cannot be delegated to instructions. The model does not have a reliable notion of what it is not allowed to do. The surrounding code does.

The mechanism that stops it

The mechanism is least privilege enforced at the tool boundary, with identity resolved before the model call. Concretely:

1. Resolve the caller identity and the agent identity.
2. Compute the set of tools and scopes available to that pair.
3. Pass only that set to the model.
4. On each tool selection, re-check the scope against the resolved set.
5. Execute only if the check passes, and record the decision.

Step three matters as much as step four. A model that never sees a tool cannot select it. A model that sees a tool but is refused at execution is still spending tokens on an action that will fail. Narrowing the visible tool set reduces both risk and noise.

Step five is where monitoring lives. The record should contain the tool name, the resolved scope, the decision, and the outcome. With that record you can distinguish a refused action from an action that never occurred, which is the difference between a blocked attack and an unmonitored gap.

Implementation with RESK

reskSecure is the enforcement layer for agent tool permissions. It sits on the tool selection step described above, resolves identity and scope, and decides whether a tool invocation proceeds. The permission model is per tool, so an agent granted read does not inherit write.

ReskPoints provides the monitoring side. It records tool invocations with their resolved scope and outcome, so that refusals and successes are visible on the same timeline. Together they cover the two halves of the problem: authorization before execution, and a per call record after it.

For the permission model in more depth, see the companion article on AI agent tool permissions at /blog/ai-agent-tool-permissions.html.

To enforce least privilege on your agents, start at https://resk.fr/projects/resksecure.html.

Checklist

• Identity and scope are resolved before the model call, not after tool selection.
• Each tool carries its own permission; no agent level blanket grant.
• The model receives only the tools and scopes available to the resolved caller.
• Every tool selection is re-checked against the resolved scope before execution.
• Tool invocations are logged per call with tool name, scope, decision and outcome.
• Refusals are recorded, so a blocked action is distinguishable from a missing one.
• Development convenience tools are removed or scoped down before exposure to untrusted input.

Access control for LLM systems is an ordering problem and a logging problem. Get the order right, log the decision, and the prompt stops being load bearing for security.