Most teams that ship an LLM agent start with a system prompt that says what the agent must not do. That is a good instruction. It is not an access control.
This article is about the difference, and about where in the request path the control has to sit for it to mean anything.
What ai agent security is
AI agent security is the discipline of constraining what an agent can do when it acts on the world, and of recording what it did. An agent is a model plus a loop plus a set of capabilities. The capabilities are the part that matters for security. A model that can only produce text is a content problem. A model that can call a tool, read a database or open a pull request is a system with a credential, and it has to be treated like any other principal.
The practical consequence: you cannot secure an agent by reasoning about the model alone. You secure it by reasoning about the identity it runs under, the actions it is allowed to take, and the resources those actions reach.
Best practices for implementing llm access controls and monitoring
The question is specific, so the answer should be too. The practices that hold up are the ones that survive a model that behaves unexpectedly.
Give the agent its own identity. Do not run an agent on a shared service account or on a human credential. An agent identity lets you scope permissions to the agent, revoke them without breaking a person, and attribute every action in the audit log.
Authorize per action, not per session. A session level grant means the agent can do everything for as long as the session lives. Check each tool call against the agent identity, the requested action and the target resource. The decision is made at call time, with the arguments in hand.
Default to deny. An allowlist of tools and resources is auditable. A denylist is a list of everything you thought of. The agent should reach only what it was explicitly granted.
Keep the policy outside the prompt. A rule in the system prompt is a suggestion to a probabilistic system. A rule in the request path is enforcement. If the only thing standing between an agent and a destructive tool is a sentence in the context window, you have no control, you have a hope.
Log the decision, not just the outcome. Record the authorization decision, the arguments, the agent identity and the result. A log that only records successful calls tells you what happened. A log that records refusals tells you what was attempted, which is what you need during an incident.
Order the check before execution. This sounds obvious and is routinely missed. If the policy check runs after the tool executes, you have an audit trail of damage rather than a prevention record.
Attack surface, concretely
The failure mode is not exotic. Consider an agent with a database credential that can read every table, because scoping it was deferred. A user asks a question that the agent decides to answer by querying a table it was never meant to touch. No exploit was written. No prompt injection was needed. The agent used a permission it had, in service of a plausible instruction.
A second case: an agent holds a token with write scope on a repository. It is asked to fix a failing check. It pushes a change. The change is wrong, or the branch protection was not what everyone assumed. The token did exactly what it was allowed to do.
A third: the agent is instructed through content it retrieves. A document it reads contains text that redirects its next tool call. If the tool call is authorized against a broad credential, the redirection succeeds. If it is authorized against a narrow grant, it fails at the policy check and the failure is logged.
In each case the model behaved as models do. The gap was in the permissions and in where the check happened.
The mechanism that stops it
The mechanism is least privilege enforced at the tool call boundary. Three parts.
First, a scoped identity per agent, with the minimum set of tools and resources it needs for its task.
Second, an authorization decision on every call, evaluated against that identity, the action and the resource, before the call executes. Deny by default. The decision is a record, not a side effect.
Third, monitoring built on those decisions. You watch for refusals, for calls outside the expected tool set, and for argument patterns that do not match the task. The audit log is the source, and it exists because the check ran first.
This is ordinary application security applied to a new kind of principal. The novelty is the principal, not the principle.
Implementation with RESK
reskSecure is where the policy lives. It enforces least privilege on your agents: each agent gets a scoped identity, and tool calls are authorized against that identity before they execute. The decision is recorded, so refusals and approvals are both visible.
ReskPoints covers the monitoring side. It gives you the visibility into agent activity that you need to notice a call outside the expected pattern, and to reconstruct what happened when something looks wrong.
Together they put the control in the request path and the evidence in one place. The related article on AI agent tool permissions goes deeper on how tool level grants are structured.
Checklist
- Every agent runs under its own identity, not a shared or human credential.
- Permissions are scoped to the tools and resources the task needs.
- Default is deny, with an explicit allowlist.
- Authorization runs on every tool call, before execution.
- The decision is logged with agent identity, action, resource and arguments.
- Refusals are monitored, not just successes.
- Policy lives in the request path, not only in the system prompt.
- Access is reviewed when the agent task changes, not only at deploy time.
Access control for agents is not a prompt engineering problem. It is a permissions problem, and it is solved where permissions are always solved: at the boundary, before the action, with a record of the decision.
Top comments (0)