How to keep AI agents within their permissions

Written by: Ido Shlomo Co-Founder and CTO of Token Security

AI agents should do more on their own. Who has the time or attention span to approve every command? And watching agents do the work they’re asked to do is mind-numbingly boring.

But agents do need boundaries, especially in corporate environments. Without a clear limit on what they can do, agentic flows tend to use all available access.

Here's a real-world example: A developer asks their agent to figure out why a nightly export job is failing. The team's rule for agents is simple: they work through read-only roles. But the developer also holds admin for on-call work, and both profiles sit in the same ~/.aws/config.

The agent hits AccessDenied when it tries to rerun the job, so it switches to the admin profile, assumes the role, and runs aws s3 rm against the production bucket to clear out the half-written export first.

The credential is valid. The developer may assume admin privileges, and the admin can delete S3 objects. AWS checks the signature, not who is holding the key, so as far as AWS knows, the developer did this. The violation is that an agent used a role that agents aren't allowed to use. Unlike intent, you can check that on every request.

Who’s to blame? The developer who shouldn’t have handed the agent their credentials and let it auto-approve actions? The harness maker? That’s the wrong question. Again, agents should do more on their own, speaking both as a developer and as a manager of developers who work with AI.

Instead of assigning blame, we need to know where this deletion attempt can actually be stopped. There are several possible enforcement points, and each depends on what the control can see, what it can block, and whether the agent has another path to the same action.

We want autonomy with limits we can actually enforce

First, we need to scope the problem. There’s constant pressure to expand agentic access, and usually, the reason makes sense in isolation. A task gets stuck, for example. Or there’s a new integration for a service that holds some of the organizational context.

The result is always the same: the next task starts with more access than the previous one.

A second source of pressure is the agent itself. Agents look for new credentials when the ones they have are blocked, without asking the human in charge whether they can have that access.

This behavior is agnostic to the source of the instructions. A malicious prompt injection can cause overreach attempts, but so can mistaken assumptions during an authorized task.

Be specific about what you are enforcing

Agents use tool calls to retrieve data or take action, so that’s where the enforcement matters most. That said, "control tool calls" is a very coarse rule. What if the tool is a shell that can run an SDK? It can also be a browser with an authenticated session. When you allow the tool, you also allow what’s behind it.

To properly understand what’s happening, we need the operation, its arguments, the account and resource accessed, and the identity in use. For data operations, we also need to understand what the output is and where this output is routed.

There’s a lot that goes into a proper decision about the validity of an action.

In most agent harnesses, local commands, file operations, skills, and delegation are also tool calls. They matter because of where they lead. For example, reading ~/.aws/config is how the agent finds an admin profile to use.

So enforcement at the tool call is critical, and so is deciding on the action inside it.

Where enforcement can happen

Some of the damage can be prevented through reasoning checks that assess a plan or action against the task at hand. But this is a probabilistic control, and some malicious instructions will pass through. There’s no good alternative to having proper mitigation controls that can stop an action.