LLM access controls and monitoring: where the control belongs in the request path

What is AI agent security?

AI agent security is the discipline of constraining what an autonomous LLM-driven system can do with the credentials and tools it has been given. It is not model alignment. It is access control for a non-human principal that reads untrusted input and then acts.

An agent typically holds an API key, a set of tool definitions, and a loop that decides which tool to call next. That combination makes it a confused deputy: it has authority the input does not, and it can be persuaded to use that authority on behalf of whoever wrote the input.

Best practices for implementing LLM access controls and monitoring

The question is specific: how do you implement access controls and monitoring for LLM agents? The architectural answer is that the control belongs in the request path, between the agent and the tool, not in the prompt and not in the model.

Three properties follow from that placement.

1. It sees every call. If the control is a wrapper the agent must choose to use, it is advisory. If it is the only route to the tool, it is enforcement.
2. It sees the arguments. Authorizing a tool name is not enough. The dangerous call is usually a permitted tool with attacker-chosen arguments.
3. It decides before execution. Logging after the fact produces an audit trail of damage, not a control.

Monitoring is the second half. Every decision, allow or deny, should emit a structured record: agent identity, tool, arguments, policy verdict, and timestamp. That record is what lets you answer what happened and why, and it is what lets you tighten policy without guessing.

Attack surface, concretely

Consider an agent with a read_file tool and a send_email tool. A document it reads contains an instruction to send the contents of a configuration file to an external address. The model has not been jailbroken. It is doing what the text says, using tools it is already allowed to call.

The failure is not in the model. It is in the absence of a policy that says this agent may call send_email only to internal domains, or that read_file may not touch paths outside a declared root. Without that policy, the tool permission is the vulnerability.

This is not theoretical. Any agent that combines untrusted input with a write-capable tool has this shape.

The mechanism that stops it

The mechanism is a policy enforcement point in the request path. The agent does not call the tool directly. It calls the enforcement point, which:

• authenticates the agent as a distinct principal,
• evaluates the requested tool and its arguments against a policy,
• allows, denies, or requires approval,
• emits a decision record,
• and only then forwards the call to the tool.

The ordering is the control. Authentication before authorization, authorization before execution, logging as part of the decision rather than after it.

This is the same least-privilege model applied to a new principal type. The agent gets the minimum tool set and the minimum argument scope it needs for its task, and nothing more.

Implementation with RESK

RESK provides two pieces for this architecture.

reskSecure is the enforcement layer. It sits between the agent and its tools and evaluates each call against policy before execution. You define which agents may call which tools, under which argument constraints, and reskSecure returns a verdict. Denied calls do not reach the tool.

ReskPoints provides the decision records. Each policy evaluation is emitted as a structured event, so monitoring is a property of the enforcement path rather than a separate integration you have to keep in sync.

Together they give you the ordering described above: authenticate the agent, authorize the specific call, log the decision, then execute.

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

For the tool-permission model this builds on, see AI agent tool permissions.

Checklist

• [ ] Every agent is a distinct principal with its own credentials.
• [ ] Tool calls route through an enforcement point, not directly to tools.
• [ ] Policy evaluates arguments, not just tool names.
• [ ] Authorization happens before execution.
• [ ] Every decision emits a structured record with agent, tool, arguments, and verdict.
• [ ] Denied calls are visible in monitoring, not silent.
• [ ] Each agent holds the minimum tool set its task requires.