LLM access controls and monitoring: an implementation guide for AI agents

Why API keys are not access control

Most teams secure an LLM agent the same way they secure a service: issue an API key, scope it to a provider, rotate it. That protects the model endpoint. It does not protect what the agent does with the tools you gave it.

An agent is a loop. It reads a prompt, decides on an action, calls a tool, reads the result, and decides again. The API key authorizes the loop to exist. It says nothing about whether this particular tool call, with these particular arguments, should run.

That gap is the subject of this article. The question is concrete: what does it take to implement access controls and monitoring for an LLM agent so that a bad decision does not become a bad action?

The attack surface, concretely

Three failure modes matter in practice.

Prompt injection into a tool call. Text the agent reads, from a document, a web page, or a tool result, contains instructions. The agent follows them and calls a tool it was never meant to call in that context. The API key is valid. The call succeeds.

Over-broad tool grants. The agent is given a tool because one workflow needs it. Every other workflow now has it too. There is no per-action scope, so the blast radius of any single bad decision is the union of every tool the agent holds.

No record of what happened. The agent runs, the tool call succeeds, and nothing logs which agent made the call, with which arguments, under which decision. When something goes wrong you cannot reconstruct the sequence.

None of these require a sophisticated attacker. They require an agent with tools and an input the agent does not fully control.

The mechanism that stops it

The control belongs in the request path, between the agent decision and the tool execution. Not in the prompt. Not in a post-hoc log review.

The ordering is the mechanism:

1. The agent proposes a tool call with arguments.
2. A policy check evaluates the agent identity, the tool, and the arguments against an explicit grant.
3. If the check denies, the call does not execute and the denial is recorded.
4. If the check allows, the call executes and the decision is recorded with the same fields.

Two properties follow. First, deny by default: a tool call with no matching grant is refused, not allowed. Second, every decision is logged before execution, so the record exists whether the call succeeds or fails.

This is least privilege applied at the action level rather than the credential level. The agent holds only the grants it needs for the current task, and each call is checked against them.

For a deeper treatment of how tool permissions are scoped, see AI agent tool permissions.

A concrete failure mode

Consider an agent that summarizes documents and has a tool to fetch a URL. A document contains text instructing the agent to fetch an internal address. The agent complies. The fetch tool has network access. The API key is valid. Nothing in the path checks whether this agent, in this task, should be fetching that address.

With an action-level check, the fetch is evaluated against the grant for this agent and this task. The internal address is outside the grant. The call is denied and the denial is logged with the agent identity, the tool, and the requested address. The agent receives a denial and can continue or stop. The action never happens.

Implementing with RESK

RESK provides the policy check and the decision record as part of the agent runtime.

reskSecure enforces least privilege on agent actions. Grants are explicit per agent and per tool, and the policy check runs before execution. A call without a matching grant is denied by default.

ReskPoints records the decisions. Each entry carries the agent identity, the tool, the arguments, and the allow or deny outcome, so the sequence is reconstructable after the fact.

Implementation follows the ordering above. Define the grants for each agent and task. Route tool calls through the reskSecure check. Send the decision to ReskPoints. Start with deny by default and add grants as workflows require them.

Enforce least privilege on your agents: reskSecure.

Checklist

• [ ] Tool calls are checked before execution, not after.
• [ ] The check evaluates agent identity, tool, and arguments.
• [ ] Default is deny; grants are explicit and per task.
• [ ] Every decision is logged with the same fields, allow or deny.
• [ ] Denials are visible to the agent so it can stop or recover.
• [ ] Grants are reviewed as workflows change, not set once.