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

The question engineers actually ask

Search demand for best practices around LLM access controls and monitoring is steady, and the question behind it is narrow. An engineer has an agent that calls tools. They want to know what to put in front of those calls, and what to watch afterwards. This article answers that question from the request path outward. It does not claim measured results. It describes the mechanism and the failure modes that follow from getting the ordering wrong.

What AI agent security is

AI agent security is the discipline of constraining what an autonomous or semi-autonomous model-driven process is permitted to do to systems outside itself. The model produces intent in the form of tool calls. The security problem is that intent is untrusted input. Everything the agent can reach, a crafted input may try to reach through it.

That reframes access control. You are not filtering text. You are deciding, per call, whether this agent, holding these grants, may invoke this tool with these arguments, right now.

The specific question: where does the check go

A tool call passes through a sequence. The model emits a structured request naming a tool and arguments. A runtime receives it. The runtime resolves the agent identity, looks up granted scopes, evaluates the request against policy, and either executes the tool or refuses.

The control belongs between resolution and execution. Not in the system prompt, not in a post-processing step on the model output, not in a log pipeline that runs after the side effect.

Three properties follow from that placement:

1. It is enforced, not suggested. A prompt instruction is context the model may follow. A policy evaluation before execution is a gate the call cannot pass.
2. It fails closed. If identity resolution or policy lookup errors, the call is denied. A default-allow fallback turns an outage into an incident.
3. It is auditable at the decision point. The record of allow or deny is written where the decision was made, with the agent identity, the tool, and the arguments that were evaluated.

Attack surface, concretely

Consider an agent granted a broad service credential because the first task needed it. The task changes. The credential does not. The agent now holds scopes nothing in its current role requires, and no log line shows the excess because nothing failed.

The second surface is argument-level. A tool that is safe for one resource is not safe for another. A policy that checks only the tool name and not the target argument permits calls the tool was never meant to serve.

The third is the ordering failure itself. If the check runs after execution, a denied call has already produced its side effect. The denial is recorded, the damage is done.

None of this requires a novel exploit. It requires an agent with more permission than its task, and a check in the wrong place.

The mechanism that stops it

The mitigation is least privilege applied to agents, enforced at the decision point, with monitoring attached to the same event.

• Scope per agent, not per service. Each agent gets the narrowest set of tool permissions its task requires. Broad shared credentials defeat the model.
• Evaluate tool and arguments together. Policy sees the target, not just the verb.
• Fail closed on evaluation error. Deny is the default when the decision cannot be made.
• Emit a decision record per call. Allow and deny both produce an event carrying agent identity, tool, arguments, and outcome. Monitoring reads that stream rather than reconstructing intent from application logs.
• Review grants on task change. A permission set that outlives its task is the quiet failure mode.

Monitoring without enforcement tells you what happened. Enforcement without monitoring leaves you unable to see drift. You need both on the same event.

Implementation with RESK

RESK builds this into the agent path rather than bolting it on.

reskSecure is where agent permissions are defined and enforced. You express what an agent may call, and the check sits in the request path before execution, failing closed when a decision cannot be reached. This is the least-privilege layer for agent tool access.

ReskPoints is the monitoring side. Decision events from the enforcement point feed a view of what agents are actually doing, so excess scope and denied calls are visible rather than inferred.

For the permission model itself, the companion article on AI agent tool permissions covers how to structure grants. This piece covers where the check runs and what it emits.

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

Checklist

• [ ] Every tool call passes a policy evaluation before execution.
• [ ] The evaluation sees the target argument, not only the tool name.
• [ ] Evaluation errors deny the call. No default allow.
• [ ] Each agent holds the narrowest scope its current task needs.
• [ ] Grants are reviewed when an agent task changes.
• [ ] Every allow and deny emits a decision record with agent identity, tool, arguments, and outcome.
• [ ] Monitoring reads the decision stream, not reconstructed application logs.
• [ ] Excess scope is treated as a finding even when nothing failed.