Least Authority for Coding Agents: Permissions by Task, Not by Role

An agent may be capable of editing a release workflow, deleting an environment, or publishing a package. That capability does not answer whether the current task needs any of those powers.

The safer design question is smaller: for this episode, which exact reads and writes are necessary, against which resources, and with what limits? This applies the familiar principle of least privilege to agent workflows. The access belongs to the task and its risk, not to a broad identity called “the coding agent.”

Start from actions, not trust labels

“Trusted agent” is too coarse to be an access policy. A single workflow may read a repository, edit a branch, run a shell command, create a pull request, merge it, and deploy. Those actions have different consequences and should not inherit one permission setting merely because one agent can perform them all.

Write an action inventory before enabling tools:

Action	Resource	Minimum access for a draft task	Higher-risk boundary
Read source and tests	One repository	Read-only repository access	Secrets and private data excluded unless essential
Edit implementation	Isolated branch or worktree	Write to the task branch	Protected branch remains unavailable
Run checks	Local or disposable environment	Execute within resource and network limits	No production credentials or unbounded host access
Create a review request	Named repository	Create a pull request	No merge permission
Change shared configuration	Specific setting or workflow	Prepare a proposed diff	Human review and approval before applying
Release or deploy	Release system	None for ordinary implementation tasks	Separate, explicit authorization and identity

The last column is not a universal tiering standard. It is a prompt for a team to match the boundary to its own system and consequences.

Divide access into useful slices

A practical starting model has four slices:

1. Observe: read only the task context and resources needed to understand it.
2. Prepare: edit an isolated branch or workspace and run bounded local checks.
3. Propose: submit a reviewable change or draft request without applying it to a protected target.
4. Commit a consequential transition: merge, publish, deploy, delete shared data, rotate credentials, or change access policy.

Many low-risk episodes can safely stop after the second or third slice. The fourth is a separate decision. Keeping it separate lets the agent perform useful engineering work without turning access to a tool into authority to use every function that tool exposes.

Make the boundary real in the toolchain

Instructions such as “do not deploy” help, but a token that can deploy still makes deployment possible if the agent misunderstands the request or an input steers it toward the wrong action. Prefer controls that make out-of-scope actions unavailable:

• use read-only credentials for investigation;
• scope write tokens to the smallest repository or resource set;
• grant access only for the time needed;
• use disposable environments for commands that may have side effects;
• keep production secrets out of the agent’s environment;
• separate pull-request creation from merge and deployment permissions;
• set explicit token permissions rather than inheriting broad defaults.

GitHub’s Actions security documentation, for example, recommends read-only defaults for the workflow token and increasing permissions only where a job needs them. Its workflow syntax also lets maintainers state per-permission read, write, or none. That is an implementation example of reducing ambient authority; it does not prove that a workflow is safe by itself.

Treat incoming repository content as data

An agent may read issue text, source comments, test fixtures, generated files, or web pages. Some of that text may contain instructions. Reading it does not make it a legitimate source of authority to widen permissions, reveal secrets, or change the assigned goal.

Keep the trusted task contract separate from material being inspected. Tool wrappers should validate the target and operation against the current task’s grant. A repository file can explain how the project works; it cannot authorize a deployment merely by saying “deploy now.”

This separation is especially important when the same agent can both interpret arbitrary text and invoke tools. A narrow tool that accepts a structured operation against an approved resource is easier to bound than an unrestricted shell with ambient credentials.

Bind approval to the action

“You have my approval” is not a useful system boundary if it does not specify what action was reviewed. For an operation that requires human authorization, show the person:

• the exact target and intended change;
• the reason the operation is needed;
• the relevant diff or payload;
• the expected effect and rollback path;
• the identity that will execute it.

Then require an affirmative approval for that action. If the target or payload changes materially, the old approval should not silently carry over. For high-impact transitions, use a separate approval and execution identity where the organization’s controls support it.

An approval should also have a clear expiration. A person who approved a patch yesterday did not necessarily approve a new patch today or a release of an artifact built from different source.

Make reversibility part of access design

Reversible operations are easier to delegate than irreversible ones, but “reversible” must be checked rather than assumed. A branch edit can usually be discarded. A migration that deletes old records may not be. A draft post can be withdrawn; a public post can be copied, indexed, or quoted after deletion.

Before granting write access, ask:

1. Can the change be previewed before it takes effect?
2. Can the agent operate on a disposable copy?
3. Is the result idempotent if a tool call is repeated?
4. Is there a reliable rollback or compensating action?
5. Who owns recovery if an operation partially succeeds?

The more difficult recovery would be, the more tightly the action should be scoped and the more clearly a human must approve the final transition.

Revisit permissions when the task changes

Least authority is not a one-time role assignment. A task can change while being investigated. If a documentation issue turns out to need a schema migration, the original grant does not automatically expand. The agent should state the new action it needs, why it is needed, and what permission boundary it would cross.

For repeat work, encode the minimum grant in the workflow and review it as the tools or task change. Remove permissions that are no longer needed. A broad permission is not justified by the fact that it made one difficult episode convenient.

The permission review

Before a coding agent starts, check:

• What can it read that is not needed for this task?
• What can it write, and where?
• Which commands can reach the network or modify shared state?
• Could a tool call cross a protected boundary without a person?
• What happens if input text tries to redirect the agent?
• Can each higher-risk action be presented and approved separately?

The useful default is simple: give an agent the smallest operational space in which it can produce and verify the requested change. Let it prepare work; keep consequential authority at the boundary where the consequences become real.

References

• NIST SP 800-53 Rev. 5, AC-6: Least Privilege
• GitHub Actions: Secure use reference
• GitHub Actions workflow syntax: token permissions

Source, license, and AI assistance

This article adapts the least-authority, separation-of-duties, and escalation principles in Part II of From Vibe Coding to Agentic Software Engineering, whose source record credits ChatGPT as preparer and identifies CC BY-NC-SA 4.0. This version is substantially reorganized and expanded with an action matrix, examples, and primary security references, and is shared under the same license: CC BY-NC-SA 4.0.

AI disclosure: The article text was generated primarily by AI. A human publisher supplied the topic, source material, and editorial direction, and remains responsible for checking claims and examples before publication.