💻 computer science

Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents

The paper introduces PORTICO, a reference monitor that mitigates "lingering authority" in coding agents by enforcing a revocable, lifecycle-based capability system that dynamically grants and retracts resource access, thereby preventing post-episode forbidden effects without compromising task success.

Original authors: Igor Santos-Grueiro

Published 2026-06-23

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Igor Santos-Grueiro

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

The Core Problem: The "Key That Won't Go Away"

Imagine you hire a very capable but slightly over-eager construction worker (the Coding Agent) to fix a leak in your kitchen sink.

The Job: They need a wrench and access to the pipes under the sink.
The Mistake: To be helpful, you give them a master key to your entire house. This key opens the kitchen, the bedroom, the safe, and the front door.
The Danger: Once they finish fixing the sink, they still have that master key. Even though they are done with the kitchen, they might accidentally (or maliciously) wander into your bedroom or try to open the safe because the key still works.

In the world of AI coding agents, this is called "Lingering Authority." The AI is given broad access to your files and tools to do a specific task. Once that specific part of the task is done, the AI often keeps that access, even though it shouldn't need it anymore. This leaves your digital house vulnerable.

The Solution: PORTICO (The Smart Security Guard)

The authors built a system called PORTICO. Think of PORTICO as a strict security guard who stands between the construction worker and your house.

Instead of giving the worker a master key, PORTICO operates on a "Request-Grant-Revoke" system:

The Initial Envelope: The worker starts with a small, specific box of tools (e.g., just the wrench and the kitchen door key).
The Request: If the worker needs to fix the bathroom next, they must ask the guard: "I need to go to the bathroom."
The Grant (The Temporary Pass): If the guard sees this is part of the job, they hand over a temporary pass (a digital handle) that only opens the bathroom door.
The Revoke (The Expiration): As soon as the bathroom is fixed, the guard takes the pass back. The bathroom door is locked again. The worker can no longer open it, even if they try to use the old pass.

How It Works in Practice

The paper describes a specific scenario: Propagating a "Timeout" setting.

Step 1: The AI needs to read a file called api.py. PORTICO gives it a "read handle" for just that file.
Step 2: The AI realizes it needs to change a file called serialization.py. It asks PORTICO.
Step 3: PORTICO checks the rules. It says, "Okay, that's part of the job," and issues a temporary handle for serialization.py.
Step 4: The AI makes the change. The task for that file is done.
Step 5 (The Critical Moment): The AI tries to read serialization.py again later to "check its work" or perhaps to sneak a peek at a different file.
- Without PORTICO: The AI still has the key. It succeeds.
- With PORTICO: The temporary handle has expired. The guard says, "Nope, your pass is dead." The AI cannot open the file.

The "Lingering" vs. "Revoked" Test

The researchers tested this by comparing two systems:

The "No-Revocation" System: This system gives the AI the temporary pass, lets it do the work, but never takes the pass back.
The PORTICO System: This system takes the pass back immediately after the job is done.

The Results:

Both systems successfully finished the main coding tasks (fixing the leak).
However, when the AI tried to use those old, expired passes after the job was done:
- The No-Revocation system let the AI open 10 out of 10 files it shouldn't have.
- PORTICO blocked all 10 attempts.
In a test where the AI tried to write to a file using an expired pass, PORTICO stopped it every time. The other system let it happen, potentially causing damage.

Why This Matters

The paper argues that security isn't just about blocking bad things; it's about limiting access to only what is needed right now.

Old Way: "Here is the whole house. Don't touch the safe." (Risky, because the AI might forget or get tricked).
PORTICO Way: "Here is the kitchen key. When you are done, I take it back. If you need the bathroom key later, ask me again."

The Trade-off

The paper admits there is a small cost. Because PORTICO is so strict, sometimes the AI gets "stuck" and asks for permission to do something it should be allowed to do, but the rules are too tight. This is called "blocked proposals."

PORTICO blocks more of these requests to be safe.
The "All-Visible" system lets the AI see more options, which makes it faster, but leaves the "lingering authority" risk open.

Summary

This paper introduces a way to stop AI coding assistants from holding onto "keys" to your computer longer than necessary. By using a system that grants temporary access and immediately revokes it when the specific task is done, PORTICO ensures that even if the AI tries to wander off or get tricked, it physically cannot access files it no longer has permission to touch. It turns "permanent access" into "temporary, expiring passes."

Technical Summary: Lingering Authority in Coding Agents

Problem Definition: Lingering Authority

The paper identifies a specific security gap in coding agents termed lingering authority. Coding agents often receive broad tool access for an entire task, even when a specific resource or effect is only required for a single subgoal. The core problem is temporal: authority justified for one subgoal remains exposed in the planner's interface after that subgoal closes.

While existing defenses address hostile content, tool trust, and execution-time checks, they often leave the planner interface itself exposed to capabilities that are no longer justified. If a broad read option remains visible to the planner after a subgoal ends, the model may continue to plan around it, creating a security state where temporary capabilities persist beyond their justification. The paper argues that the exposed interface is part of the security state, distinct from runtime reachability or sandbox boundaries.

