How to keep AI agents within their permissions
AI agents can use valid credentials to perform actions beyond their assigned permissions, creating risks that traditional access controls may not prevent. Token Security explains how organizations can enforce agent-specific policies without sacrificing autonomy.
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.
Valid Key, Wrong Hands
AWS checks the signature, not who holds the key. When an agent grabs an admin profile, the request appears to come from the developer.
Token Security maps every agent to its owner, identities, and permissions, so your controls block actions outside the assigned task and allow the rest to run.
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.
These methods overlap and complement each other. A hook that calls a policy service and a gateway that consults an identity graph do a better job because the enforcement and decision points are in the locations best suited to them.
This table is far from exhaustive, and there are more considerations for some of these methods. Take managed settings, for example. Model and effort settings are behavioral in nature, but with some harnesses, permissions are much more than a prompt saying “please don’t flip out”.
In Claude Code, for example, permission rules are enforced by the application itself, and managed settings can restrict user overrides. In that case, control lives in a settings file, but that doesn’t make it less effective.
With hooks, the basic premise depends entirely on their placement in the execution chain. You can’t stop an event that’s already happened, and failure behavior varies by hook types and events.
Gateways have their own complexities, as they must base their authorization decisions on what they see. Look at AWS AgentCore, which demonstrates policy checks for connected tools. Note which calls it sees.
Sandboxes and scoped credentials solve different problems. Proper isolation can remove access capabilities, whereas a scoped credential limits what happens after access is granted. See Cloudflare’s sandbox authentication design, which shows a way to add credentials outside the sandbox, so the agent doesn’t need to possess the secret. Its operations, though, will still require authorization.
Apply the same policy to a hosted agent
Consider a support agent that’s asked to summarize open cases. Its connector uses a service account built for agents that edit and close cases. The agent decides that some cases look resolved and tries to close them.
Again, the capability comes with the credential, and the agent is within its grant. The place where the action is disallowed is the agent’s approved read-only policy.
To enforce it, the policy must be something a control can check, such as: “This agent may read cases, and any call that edits or closes one is denied, regardless of the service account it holds.”
If that agent lives in a hosted environment, an endpoint control on the employee’s laptop might have no opportunity to stop the action, since it’s all server-side.
Here, you’ll need cooperation from the SaaS platform’s own controls, rely on a tool gateway, or have a narrower service identity. And again, it depends on what the platform exposes and where the calls run.
Which brings us to coverage gaps in our controls. There’s no one perfect control here. Hooks aren’t better than endpoint enforcement, which isn’t better than a sandbox. It’s all about what you deploy and where.
Two methods can stop both of these examples before the action reaches the target: a gateway that sees the relevant traffic and credential scoping at the target. The other methods depend more heavily on where the agent runs and what the runtime exposes.
Above all, you want the agent to keep working within its approved policy. Read-only is not complete. It can still expose sensitive data, depending on where the output goes. Anthropic’s containment analysis explains why.
Choose what’s practical, then test the ways around your control
You’ll likely be deciding what’s practical based on your deployment. Managed settings require supported clients and central administration, for example. And you won’t have hooks without a runtime that exposes the right events. Gateways force you to route traffic through them, and endpoint controls mandate software installation and maintenance.
None of these is free. The controls introduce trade-offs, require maintenance, and must account for an ever-growing volume of AI-driven work.
Take the AWS example from the beginning of the article. Blocking the literal command is a start, but what if the same request comes through an SDK? With a different credential? Through delegation?
The security requirement to block deletion remains the same, but there are many different paths to it.
Then there’s the question of value, and you have to consider it as much as the control capabilities. How much delay do the controls add? How often does someone need to unblock a false positive? Are we reducing risk or introducing problems?
SACR’s ARISE report centers on runtime intervention, delegated authority, and action-level decisions. This should be brought down to a concrete request, a policy, and evidence of what happened when the agent tried it.
A short guide, based on where your agents run and what you control there:
It probably isn’t one or the other. Instead, most organizations have all of the above, mixed together, with controls spread around different teams as well. Across these environments, the one common denominator is identity. So start with credential scoping at the target, as this dictates the reach wherever the agent is running. Then, add one policy source that every enforcement point reads from.
Do this, and you’re in a good starting position.
Where Token fits
At Token Security, we are building around the identity intelligence graph and the decisions it can support across the different enforcement points. Our current focus spans agent settings, gateways, endpoint enforcement, and APIs into identity and agent platforms.
The broader vision is to build or connect to the enforcement capability the customer needs. We don’t need to build everything ourselves.
The graph connects an agent to its owner, the identities it consumes, the permissions associated with those identities, and the resources it can access. That’s the kind of context that policy engines can use to decide what an agent may do, rather than assuming that the credential’s full authority is appropriate.
In a recent gateway demo, we demonstrated this exact idea: same developer, same session, and the agent’s call is denied on admin and allowed on readonly. Other controls can enforce read-only access, too.
Supplying the right identity context and applying the policy across the different places agents work is paramount, yet complex, as this process requires reliable attribution. If we cannot distinguish the agent’s request from a human using the same credentials, the graph doesn’t magically fix it.
What about baselines? Keep in mind that past behavior can only be used as an input, not the policy itself. The fact that an agent usually just reads data does not prove that a write is forbidden. That’s the job of the rule that pins agents to readonly. Missing or stale context also requires an explicit decision, as with hook timeouts.
I want an agent to complete the investigation or the support summary without requiring approval for every step. I also want to know exactly where an action outside that task will stop. That’s what I would ask of every enforcement method, including Token Security.
Check us out or book a demo if you’re also solving these AI security problems in your organization.
Sponsored and written by Token Security.
