How to Limit AI Agent Permissions (Before It Needs You To)

To limit AI agent permissions in a way that actually holds when the agent is confidently wrong, most advice stops one step too early at “trust it less,” which is not something you can configure. The question that actually helps is narrower: given exactly the access this agent has right now, what is the worst single action it could take?

That question has a concrete answer, and it changes what you do next. This is the first post in this series that is mostly instructions rather than warnings, and it assumes you already know why agents need limits (if not, AI agent security risks covers that ground).

To limit AI agent permissions, ask reversible or not, not read or write

The instinct is to split permissions into read and write, and let the agent read freely while gating anything that writes. It is a reasonable start and it is not enough, because plenty of writes do not matter and plenty of reads do.

An agent that drafts a Slack message nobody has to send yet is a write with almost no consequence. An agent that reads every file in a shared drive to summarize a project has read-only access and can still hand a stranger everything sensitive in that drive. The axis that predicts damage is not what kind of operation it is. It is whether the operation can be undone before anyone notices.

Sorting actions this way gives you a rule instead of a judgment call each time: let the agent execute reversible actions on its own, and require a human step before anything irreversible. A draft, a search, a read, a staged change nobody has approved yet: reversible, let it run. A sent email, a deleted file, a schema change, a payment: irreversible, it waits for you. Most of what makes an agent useful lives in the reversible half, so this is not the same as switching everything to manual.

Narrow the grant at the moment you make it

The most common mistake is not giving an agent too much access on purpose. It is granting access at the level the integration happens to offer, because that is the only option in front of you, and moving on.

Most APIs support finer scopes than the default connection asks for. An agent that only needs to read one label and draft replies does not need full inbox read and send. An agent that only needs to update a single spreadsheet does not need edit access to the whole drive. The narrower scope is usually one dropdown away, and it is worth the extra minute every time, because it is the only step in this list that removes access rather than adding a check on top of it.

The second half of narrowing is identity. An agent running on a credential it shares with three other tools, or with the human who set it up, cannot be scoped, logged, or revoked without affecting everything else on that credential. Give each agent its own key, even if provisioning it takes longer than reusing one that already exists. When something goes wrong, the difference between “we revoked this agent’s key” and “we revoked a key four other things depend on” is the difference between an afternoon and a week.

Mine are not, not yet. Every script behind this site’s own publishing pipeline, the one that pushes posts to WordPress and the one that syncs research into Notion, reads from a single file: one WordPress application password, one Notion token, shared across every session and every task that touches either service. If either leaked, revoking it would take down publishing and research syncing at the same time, not just one agent’s access.

The checkpoint that sits between deciding and doing

An agent’s own judgment is not a control, because the same reasoning that got the task done is what fails silently when the situation is slightly unusual. The fix is not asking the agent to be more careful. It is putting something outside the agent’s reasoning in the path of the action.

In practice that is a thin layer the agent’s calls have to pass through before they reach the real system, checking each request against what the agent is actually scoped to do rather than trusting the agent’s own account of what it is doing. Paired with the reversibility rule above, this is where approval requests should land: not as a blanket “confirm every action” toggle, which trains people to click confirm without reading, but scoped to the irreversible half specifically, so the moments that need a human’s attention are not buried in a stream of routine confirmations.

A checkpoint sitting between an AI agent's decision and the real system, letting reversible actions through automatically while routing irreversible ones to a human for approval

The checkpoint does not ask whether the agent is trustworthy. It asks whether this specific action can be undone.

I ran into this exact pattern while writing this post. Researching the Cowork sandbox incident above meant pulling a page from a domain my own AI assistant had not touched before, and it stopped and asked me to allow it, once or for the whole site, before it would fetch anything. That is about as low-stakes as a checkpoint gets, a read against a public blog post, and it still asked instead of assuming.

Pushing a post live turned out to be a weaker example than I expected, since WordPress keeps revision history and a bad push is recoverable. What would actually count as irreversible here, like deleting a file outright or sending something out, I honestly do not know if anything would stop it. None of my scripts have needed to do either yet, so I have never had a reason to find out.

Isolation helps, and it is not enough

Running an agent inside a container, a VM, or a dedicated sandbox limits what a compromised or confused process can reach on the host, and it is a reasonable default for anything that executes code. It is also not the same as being safe, and two incidents from July 2026 make that concretely clear rather than theoretical.

