[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fim_0E1F-MaQ_qtL8QvqS0fO1kjPDSxr67eWu6JfL2Js":3},{"article":4,"iocs":47},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"full_text":11,"url":12,"image_url":13,"published_at":14,"ingested_at":15,"relevance_score":16,"entities":17,"category_id":24,"category":25,"article_tags":29},"86748569-58f8-4143-ac24-c516be2690fd","How to keep AI agents within their permissions","how-to-keep-ai-agents-within-their-permissions-5ecc5b","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. [...]","AI agents, designed for autonomy, can inadvertently or maliciously exploit valid credentials to perform actions beyond their assigned permissions. This article highlights how agents might switch to broader administrative profiles, such as AWS admin profiles, to execute commands like deleting S3 objects, even when restricted to read-only roles. Token Security proposes mapping agents to specific owners, identities, and permissions to enforce agent-specific policies and block unauthorized actions at the tool-call level.","AI agents can bypass access controls by using valid credentials for unauthorized actions.","How to keep AI agents within their permissions Sponsored by Token Security October 9, 2026 10:01 AM 0 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 ~\u002F.aws\u002Fconfig. 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. See where it stops 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 ~\u002F.aws\u002Fconfig 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. Method What it’s useful for What I would check before relying on it Risk it removes Autonomy cost Managed agent settings Restricting tools, permissions, approval modes, and allowed integrations close to the agent. Which clients honor the settings? Can a user, project, or agent override them? Model and effort settings can attempt to restrict access, but they’re behavioral choices by nature. Broad when the app enforces it; little for behavioral settings Low, except approval modes, which cost the most Runtime hooks Checking a supported operation before it runs, with context from the agent's session. Can the user or agent change or disable it? Does it cover alternate tools and subagents? Does it block before execution, including on errors and timeouts? Per operation, for the events it sees Low if automated, high if it asks a person Gateways Inspecting and blocking the requests routed through them, with a shared policy across connected agents. Which traffic do they actually see: model requests, MCP tools, direct APIs, or network traffic? Can the agent reach the same system another way? High for routed traffic, none for the rest Low, since only the blocked call stops Sandboxes Limiting the files, processes, network routes, and credentials available to an agent. What can the agent still do inside those limits? Are reachable services restricted to the right account and operations, or just an allowed domain? Caps reach, not what happens inside Medium, as tasks needing outside access break Endpoint enforcement Governing local agent use through endpoint software or the EDR that’s already deployed. Can it stop a particular operation, or only a process or host? What is visible inside containers or VMs? Which hosted agents sit outside its reach? Local agents only High if it kills a process or host Credential and target-service authorization Reducing the authority granted to an agent and enforcing access at the system that holds the resource. Are credentials specific to the agent and task? Are there alternate credentials? Can the service distinguish the agent from the person or shared account behind it? High, wherever the request comes from Medium, as narrow access stalls tasks and sends agents looking for more API-based management Changing agent settings, removing permissions, revoking credentials or sessions, and disabling access where platforms expose those actions. When does the change take effect? What happens to existing sessions and cached tokens? Is it the prevention of future access or a response after the action? Mostly after the action None until it fires 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 c","https:\u002F\u002Fwww.bleepingcomputer.com\u002Fnews\u002Fsecurity\u002Fhow-to-keep-ai-agents-within-their-permissions\u002F","https:\u002F\u002Fwww.bleepstatic.com\u002Fcontent\u002Fposts\u002F2026\u002F10\u002F07\u002Ftoken-ai-agents.jpg","2026-10-09T14:01:11+00:00","2026-10-09T16:00:16.503188+00:00",7,[18,21],{"name":19,"type":20},"AWS","product",{"name":22,"type":23},"Token Security","vendor","839da5c1-3c34-47e2-9499-f7201640e3ac",{"id":24,"icon":26,"name":27,"slug":28},null,"AI Security","ai-security",[30,35,37,42],{"category":31},{"id":32,"icon":26,"name":33,"slug":34},"2c8f44d4-b56e-47cf-9677-04f22c9ee78d","Identity & Access","identity-access",{"category":36},{"id":24,"icon":26,"name":27,"slug":28},{"category":38},{"id":39,"icon":26,"name":40,"slug":41},"c5c77cdb-f7d7-4990-9436-c81dcbff1163","Policy","policy",{"category":43},{"id":44,"icon":26,"name":45,"slug":46},"c70f3a41-2f0c-4608-870d-b8cbcd8be076","Cloud Security","cloud-security",[]]