Lingering authority: revoking coding-agent capabilities after a task closes

What is this?

A June 2026 preprint (arXiv:2606.22504) puts a name to a failure mode that most coding-agent deployments never measure: lingering authority. The idea is simple. A coding agent is usually handed broad tool access for an entire task — read and write across the repository, run tests, mutate git, reach the network — even when a given resource is only needed for one narrow subgoal. Once that subgoal closes, the capability is still exposed on the agent’s tool interface. The paper’s framing is that the temporary authority has degraded into standing authority: “a temporary resource/effect capability remains exposed after the episode that justified it has closed.”

The problem is fundamentally temporal, not a bug in any single tool. Every grant was legitimate at the moment it was made. What is missing is the second half of least privilege — taking authority back when the reason for it ends. The study argues the exposed tool interface is itself part of the security state, and it maps cleanly to a category the OWASP Top 10 for Agentic Applications (December 2025) calls identity and privilege abuse: an agent operating with more effective authority than its current step requires.

How it works

The threat model assumes an untrusted planner. The agent’s plan is steered by ordinary inputs it must read anyway — repository files, issue text, retrieved documentation, tool descriptors and protocol metadata, and misleading tool outputs — which is exactly the surface that indirect prompt injection rides on. The paper’s point is that an attacker does not need a runtime compromise or a sandbox escape. A legitimate tool that still carries surplus, no-longer-needed capability is enough.

The canonical example is a scoped repair task. The agent is granted write access to one file to propagate a change, the focused tests pass, and the subgoal is done — but the write handle is still live. Later in the same run, a manipulated instruction reuses that stale handle to write somewhere it was never authorized, or to reread a sensitive path that was only ever justified for the earlier step. No new permission was requested; the agent simply replayed authority that should have been closed.

The defense the authors propose, PORTICO, is a reference monitor for revocable capabilities. It compiles an explicit task contract into an initial envelope, grant rules, trusted closure predicates, and global deny rules, then runs a request–grant–invoke lifecycle. Grants mint opaque, epoch-bound handles for a specific resource and effect. When a closure condition fires, those handles are removed from the next planner interface and any replay is rejected before it can produce a side effect. Crucially, only trusted events — monitor-run tests passing, an orchestrator phase exit, an authenticated human approval — can grant or close authority. A planner-authored line of text claiming “subgoal complete” is logged as untrusted and cannot reopen a closed epoch.

Why it matters

The measured gap between revoking and not revoking is stark. In the paper’s post-closure audit, a non-revoking comparator that received the exact same grants at the same turns executed 6 of 6 contract-forbidden effects when a stale handle was replayed; the revoking monitor executed 0 of 6. On a late-reread slice, the non-revoking setup permitted 10 of 10 stale reuses while the monitor denied 10 of 10 — with both matching on task success and scope up to the moment of closure. The split held across file writes, git mutation, and network egress, on real Python projects (Flask, Requests, HTTPX, Click, Jinja, Werkzeug and others) and across an evaluated model set that included Qwen3-Coder, GPT-5.5, Gemini 3.5 Flash and Claude Opus 4.8. The lesson generalizes beyond one monitor: if your agent framework never revokes a capability, every grant it ever makes is effectively permanent for the rest of the run.

Defenses

The actionable takeaways do not depend on adopting any specific tool:

Add the missing half of least privilege. Least privilege at grant time is not enough for agents. Bind each capability to a tool, resource, effect class, phase and epoch, and enforce a no-stale-use rule: once the justifying subgoal closes, the handle should disappear from the interface and any replay should be rejected before side effects.

Let only trusted events change authority. The agent’s own narration is untrusted input. Grants and revocations should be driven by monitor-observed signals — tests passing, phase transitions, authenticated human approval — never by a model-generated claim that a step is done.

Revoke the interface, not the memory. Revocation is about what the agent can still invoke through a mediated path, not about erasing conversation history. This only works if tool paths are actually mediated; unmediated shell, file or network access sits outside the guarantee.

Layer it. The authors are explicit that this complements, rather than replaces, host isolation, credential management, human-in-the-loop approval for unusual expansions, and audit review. Capability governance is one control among several — see related work such as SAGA on governing agent identities and permissions.

Status

Item	Reference	Notes
Core concept	arXiv:2606.22504, June 2026	”Lingering authority”: temporary capability stays exposed after its subgoal closes
Proposed defense	PORTICO reference monitor	Request–grant–invoke lifecycle; epoch-bound handles; trusted closure predicates
Post-closure audit	Same paper	Non-revoking comparator 6/6 forbidden effects executed; revoking monitor 0/6
Framework mapping	OWASP Top 10 for Agentic Applications, 2025-12	Identity & privilege abuse (over-authority relative to current step)
Evaluated stack	Same paper	File/git/network effects on real repos; Qwen3-Coder, GPT-5.5, Gemini 3.5 Flash, Claude Opus 4.8

The durable point is that autonomy plus un-revoked authority is what turns a single injected instruction into an executed effect. Grants are only as safe as the mechanism that takes them back.