Methodology: PORTICO Reference Monitor

The authors introduce PORTICO, a reference monitor designed to enforce bounded capability lifetimes for coding agents. PORTICO operates under a fixed host isolation model and relies on explicit task contracts and a sound, typed tool catalog.

Core Mechanisms

PORTICO compiles a task contract into four components:

Initial Envelope ( $E_0$ ): The set of capabilities exposed at the start of the task.
Grant Rules ( $\Gamma$ ): Rules defining how temporary authority can be expanded via explicit requests.
Closure Rules ( $\Lambda$ ): Predicates (e.g., test pass, phase exit, subgoal completion) that trigger the revocation of temporary authority.
Global Deny Rules ( $G$ ): Invariants such as forbidden network hosts or credential file access.

The Request–Grant–Invoke Lifecycle

PORTICO materializes expansions as opaque, epoch-bound handles.

Request: The planner can request authority based on declared rules, but cannot create new authority.
Grant: If a rule matches, the monitor mints a handle for the specific resource/effect/phase. This handle is added to the next planner interface.
Invoke: Execution is permitted only if a valid, live handle is present.
Closure: When a closure event (e.g., a trusted test result) occurs, the monitor removes the corresponding handles from the planner interface. Subsequent attempts to use the stale handle are rejected before side effects occur.

Crucially, revocation removes the authority from the interface but leaves the context (e.g., file names in conversation) intact. The planner can no longer select the tool for that resource without a fresh grant.

Key Contributions

The paper makes three primary contributions:

Definition of No-Stale-Use: It defines the requirement that authority from a closed grant must disappear from later planner interfaces and be invalid at execution time.
Formalization and Implementation: It formalizes exposure minimality, justified expansion, and authority closure around a request–grant–invoke protocol. These are implemented in PORTICO using epoch-bound handles.
Empirical Evaluation: It evaluates bounded lifetimes on controlled fixtures and pinned real repositories, demonstrating reduced post-closure stale-capability availability compared to non-revoking designs.

Experimental Results

The evaluation uses three controlled fixture suites (A–C) and one real-repository suite (D), comparing PORTICO against baselines (Full Access, Static Allowlist, Coarse Sandbox) and specific comparators (Non-Revoking, All-Visible Same-Policy).

Key Findings

Minimization (RQ1): PORTICO variants drive policy violations and "blast radius" (sensitive resources reached) to 0.00 in Suite A, whereas full access and static allowlists show significant violation rates (1.00 and 0.82, respectively).
Justified Expansion (RQ2): PORTICO Core (initial envelope only) is safe but brittle, failing many tasks that require boundary expansion (0.21 success in Suite B). PORTICO Full recovers legitimate boundary work, achieving 0.87 success in Suite B while maintaining 1.00 scope compliance and 0.00 violations.
Closure (RQ3): This is the paper's primary differentiator. A Non-Revoking Comparator (which receives the same grants at the same times but never removes them) matches PORTICO on task success and pre-closure decisions. However, on post-closure re-reads:
- PORTICO Full: Denies 10/10 post-closure reuse attempts.
- Non-Revoking Comparator: Allows 10/10 post-closure reuse attempts.
- Stale-Effect Audit: In deterministic tests involving file writes, git mutation, and network egress, PORTICO executes 0/6 forbidden effects, while the non-revoking comparator executes 6/6.
Interface Breadth (RQ3): An All-Visible Same-Policy Comparator (broad interface, same execution policy) matches PORTICO on executed forbidden effects (0/20) but generates significantly more blocked proposals (84 vs. 67), indicating that a broader interface increases planning pressure even if execution is eventually denied.
Real Repositories (RQ4): On pinned real Python repositories (Flask, Requests, etc.), PORTICO Full successfully materializes temporary grants and enforces closure, maintaining scope compliance and zero violations across 14 contracts.

Significance and Claims

The paper claims that PORTICO successfully isolates the "lifetime" of authority as a distinct security variable. The key finding is that a system can preserve task success and scope compliance before closure while still leaving temporary capabilities available after closure if revocation is not enforced.

The authors position PORTICO not as a replacement for sandboxing or content defenses, but as a complementary layer that makes temporary capabilities explicit, bounded, and auditable. The significance lies in the demonstration that revocation is necessary to prevent lingering authority, even when the execution policy and grant timing are identical to a non-revoking system.

The paper remains modest regarding its scope:

It assumes a trusted typed tool catalog and mediated execution; it does not claim to protect against unmediated shell commands or sandbox bypasses.
It acknowledges that contract quality is a deployment input; poor contracts can lead to under-granting (blocking work) or over-granting (exposing risk).
It notes a utility cost: PORTICO Full trades some raw completion rates for stricter scope control, resulting in visible "safe incompleteness" rather than hidden over-broad success.

Ultimately, the work argues that for coding agents, the planner interface itself must be dynamic, shrinking as justifications expire, rather than remaining a static, broad menu of admissible tools.