Revoking lingering agent access beats static sandboxes
New research targets a real weak spot in coding agents: lingering permissions. PORTICO enforces revocable, epoch-bound handles tied to explicit task contracts. In tests, it blocks post-closure reuses (10/10) and stale writes (0/6 vs 6/6), eliminates contract-forbidden effects, and preserves utility via controlled grants. Assumptions about mediation and catalogues still matter.
Everyone is busy talking about prompt injection while ignoring a simpler failure mode: agents keep hold of tools long after the reason for access has ended. That lingering authority is how you get a code assistant quietly pushing to git or calling out to the network after the subtask is done. The lab sandbox may be intact; your process still took a hit.
A new paper names the problem and ships a design that actually bites. PORTICO is a reference monitor for coding agents that compiles an explicit task contract and a typed tool catalogue into a policy: an initial capability envelope, grant rules, trusted closure predicates, and global denies. It mediates a clean request–grant–invoke flow. When the planner asks, it gets an opaque, epoch-bound handle for the next turn. When the subgoal closes, those handles vanish from the planner interface and any stale handle is rejected at execution with linearisable validation.
The exploit path is boring and effective
An adversary does not need wizardry. Seed a repository file, an issue, or a tool output that nudges the planner to request a temporary write or network egress for a legitimate subgoal. Later, trigger reuse once the subgoal has closed. In non-revoking designs this works. The paper’s comparator allowed 10 out of 10 post-closure reuses, and a deterministic stale-write audit recorded 6 out of 6 executed forbidden effects. With PORTICO the same traces hit a wall: 10 out of 10 reuses rejected, 0 out of 6 forbidden stale writes executed. That is the point of revocation.
Revocation restores utility without spilling scope
Static narrow envelopes are safe but useless. PORTICO’s controlled grants kept scope clean while recovering work: in one suite, success jumped from 0.21 to 0.87 with zero measured violations. In controlled fixtures it drove contract-forbidden effects to zero across file writes, git mutation, and network egress. Real-repository runs on 14 pinned Python projects repeated the lifecycle: all six test conditions completed with 14 out of 14 scope and 0 out of 14 executed forbidden effects; only PORTICO actually materialised temporary grants. One nuance: making more tools visible to the planner did not worsen executed safety but did raise the number of blocked forbidden proposals, a hint that wide interfaces increase planning pressure even when enforcement holds.
There are caveats. PORTICO assumes complete mediation, a sound typed catalogue, and trusted closure events. It does not fix sandbox bypass, compromised kernels, unmediated tools, or covert channels. Contracts can undergrant and stall work, or overgrant and widen exposure. Still, the uncomfortable truth stands: if you do not revoke, you do not contain. Epoch-bound handles and closure semantics solve the problem that static sandboxes pretend does not exist. Ship agents that ignore lifecycle and you are betting the house on good behaviour after the door is left open.
Additional analysis of the original ArXiv paper
📋 Original Paper Title and Abstract
Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents
🔍 ShortSpan Analysis of the Paper
Problem
This paper studies lingering authority: coding agents are often given temporary resource or effect capabilities for a subgoal but keep them exposed to the planner after the subgoal closes. That residual authority can enable post‑closure reads, writes, version‑control mutations or network egress that were not justified by the current task phase, increasing attack surface even when lower‑level sandboxes remain in place.
Approach
PORTICO is a reference monitor that compiles an explicit task contract and a typed tool catalogue into a policy object containing an initial capability envelope, grant rules, trusted closure predicates and global deny rules. It mediates a request–grant–invoke lifecycle: requests produce epoch‑bound, opaque handles for the next planner turn; closure events remove those handles from the planner interface and cause execution‑time rejection of stale handles. The monitor assumes fully mediated tools, a sound typed catalog and linearisable handle validation at execution. Evaluation uses controlled fixture suites (A–C) and a pinned real‑repository suite (D) to measure exposure, justified expansion, closure behaviour, and stale‑effect audits across file writes, git mutation and network egress using live and scripted model traces.
Key Findings
- Portico eliminates executed contract‑forbidden effects in the tested fixtures: Portico variants drove violations and blast radius to 0.00 in Suite A (0/17 scenarios, 0/85 executions recorded violations) compared with high violation rates under full access.
- Justified expansion recovers legitimate cross‑boundary work: Portico core (initial envelope only) preserved scope but underblocked utility; Portico full (request–grant–invoke with trusted closure) improved Suite‑B success from 0.21 to 0.87 while retaining 100% scope compliance and zero measured violations.
- Closure prevents post‑closure reuse and stale effects: in a late‑reread diagnostic Portico rejected 10/10 post‑closure reuses while a non‑revoking comparator allowed 10/10. A deterministic stale‑write audit recorded 0/6 forbidden effects under Portico versus 6/6 under the non‑revoking comparator; scripted and six live model traces showed the same split across file, git and network effects.
- Broader planner visibility raises blocked proposals without improving executed safety: an all‑visible same‑policy comparator matched Portico on executed forbidden effects but logged more blocked forbidden proposals in some diagnostics, indicating higher planning pressure from a broader interface.
- Real‑repository experiments reproduced the lifecycle: on 14 pinned Python projects all six test conditions completed contracts with 14/14 scope and 0/14 executed forbidden effects; only Portico materialised temporary grants across those contracts.
Limitations
Guarantees depend on complete mediation, a sound typed catalogue, and trusted closure events; Portico does not address sandbox bypass, compromised kernels, unmediated tool use, or covert channels. Contract quality matters: undergranting blocks legitimate work, overgranting raises initial exposure. Utility can decline when trusted reauthorisation paths are absent. Experiments are scoped to coding‑agent toolsets and pinned or synthetic repositories; other tool domains remain untested.
Implications
Offensively, an adversary can exploit lingering authority in non‑revoking deployments by seeding repository files, issue text, tool metadata or outputs that cause the planner to request temporary capabilities and later trigger post‑closure misuse; this can enable stale file writes, git mutations or network egress after a subgoal completes. Portico’s epoch‑bound handles, closure semantics and stale‑replay rejection materially reduce that avenue by removing capabilities from the planner interface and auditing handle lifetimes, but attackers retain leverage where mediation is incomplete or contracts are overbroad.
