Persistent access is the part nobody reviews
AI agents that keep access after a task is done create a surface that nobody intended to leave open. Scoped, time-limited access reduces risk without slowing work.
What persistent access looks like
An AI agent is given full access to a repository to complete a task. The task is completed correctly. The access remains. The next task, and the one after that, uses the same standing access, because no one changed it between tasks.
This is not negligence. It is the default behavior of almost every AI coding setup. Access is granted once, at setup time, and it persists across every subsequent run unless someone actively revokes it.
The problem is not that the agent will misuse the access. The problem is that persistent, broad access is a surface area that nobody is actively reviewing. It is open, it is broad, and it sits outside the normal review loop.
Access scoped to the task, not to the session
The comparison
Persistent broad access
- Granted once at setup
- Remains open between tasks
- Surface grows with team size
- Nobody is reviewing the idle state
- Incidents require retroactive investigation
Scoped task access
- Declared at task start
- Bounded by file scope
- Revoked when task exits cleanly
- Receipt records what was touched
- Surface is zero when no task runs
Why the idle state matters
Teams focus access review on active work. What is the agent doing right now? What files is it changing? These are the right questions during a run. But they are not the only questions.
Between runs, a persistent broad access grant is sitting idle. It is not doing anything. It is also not doing nothing: it represents an access surface that exists outside any active review. If anything uses that surface unexpectedly, the response is retroactive investigation, not prevention.
The safest idle state for an AI agent is no access. Not minimal access. Not scoped-but-persistent access. No access, restored at task start and revoked at task end.
How this works without slowing down
Task-scoped access feels like friction until it is automatic. When the access grant and revocation happen as part of the run lifecycle, the developer does not manage it manually. The task starts, access is granted to the declared scope, the task completes, access is revoked.
The developer sees the receipt. The access state is zero. The next task starts with a clean grant for its own scope.
This is not a security theater exercise. It is an architectural constraint that makes the access surface observable, bounded, and reviewable by default, without requiring any additional developer action.
What to look for in your own setup
- Access grants that were created at setup and have not been reviewed since
- Agents that operate with repo-wide write access regardless of task scope
- No visibility into what access an agent holds between tasks
- Access review that only happens after an incident
If you cannot answer "what access does the AI agent have right now, between tasks?" the answer is probably more than you intended to give it.
Access should close when the task closes.
Avorelo scopes access to each task automatically. Zero surface between runs, zero manual revocation required.
Start free in your repo