Where LLM access controls belong in the agent request path

Most access control advice for LLM systems is written as if the model were the only thing running. It is not. Once an agent can call tools, the model is one component in a request path that ends in your infrastructure.

That changes where the control belongs.

What AI agent security covers

AI agent security is the practice of constraining what an agent can do, not just what it can say. A plain LLM has a read path: input goes in, text comes out. An agent has a write path: it selects a tool, supplies arguments, and something executes.

The write path is where the risk lives. The model does not need to be malicious for damage to occur. It needs to be wrong, or manipulated, or simply operating on a credential that is broader than the task requires.

The specific question: LLM access controls and monitoring

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

There are three candidate positions in the request path.

1. Before the model runs, by filtering the prompt. This is the weakest position. Prompt filtering is probabilistic and the model can be steered around it.
2. Inside the prompt, by instructing the model to behave. This is not a control. It is a suggestion.
3. After the model decides and before the tool executes. This is the only position where you have a concrete, inspectable artifact: a named tool and a set of arguments.

Position three is where authorization belongs. At that point you know the identity of the caller, the tool being requested, and the arguments. You can make a deterministic decision.

Monitoring follows the same logic. You do not log prompts and hope. You log decisions: which identity requested which tool with which arguments, and whether the request was allowed or denied.

Attack surface, concretely

Consider an agent that has been given a single credential with broad scope so it can complete a range of tasks. That credential is now the attack surface.

An injected instruction in a document the agent reads does not need to compromise your model. It only needs to cause one tool call. If the credential behind that tool can also reach other tools, the injected instruction reaches them too.

The failure mode is not theoretical and it is not subtle. The blast radius of a successful injection equals the scope of the credential the agent holds. Prompt-level defenses do not shrink that radius. Credential scope does.

A second failure mode is ordering. If the tool executes and the authorization check runs afterward, or runs asynchronously, the check is decorative. The side effect has already happened.

The mechanism that stops it

The mechanism is a policy decision point placed between the model and the tool runtime.

• The model emits a structured tool call.
• The policy decision point evaluates it against the caller identity, the tool name, and the arguments.
• If the decision is allow, the tool executes. If it is deny, the call is rejected and recorded.
• Every decision is logged with the identity, the tool, the arguments, and the outcome.

Two properties make this work. First, deny by default: a tool that has no explicit grant is not callable. Second, per-tool scoping: each credential grants exactly one tool and one action, so a compromised call cannot pivot.

This is the same shape as any authorization layer. The novelty is only the position in the path.

Implementation with RESK

reskSecure is the enforcement point for agent tool calls. It sits in the request path described above, evaluates each call against policy, and denies anything without an explicit grant.

ReskPoints covers the monitoring side. It records the decisions so you can answer the operational questions later: which agent called which tool, under which identity, and what the policy returned.

Together they give you the two halves of the problem. reskSecure decides. ReskPoints records.

For the tool-level permission model that this builds on, see the companion piece on AI agent tool permissions.

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

Checklist

• Place the authorization check after the model decides and before the tool executes.
• Deny by default. No explicit grant means no call.
• Scope each credential to one tool and one action.
• Reject and record denied calls rather than silently dropping them.
• Log the identity, tool, arguments, and outcome for every decision.
• Treat prompt-level instructions as guidance, never as a control.
• Re-check scope whenever a new tool is added to an agent.