Where LLM access control belongs in the request path

Access control for LLM agents fails in a predictable place: the request path is built so that the model is trusted to enforce its own limits. This article is about moving the control to where it can actually hold.

What AI agent security means here

AI agent security is the discipline of constraining what an agent can do when its instructions are influenced by untrusted input. The model is not a security boundary. It reads text, including text an attacker may control, and it produces actions. Any policy that lives only in the prompt is a suggestion to the same component that an attacker is trying to steer.

The question: best practices for LLM access controls and monitoring

The practical question is not whether to log agent activity. It is where the decision to allow or deny a tool call is made, and what identity that decision is based on. Best practice is to make that decision outside the model, in front of the tool, using a scoped identity for the agent and a policy that denies by default.

Attack surface, concretely

Consider an agent that holds a long lived API token with broad scope and can call a ticketing tool, a code repository tool, and an internal search tool. A user submits content that contains an instruction to move data from search into a ticket. The model, following the injected instruction, calls the tools it already has credentials for. Nothing in the model refused, because nothing in the model was a control.

The failure mode is the confused deputy: the agent has authority, and the attacker supplies the intent. It is not theoretical because the token is real, the tools are real, and the model has no reliable way to distinguish operator intent from injected text.

The mechanism that stops it

The control belongs in front of the tool call, in the request path between the agent runtime and the tool. The ordering matters:

1. Authenticate the agent as a distinct identity, not as a shared service account.
2. Resolve the declared scope for this task, which should be narrower than the agent total permissions.
3. Evaluate the specific action against policy before the tool is reached.
4. Issue a short lived credential scoped to that one action.
5. Record the decision with the agent identity, the action, and the outcome.

Deny by default. If the policy has no rule for an action, the action does not run. Monitoring then becomes meaningful because every allow and every deny is attached to an identity and an action, not to a vague session.

This is also why tool permissions deserve their own model. See the related article on AI agent tool permissions for how per tool scopes are structured.

Implementation with RESK

reskSecure is the enforcement point for agent identities and tool calls. It sits in front of the tool so the policy check happens before the action, and it issues scoped credentials per call rather than handing the agent a standing token.

ReskPoints provides the decision and event record: each allow or deny is tied to the agent identity and the requested action, so monitoring reflects what was actually enforced rather than what the model said it would do.

Start by inventorying the tools your agents can reach, then declare per tool scopes, then move the check in front of the call. The goal is least privilege on your agents, enforced outside the model.

Checklist

• Each agent has its own identity, not a shared service account.
• Task scope is narrower than the agent total permissions.
• Policy is evaluated before the tool call, not inside the prompt.
• Credentials are short lived and scoped to one action.
• Default is deny when no rule matches.
• Every decision is logged with agent identity and action.
• Tool permissions are modeled per tool, not as one broad grant.