Agent permissions: what should you grant?
Stefan-Iulian Tesoi · · 6 min read
Enough to fetch work, read its context and hand it back, and no authority to close it. Read and write on the items it is working, a confirmation step on anything that undoes a person's decision, and nothing at all outside the project it was granted.
Agent permissions are usually set once, during an afternoon of getting the connection working, and never looked at again. That is the actual risk in most teams: not a grant that was wrong on day one, but a grant nobody has read since.
What should agent permissions actually cover?
Three things, and only the third is contentious.
What it can see. An agent working an item needs the item, its acceptance criteria, its parent epic and the rules of the project it is working in. It does not need the rest of the backlog, and it certainly does not need other projects.
What it can change. Creating items, moving them forward, attaching evidence, reporting a blocker. These are additive: they make new records rather than removing existing ones, and nothing in that list needs a human to approve it in the moment.
What it can finish. This is the contentious one, and the answer is nothing. An agent can carry an item as far as review. The transition from "built" to "done" is a judgement about whether the work meets what was asked, and handing that to the thing that produced the work removes the only independent check in the process.
Every permission argument that goes in circles is really an argument about the third one. Teams that settle it first find the rest of the grant almost writes itself.
What does least privilege mean for an agent?
The same thing it has meant since 1975, applied to a faster actor. Saltzer and Schroeder's The Protection of Information in Computer Systems set out least privilege as a design principle: every program operates using the least set of privileges necessary to complete the job. The wording has not needed updating.
What has changed is the cost of getting it wrong, because the actor is fast and tireless. A misconfigured human contractor makes a handful of mistakes before someone notices. A misconfigured agent makes a few hundred, politely, overnight.
A least privilege AI agent grant is narrower than most end up being, and coding agent access control comes down to four choices:
- Scope to one project, not to an account. An agent working on the billing service has no business enumerating the backlog of the mobile app.
- Scope to a person, where a person is driving. A credential bound to you keeps attribution intact; a shared key collapses everyone's work onto one identity and makes an incident unreconstructable.
- Prefer additive over subtractive. Creating a bug is safe. Archiving one takes something away from where a person put it, and the two do not deserve the same treatment.
- Grant nothing for "later". The permission added because it might be needed next quarter is the one still there in two years, unused and unreviewed.
Which actions should stop and ask?
The ones that undo a person's decision, and almost nothing else. The useful test has two questions, not one, and the second is the one people skip.
| Can it be undone? | Whose decision does it undo? | Where it belongs |
|---|---|---|
| Yes | Nobody's — it is new work | Runs without asking |
| Yes | A person's | Confirm first |
| No | Nobody's | Confirm first |
| No | A person's | Should not be granted at all |
Reversibility alone is the wrong test, because it classifies too much as dangerous. Most things an agent does in a backlog are reversible — archived items stay recoverable — so a system that prompts on everything reversible prompts constantly.
That matters more than it sounds. Confirmation prompts are a budget, and spending them badly is worse than not having them. A reviewer who has clicked through forty dialogs this week is not reading the forty-first, and the one that mattered arrives looking exactly like the other thirty-nine. A tool that asks about everything has trained its users to approve everything, which is a weaker position than asking about nothing and being narrow instead.
Laimonade declares one of three MCP permissions on every tool and reserves the confirming tier for the second and third rows: destructive means undoing a human decision rather than losing data. delete_milestone is the clearest case — it genuinely removes the milestone, so it is refused outright while any epic still points at one, and cancelling is the better move when work actually happened. Every tool and its tier is published in the MCP tool reference, and where the handover sits in the week is in the sprint workflow.
How do you review a grant you made six months ago?
By looking at three things, twice a year, in about twenty minutes. The review is short because the questions are narrow, and it is worth doing because nothing else in the system will tell you a connection went stale.
- List what the connection was actually granted. Not what you remember granting. Ask the agent to enumerate its own projects, or read the grant from the connector page, and compare that against what it is for now.
- Check when the credential was last used. A credential with no recent use is either a forgotten integration or somebody's abandoned experiment, and both should be revoked rather than left. A last-used timestamp turns this from an investigation into a glance.
- Re-read the tier assignments against your own workflow. Teams change what counts as a human decision. If your team has started treating a certain transition as meaningful, the permission that governs it should have moved tiers too.
The two failures this catches are unglamorous. The first is the leaver: someone set up a connection under their own sign-in and has since moved on, so the work of a still-running agent is attributed to a person who no longer works there. The second is scope creep by addition — a second project granted for a two-week experiment, never ungranted, quietly widening what a compromised credential would reach.
Neither is exotic and neither shows up as an incident. They show up as an audit finding, months later, which is the argument for the twenty minutes.
Frequently asked questions
Should an agent be able to close its own work?
No, and this is the one limit worth being inflexible about. Closing an item asserts that the work meets its acceptance criteria, and an assertion made by the thing that produced the work is not independent evidence. Let the agent carry the item to review with its commands, exit codes and a list of what it could not verify, then let a person decide.
Is read-only access useful on its own?
Yes, as a starting posture. An agent that can read the backlog but not write to it can still answer what is ready, summarise an epic and draft an approach, which is enough to see whether the items are executable at all. It is also the easiest grant to get through a security review, which makes it a good shape for a first fortnight.
How often should permissions be reviewed?
Twice a year on a schedule, and immediately whenever someone leaves or a project is restructured. The scheduled review catches stale grants; the triggered one catches attribution that has quietly become wrong. Both are short, because the questions are narrow: what was granted, when was it last used, and does it still match what the connection is for.
Does an agent need access to our repository?
Not for backlog work, and it is worth keeping the two grants separate. Reading items, attaching evidence and moving work to review needs no repository credential. Where a link is useful it should point inward — commits and check results arriving against the item — so status reflects something that happened rather than a button somebody pressed. What is stored either way is set out in the privacy policy, and the wider question of what a connection should be unable to do is in coding agent security.