How to scope write permissions for LLM agents

Start from what the agent has to change

Before choosing any control, list the files, keys and resources the task actually changes, and separate them from what it only reads.

The OWASP LLM Top 10 entry on excessive agency puts this first: limit the tools, then the functions inside each tool, then what each tool may do on other systems. Its example agent needs to read one database table and “should not have access to other tables, nor the ability to insert, update or delete records”. The limit is set in the database, on the identity the tool connects as, not in the prompt.

Open-ended tools undo all of this. OWASP says to avoid open-ended tools such as a shell “where possible”, because “the scope for undesirable actions is very large (any other shell command could be executed)”. An agent that edits config through a shell holds every permission the shell’s credentials hold.

Six controls, in the order to add them

1. Give the agent its own identity, not a shared admin account. OWASP’s agentic Top 10 calls for “per-agent identities”, and Google’s secure-agents paper says agents acting for teams “need distinct identities and clear authorization models”. Where an agent acts for one person, OWASP adds that the action should run “in the context of that specific user, and with the minimum privileges necessary”, rather than on the agent’s own permissions alone, so the agent never does more than that person could.

2. Keep production write credentials out of reach. The simplest limit is a production environment the agent’s identity has no access to. AWS lists separate accounts for non-production and production among the benefits of a multi-account setup, because “by default” each environment’s resources are “separated from other environments and workloads”. After Replit’s vibe coding agent deleted data from a user’s production database in July 2025, the fixes its CEO announced included “automatic separation between development and production databases”, Fortune reported.

3. Let the agent propose and the pipeline apply. For production config, the agent opens a pull request, and the deploy pipeline, under its own identity, applies the change after review. GitHub’s coding agent is one working example. It can push to a single branch, it “cannot approve or merge a pull request”, and by default workflows do not run on its changes until someone with write access approves them. The person who asked for the change cannot approve it either. On the deploy side, GitHub environments can require a named reviewer, and an optional setting blocks self-review so deployments “are always reviewed by more than one person”. On GitHub’s Free, Pro and Team plans, required reviewers work only for public repositories. Any review-and-apply pipeline can do the same.

4. Make direct write credentials short-lived and narrow. Some writes cannot wait for a pull request, such as staging changes or an incident fix. For these, OWASP’s advice is: “Issue short-lived, narrowly scoped tokens per task and cap rights with permission boundaries”. Cloud platforms already support each part. An AWS role session can be requested for as little as 15 minutes and at most 12 hours, within the maximum set on the role, and a session policy narrows it to “the intersection of the role’s identity-based policy and the session policies”. A GitHub App token “will expire after 1 hour” and can be requested with fewer permissions than the app holds. An AWS permissions boundary sets “the maximum permissions that an identity-based policy can grant” to a role. Google makes such a cap a requirement: agents “must be prevented from escalating their own privileges beyond explicitly pre-authorized scopes”. For agents that reach tools over MCP, the protocol’s security guidance applies the same idea to OAuth scopes: start with a “Minimal initial scope set” and elevate only when “privileged operations are first attempted”.

5. Check each action against a policy outside the model. OWASP calls this complete mediation: “Implement authorization in logic rather than relying on an LLM to decide if an action is allowed or not.” The check can sit in the tool, in a separate policy point in front of the target, or in the target system. OWASP suggests graduated outcomes, so “low-consequence or easily reversible actions” go through and “high-consequence or irreversible ones route to human review”. Google’s paper describes the same layer as a policy engine that can allow an action, block it or ask the user to confirm.

6. Log every write and every grant. OWASP says monitoring “will not prevent Excessive Agency but can limit the level of damage caused”. The MCP guidance adds logging each scope elevation “with correlation IDs”, so a later audit can tie a grant to the operation that asked for it.

How the four common setups compare

The four setups below are layers, not alternatives: each covers a gap the others leave. The last column says where each one does the most work.

Setup	What it limits	What it leaves open	Does the most work when
Pull request gate	Nothing reaches production until a person approves the diff	Only as good as the review	Config already lives in a repository with a deploy pipeline
Scoped service account	What the agent can touch at all	Misuse within that scope, for as long as the credential lives	The agent’s job is narrow and stable
Short-lived credentials	How long a leaked or misused credential works	Anything within the scope and the time window it was issued for	Tasks that need direct writes, such as staging or incident work
Policy gateway	Which individual actions go through, checked against rules before they run	Rules nobody anticipated: Google warns a rule “might block a legitimate action or allow a harmful one”	Many tools or many agents, where reviewing each one does not scale

Where these controls fall short

An instruction is not a permission. Telling an agent “do not touch production”, or declaring a code freeze in its prompt, limits nothing. During the Replit incident, SaaStr founder Jason Lemkin wrote “There is no way to enforce a code freeze in vibe coding apps like Replit”. Seconds after he posted it, he added, the agent “again violated the code freeze”, The Register reported. OWASP lists prompt injection among the triggers for excessive agency, and an instruction in the prompt is exactly what an injected instruction can override.

Approving everything. A human confirmation on every write turns the gate into a reflex. Anthropic, describing its own coding agent, says constant approval “can lead to ‘approval fatigue’, where users might not pay close attention to what they’re approving”. It reports that giving the agent pre-set boundaries cut permission prompts by 84% in its internal use. Keep human approval for irreversible and high-impact changes, and bound the rest with the controls above. The risk on the reviewer’s side is automation bias.

Trusting the scope in the token. MCP’s guidance lists this among its common mistakes: “Treating claimed scopes in token as sufficient without server-side authorization logic”. The system being written to still has to check.

Expecting any of it to make the agent safe. Google builds its defence in layers because of “the practical impossibility of guaranteeing perfect alignment against all potential threats”. These controls bound what an agent can break. They do not decide whether a change it proposes is a good one; that is still the reviewer’s job.