LLM access controls and monitoring: the attack path you are probably not logging

Most teams treat LLM access control as a prompt problem. They add a system prompt that says do not do X, they add a moderation layer on the input, and they call it done. The attacks that actually land rarely go through the prompt. They go through the permissions the agent already holds.

This article is about that path: what an agent security failure looks like concretely, why it is not theoretical, and where the control belongs so that it stops the call instead of describing it afterwards.

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, credentials and data it has been given. It is distinct from model safety, which is about what the model says. Agent security is about what the system executes.

An agent is a model plus a loop plus a set of tools. The model proposes an action, the runtime executes it, the result goes back into the context, and the loop continues. Every one of those tool calls is a real operation against a real system. That is the security boundary. Not the text the model produces, but the calls the runtime is willing to make on its behalf.

Best practices for implementing LLM access controls and monitoring: the specific question

The question engineers actually ask is narrower than the general topic. It is: where do I put the check, and what do I check?

There are three common answers, and only one of them holds under attack.

1. Check the user. Authenticate the human, issue a token, let the agent act with that token. This fails because the agent acts across many steps and many tools, and the human token was scoped for a human session, not for a chain of automated calls.
2. Check the prompt. Instruct the model to stay in scope. This fails because instructions are inputs, not enforcement. A model that is being helpful will use a tool it was told about.
3. Check the tool call. Evaluate each call against a policy before it executes. This is the only one that sits on the actual boundary.

Monitoring belongs alongside the third answer, not instead of it. Logs are necessary for detection and forensics, but a log line is written after the call has already happened. If your only control is monitoring, your incident response is a reading exercise.

Attack surface, concretely

Consider an agent with three tools: a document reader, a ticket creator, and a notification sender. The document reader is scoped to one folder. The ticket creator can write to one project. The notification sender can reach an external address.

Now consider a chain. Step one reads a document. Step two summarises it into a ticket. Step three notifies a channel. Each step is individually reasonable. The failure is in the composition.

A document placed in the readable folder contains text that steers the summarisation step toward including content the agent should not propagate. The ticket step writes it. The notification step sends it out. No single tool was abused. No credential was stolen. The model was not jailbroken. It was helpful, in order, with the scope it had.

This is why the attack is not theoretical. It does not require a novel exploit. It requires an agent that holds a permission broader than any single step needs, and a chain long enough for the composition to matter. Both are the default state of most agent deployments.

The same pattern applies to any tool that can read and any tool that can write. Read plus write plus a loop is an exfiltration path unless something breaks it.

The mechanism that stops it

The mechanism is per-call authorisation with least privilege, evaluated at the tool boundary.

Concretely, that means three properties.

First, the permission is attached to the call, not to the session. The agent does not carry a broad grant through the whole chain. Each tool invocation is evaluated against what that invocation is allowed to do, given the current step and the current data.

Second, the default is deny. A tool that has not been explicitly granted for this call does not execute. This inverts the usual model where the agent has a toolbox and the policy is a set of prohibitions.

Third, the decision is made before execution and recorded with the call. The policy check and the audit record are the same event, so what you monitor is what you enforced, not a separate stream you have to reconcile later.

This is the ordering that matters. Policy first, execution second, log as part of the decision. If the log is written by the tool after it ran, you have monitoring without control.

Implementation with RESK

RESK builds this into the request path rather than around it.

reskSecure enforces least privilege on agent tool calls. Each call is evaluated against policy before the tool executes, so a chain cannot compose its way into a permission that no single step was granted. The default is deny, and grants are scoped to the call.

ReskPoints provides the enforcement points where those decisions are applied, so the check sits on the boundary between the agent runtime and the tools it reaches for, not in a sidecar that observes traffic after the fact.

Together they give you the ordering described above: policy decision, then execution, then an audit record that reflects the decision that was actually enforced.

If you are currently relying on prompt instructions plus logs, the gap is the window between the call being proposed and the call being made. That window is where the control belongs.

Checklist

• Map every tool an agent can call, and the scope each one actually needs per step.
• Remove standing grants. Scope permissions to the call, not the session.
• Set the default to deny for any tool not explicitly granted for the current invocation.
• Evaluate policy before execution, not after.
• Make the audit record part of the policy decision so monitoring reflects enforcement.
• Treat read plus write plus a loop as an exfiltration path until proven otherwise.
• Review chains, not just individual tools. Composition is where the scope creep shows up.
• Test with a document that tries to steer the chain, and confirm the call is blocked rather than logged.

For the related question of how tool permissions are scoped in practice, see our article on AI agent tool permissions.

To enforce least privilege on your agents, start with reskSecure.