More teams are pointing AI agents at the tools they already use to build and test software. An engineer can ask an agent to fix a flaky test and watch it create a branch, edit the test, run it, and get most of the way to done.
That convenience creates a new permission problem. A person might be allowed to delete a branch by hand and still be uncomfortable with an agent doing it unattended.
Cleanup is a good example
Agents create things quickly and rarely notice the cleanup they leave behind. In usage I have been looking at, teams using agents to create test branches accumulate them much faster than teams that do not. Eventually someone has to delete old branches or write a script to do it.
It would be useful for the agent to clean up after itself. The same delete permission can be harmless in one case and risky in another, so teams need a way to decide how much of that work they are comfortable handing over.
What teams need to control
Large companies tend to get to this question early because security and audit teams need a clear answer to what an agent can reach, what it can change unattended, and who gets to set those rules.
The model that makes the most sense to me is simple. A person’s existing role sets the outer limit. Inside that, an admin can decide whether an agent can take a specific action freely, needs approval, or cannot use it.
A few practical details matter. If an action is blocked, the agent should not get the tool at all. Pre-approval should be limited by count as well as time because an agent can do a lot in an hour. Reversible actions are easier to delegate. Some cleanup, like expiring an abandoned temporary branch, can happen automatically without asking anyone to remember it later.
Why teams care
Teams are more willing to hand over meaningful work when they know where the edges are. Engineers get fewer half-finished agent workflows, and security teams get controls they can set centrally and review later. That makes adoption easier without turning every agent step into another approval prompt.