The question

Engineers searching for best practices on LLM access controls usually want one thing: a concrete answer to how an agent should be allowed to touch real systems. This article explains the mechanism, the failure mode it prevents, and the order in which the controls must be applied.

What AI agent security means

AI agent security is the discipline of constraining what an autonomous or semi-autonomous LLM system can do with the credentials it holds. It is not prompt safety and it is not model alignment. It is the same problem as any other delegated access problem: a principal acts on behalf of another principal, and the system must ensure the action stays within the delegation.

An agent is a confused deputy when it holds permissions broader than the task requires and can be induced to exercise them. The model does not need to be malicious. It only needs to be persuadable by text it processes.

The attack surface, concretely

Consider an agent that reads issues, summarizes them, and can open pull requests. It holds a token with write access to the repository. An attacker files an issue whose body contains instructions. The agent reads the issue as part of its task, follows the instructions, and opens a pull request that changes a workflow file. No exploit was written. The agent used its own legitimate token.

The same shape appears wherever an agent has a tool. A database tool with a broad role can be asked to read a table outside the task. A shell tool can be asked to run a command the operator never intended. A cloud tool can be asked to change a policy.

The common property is that the tool call is authorized by the agent identity alone. If the token can do it, the agent can be made to do it.

The mechanism that stops it

Three controls, applied in this order, close the gap.

1. Distinct identity per agent. The agent authenticates as its own principal. It does not reuse a human token and it does not share a service account with other agents. This makes revocation possible and makes logs attributable.

2. Per-call authorization against a task-scoped policy. Every tool invocation is evaluated before execution. The policy answers a narrower question than whether the agent may use the tool: it asks whether this specific action, with these arguments, is within the scope of the current task. A repository agent may open a pull request but not modify a workflow file. A database agent may read the orders table but not the users table.

3. Decision logging with inputs. The authorization decision is recorded together with the arguments that produced it. A denied call and an allowed call are both auditable. Without this, monitoring is guesswork.

The placement matters as much as the controls. Authorization must sit in the request path between the model output and the tool execution, not inside the prompt. A rule written in a system prompt is a suggestion to the model. A rule enforced by the executor is a control.

A concrete failure mode

A common mistake is to scope the tool rather than the call. The agent is given a database tool and the tool is given a read-only role. The team considers the problem solved. Then the agent is asked, through injected text, to read a table that the read-only role can access but the task does not require. The call succeeds because the role was broad enough. The failure is not a privilege escalation in the classic sense. It is a scope violation that the policy never checked.

Monitoring alone does not catch this reliably. The call looks like every other read. It is only visible if the decision was evaluated against task scope and logged with its arguments.

Implementation with RESK

RESK provides two components for this.

reskSecure enforces least privilege on agents. It places the authorization decision in the request path and evaluates each tool call against a policy scoped to the task, so a broad credential cannot be exercised outside its intended use. See the project page for the current API surface: https://resk.fr/projects/resksecure.html

ReskPoints provides the decision logging layer, so allowed and denied calls are recorded with the inputs that produced them.

For the related topic of how tool permissions are modeled per agent, see the companion article on AI agent tool permissions.

Checklist

  • The agent authenticates as a distinct principal, not as a human or a shared account.
  • Every tool call is authorized before execution, not inside the prompt.
  • The policy is scoped to the task, not only to the agent identity.
  • Arguments are part of the authorization decision.
  • Allowed and denied decisions are logged with their inputs.
  • Credentials are revocable per agent.
  • The control sits between model output and tool execution.