The question engineers actually ask
Search demand around LLM access controls is rarely about theory. It is about implementation. Where does the check go. What does it look at. What happens when it fails. This article answers that question directly, and stays inside what we can defend.
What is AI agent security
AI agent security is the discipline of constraining what an autonomous or semi autonomous system is allowed to do, and observing what it does. It is not prompt filtering. It is not model alignment. It is the same problem as any privileged workload: identity, permission, execution, audit.
An agent differs from a normal service in one important way. Its action space is chosen at runtime by a model, not fixed at deploy time by a developer. That single property is why traditional allowlists break down and why access control has to move closer to the call.
Attack surface, concretely
Consider an agent wired to a ticketing system, a code repository, and an internal search index. It holds one credential that can read and write all three.
Now consider a prompt injection arriving through a ticket body. The agent reads the ticket as part of its task. The injected text instructs it to open a pull request against a repository it was never supposed to touch. The agent complies.
The call succeeds. The credential is valid. The request looks like ordinary work. Your logs show a successful operation by a known identity. Nothing in the pipeline is designed to ask whether this particular agent should have been able to reach that repository at all.
This is not a hypothetical class of failure. It is the direct consequence of broad credentials plus runtime chosen actions. The blast radius is whatever the credential can reach, which is usually everything the integration was ever given.
A second failure mode is quieter. An agent accumulates permissions over time as teams unblock it. Nobody removes them. Six months later the credential is far wider than the task requires, and no single person knows the full extent.
The mechanism that stops it
The control belongs in the request path, between the agent and the tool it wants to call. Not in a policy document. Not in a periodic review. In the path, evaluated per call.
Three properties matter.
First, explicit permission. Each agent has a declared set of tools and operations it may invoke. A call outside that set is denied before execution, not logged after.
Second, least privilege by default. The starting state is empty. Permissions are added for a reason and scoped as narrowly as the task allows. Read on one resource is not read on the namespace.
Third, decision logging. Every allow and every deny is recorded with enough context to reconstruct what happened: which agent, which tool, which operation, which decision. A deny that nobody sees is only half a control.
Ordering matters here. If the check runs after the tool executes, you have an audit trail, not a control. The evaluation has to precede the side effect.
Implementation with RESK
reskSecure is where the enforcement lives. You declare what each agent may reach, and the check runs in the request path before the tool call executes. Denied calls do not fire. Allowed calls are recorded.
ReskPoints covers the observation side. It gives you the record of decisions so you can see what your agents attempted, what was permitted, and what was refused. That is the feedback loop that keeps permissions honest over time, because you can see when an agent is repeatedly hitting a boundary it should not be near.
The practical sequence is straightforward. Enumerate the tools each agent can currently reach. Cut that list to what the task requires. Route the calls through reskSecure so the check happens before execution. Watch ReskPoints for denials and near misses. Adjust from evidence, not from guesswork.
For the permission model itself, see our companion piece on AI agent tool permissions, which covers how to structure the grants that reskSecure enforces.
Checklist
- Every agent has an explicit, declared permission set.
- The default state is deny, not allow.
- Permissions are scoped to specific tools and operations, not namespaces.
- The permission check runs before the tool executes, never after.
- Every allow and deny is logged with agent, tool, operation, and decision.
- Denials are reviewed, not ignored.
- Permissions are removed when the task that needed them ends.
- One agent does not share a credential with another.
Enforce least privilege on your agents at reskSecure.
Top comments (0)