LLM access controls and monitoring: the attack path and the permission boundary that stops it

The question behind the query

Engineers searching for best practices on LLM access controls and monitoring usually already have an agent in production. The question is not what an agent is. It is what can go wrong when the agent holds credentials, and where the control belongs so that it does not.

This article answers that specific question. It frames the problem as an attack path, names the mechanism that breaks the path, and closes with a checklist you can apply to an existing integration.

What AI agent security covers

AI agent security is the discipline of constraining what an autonomous or semi-autonomous LLM system can do with the access it has been granted. It sits above model safety. Model safety asks whether the output is acceptable. Agent security asks whether the action the model triggers should have been possible at all.

That distinction matters because most agent incidents are not output problems. They are authorization problems. The model produced a syntactically valid tool call. The tool executed it. Nothing in the path asked whether this agent, at this moment, for this task, should have been able to make that call.

The attack surface, concretely

An agent connected to tools has at least four places where an attacker can influence what it does.

Untrusted input reaching the reasoning loop. Any text the agent processes can contain instructions: a retrieved document, a web page, an issue comment, an email body, a tool response. The model does not reliably separate data from instruction. If the input says to call a tool, the model may call it.

Tool descriptions and tool output. Tools are part of the context. A compromised or malicious tool can return content that redirects the agent, or a tool description can be written to encourage over-broad use.

The credential itself. This is the part that turns a bad decision into an incident. If the agent holds one token that can read the whole database, write to the repository, and call the internal admin API, then any successful injection inherits all of that scope. The blast radius is defined by the token, not by the prompt.

The monitoring gap. If the only record of an agent action is an application log line, nobody sees scope escalation in time. The call succeeds, the log is written, and the review happens after the damage.

None of this is theoretical. It is the ordinary shape of an integration built for convenience: one service account, one broad token, tools registered without per-tool scoping, and observability that records outcomes rather than authorization decisions.

The mechanism that stops it

The control that breaks the attack path is least privilege enforced outside the model, at the tool boundary.

Concretely, that means three properties.

1. Per-tool, per-task credentials. Each tool call uses a credential scoped to the minimum the task requires. The agent does not hold a token that spans tools. A retrieval tool gets read scope on one collection. A ticketing tool gets write scope on one queue. Nothing else.
2. Short expiry and explicit grant. Credentials are issued for the task and expire. A long-lived token is a standing permission; a task-scoped token is a decision that has to be made again for the next task.
3. Authorization decided before execution, and recorded. The check happens in the request path, before the tool runs, and the decision is logged with the identity, the tool, the requested scope, and the outcome. Monitoring then watches for escalation attempts rather than reconstructing them later.

The ordering is the point. If authorization is evaluated after the tool call, or inside the prompt, it is not a control. It is a suggestion.

This is also why prompt hardening alone does not close the gap. A better system prompt reduces the probability of a bad tool call. It does not change what the credential can do when the call happens. The permission boundary is the part that holds when the model is fooled.

Implementation with RESK

RESK builds the permission boundary as a separate layer from the model.

reskSecure enforces least privilege on agent tool access. Credentials are scoped per tool and per task, issued with an expiry, and checked before the tool executes. The authorization decision is recorded, so monitoring has a signal to act on: which agent, which tool, which scope, allowed or denied.

ReskPoints provides the control points where those decisions are enforced in the request path, so the check sits between the agent and the tool rather than inside the prompt.

You can read more about the enforcement model at https://resk.fr/projects/resksecure.html. For the related question of how tool permissions are scoped and reviewed, see the article on AI agent tool permissions at /blog/ai-agent-tool-permissions.html.

Checklist

• Inventory every tool the agent can call and the credential each one uses.
• Replace any shared, broad, long-lived token with per-tool, per-task scoped credentials.
• Set an expiry on every agent credential and require a fresh grant per task.
• Move the authorization check before tool execution, not after.
• Log the decision, not just the outcome: identity, tool, requested scope, allow or deny.
• Monitor for scope escalation and denied calls as first-class signals.
• Treat all retrieved content and tool output as untrusted input in the reasoning loop.
• Review tool descriptions as part of the attack surface, not just the documentation.

If you cannot answer which credential a given tool call used and what scope it carried, the control is not in place yet.