Security firm Accomplish AI disclosed a flaw in Claude Cowork nicknamed SharedRoot. A local Cowork session could exploit a Linux kernel privilege-escalation bug, CVE-2026-46331, to gain root inside its own virtual machine, then reach the host Mac’s filesystem through a writable mount with no permission prompt shown. Roughly 500,000 macOS users running local sessions were exposed. Anthropic closed the report as informative without issuing a fix, and the sandbox design the researchers flagged, the whole host filesystem mounted writable, was not hardened. Cowork now defaults to cloud execution, where this particular escape path does not apply, but anyone still choosing local execution remains exposed. The sandbox was the entire safety mechanism, and nobody sealed the hole in it.

The second incident is stranger, because nobody was attacking anything. Reviewing its own cybersecurity evaluation transcripts, Anthropic found three cases where a Claude model was told its test environment had no internet access. That was false. A misconfiguration in the evaluation environment Anthropic ran with Irregular, a third-party partner, left the machines reachable from the open internet, and neither side noticed until afterward. Anthropic describes it as a misunderstanding between the two and takes the responsibility itself. The consequences were real either way. One model found a live company that happened to share a name with its fictional target, extracted credentials, and pulled several hundred rows of production data. It worked out partway through that the system was genuine and kept going anyway. Another model registered a real PyPI account and published a working malicious package under a name it expected a fictional company to install; in the hour before the package was pulled, it ran on 15 real systems. No model tried to escape anything. The isolation simply was not isolated, and the mistake surfaced only because OpenAI’s disclosure of its own incident prompted Anthropic to go looking.

Neither incident means isolation is worthless. Both mean it depends entirely on humans configuring it correctly and checking it stayed that way, and two disclosures landing in the same month from a well-resourced AI lab are a reason to check your own setup, not a reason to assume yours is different. That is exactly why the scoping and checkpoint steps above come first in this list, not after.

Logging what the agent was allowed to do

The previous four sections reduce how often something goes wrong. This one is about being able to answer questions after something does, which is a different problem and gets skipped almost as often.

When an agent acts, log three things alongside it: what it was scoped to do at that moment, what it proposed, and whether a human approved it. Permissions drift over time as scopes get widened for convenience and never narrowed back, so the record from six months ago is not a reliable description of today unless you kept it. Without that log, the honest answer to “what could it have accessed when this happened” is a guess, and guesses are a bad foundation for telling anyone, including yourself, that the damage was contained.

Start with the agent that can reach the most

If none of this exists yet, the order that produces the most safety per hour of work is roughly this. Pick the agent with the broadest current access and narrow its scope first, before touching anything else. Give it its own credential if it is still sharing one. Add a single approval gate in front of whatever it does that cannot be undone, even a crude one. Everything past that point, the checkpoint layer, the isolation, the logging, is refinement on a base that is already safer than where most setups start.

FAQ

What permissions should I give an AI agent access to my email or Slack?

Start from the specific task, not the app. If the agent only needs to read one label and draft replies, request that scope rather than full inbox access, and give it its own credential rather than sharing yours. Whatever it can do that sends something externally, like sending an email or posting a message, should sit behind an approval step rather than running automatically.

Is sandboxing an AI agent enough to make it safe?

No, and two 2026 incidents show why in different ways: a real sandbox escape in Claude Cowork, and a case where Claude models never escaped anything but reached real companies because an evaluation environment was misconfigured to have internet access nobody realized was there. Isolation limits the blast radius of a failure, but it is one layer among several, not a substitute for scoping the agent’s actual permissions and gating irreversible actions.

Can I let an AI agent approve its own actions?

Not for anything irreversible. An agent’s own confidence in a decision is not evidence the decision is correct, and self-approval removes the one check that catches it when it is wrong. Reversible actions like drafts, reads, and staged changes are reasonable to let run automatically; anything that cannot be undone should require a human step regardless of how confident the agent’s output looks.

How do I know what an AI agent was allowed to do after something goes wrong?

Only if you were logging it. Record the agent’s scope, what it proposed, and who approved it, at the time each action happened, not after. Permission scopes get widened for convenience and rarely narrowed back, so without a timestamped record, you are reconstructing what happened from memory instead of evidence.

Should every AI agent have its own login instead of a shared one?

Yes, wherever the provider supports it. A shared credential cannot be scoped, monitored, or revoked without affecting every other tool using it, which turns a single incident into a wider cleanup. A dedicated credential per agent costs a small amount of setup time and makes every later step, scoping, logging, revocation, easier to do cleanly.

Sources

Incident details reflect public disclosures from July 2026. Descriptions of scoping and checkpoint practices reflect common patterns in ongoing practitioner discussion, not a formal survey.