Access control for LLM agents is usually discussed as a prompt problem. It is an architecture problem. The question is not what you tell the model to avoid. The question is where in the request path a decision gets made, and what happens when that decision is no.
This article covers the mechanism, a concrete failure mode, and the mitigation, with a short implementation section for RESK.
What is AI agent security?
AI agent security is the set of controls that govern what an autonomous or semi-autonomous agent can do with the credentials and tools it holds. It covers identity, tool permissions, scope of each call, and the monitoring record that proves what happened. It is distinct from model safety, which concerns what the model outputs. Agent security concerns what the system executes.
Best practices for implementing LLM access controls and monitoring
The specific question is where the control belongs. The answer is: on the request path, between the agent and the tool, before execution.
A control inside the system prompt is advisory. A control in a gateway that sits in front of the tool is enforcement. If the policy check runs after the tool has executed, you have built an audit log of a breach, not a prevention layer.
The ordering that matters is:
- Authenticate the agent identity.
- Resolve the permission for the specific tool being called.
- Evaluate the requested scope against least privilege.
- Allow or deny the call.
- Record the decision with identity, tool, requested scope and granted scope.
Skipping any step leaves a path that an injected instruction can walk.
Attack surface, concretely
An agent typically holds a token or a set of credentials. If that token carries more rights than the current task needs, the blast radius of any mistake equals the token scope, not the task scope.
Consider a failure mode that is not theoretical. An agent is asked to summarize a document. The document contains an instruction to call a write tool. The agent has a token that permits writes because it was provisioned broadly at setup. The model follows the instruction. The write executes. Nothing in the path checked whether a summarization task should ever reach a write tool.
The failure is not that the model was fooled. The failure is that the architecture had no point where the task scope and the token scope were compared. Monitoring alone would have recorded the call after the fact. Prevention requires the check before execution.
The mechanism that stops it
The mechanism is a policy enforcement point on the request path. Every tool call passes through it. The point holds three pieces of state: the agent identity, the tool permission set, and the scope required by the current task. It compares them and returns allow or deny before the tool runs.
Two properties make this work. First, the decision is outside the model, so an injected instruction cannot argue with it. Second, the decision is recorded, so a denied call is visible rather than silent. A denial that leaves no trace is indistinguishable from a call that never happened.
Monitoring closes the loop. Log the agent identity, the tool, the scope requested, the scope granted and the outcome. That record is what lets you answer whether a control is working.
Implementation with RESK
reskSecure provides the enforcement point for agent tool permissions. It sits between the agent and the tool call and evaluates least privilege before execution, so the check is architectural rather than advisory.
ReskPoints provides the monitoring record. Every decision is logged with the identity, the tool and the scope involved, so denials and grants are both visible.
For the permission model in more depth, see the related article on AI agent tool permissions: /blog/ai-agent-tool-permissions.html
To enforce least privilege on your agents, start here: https://resk.fr/projects/resksecure.html
Checklist
- The policy check runs before the tool executes, not after.
- Agent identity is authenticated on every call.
- Tool permissions are resolved per tool, not per agent session.
- Requested scope is compared against least privilege for the current task.
- Denials are logged with identity, tool and scope.
- Grants are logged with the same fields.
- The token scope is no broader than the task scope.
- Monitoring can distinguish a denied call from a call that never happened.
Top comments (0)