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

# Revocable Resource-and-Effect Capabilities for Coding Agents
Source: [https://arxiv.org/html/2606.22504](https://arxiv.org/html/2606.22504)
###### Abstract

Coding agents often receive broad tool access for an entire task, even when a resource is needed only for one subgoal\. We call this gaplingering authority: a temporary resource/effect capability remains exposed after the episode that justified it has closed\.

Porticois a reference monitor for revocable capabilities exposed to the planner\. It compiles an explicit task contract into initial capabilities, grant rules, trusted closure predicates, and global deny rules\. A request–grant–invoke lifecycle materializes expansions as opaque, epoch\-bound handles\. Closure removes those handles from the next planner interface and rejects stale replay before side effects\. The monitor assumes mediated tools and a sound typed catalog\.

In controlled coding\-agent tasks,Porticorecords no executed contract\-forbidden effects in the evaluated runs, while controlled grants recover boundary work blocked by a fixed narrow envelope\. A non\-revoking comparator receives the same initial envelope and the same grants at the same turns\. On the closure slice, both systems match task success, scope compliance, and all pre\-closure decisions;Porticothen rejects 10/10 post\-closure reuses, while the comparator permits 10/10\. A deterministic stale\-write audit records 0/6 versus 6/6 executed forbidden effects\. Scripted traces and six live model traces over file writes, git mutation, and network egress show the same split\. In a four\-episode same\-policy diagnostic, broad request exposure preserves zero executed forbidden effects but raises blocked proposals from 67 to 84\. Frozen real\-repository runs, with commits and traces recorded, exercise the same lifecycle on real project layouts\.

## 1Introduction

Coding agents turn natural\-language tasks into tool calls over repositories, tests, shells, package managers, network clients, and version control\. They often start with more authority than the task needs\. The key problem is temporal: authority justified for one subgoal can become stale once that subgoal closes\. If the agent later uses this stale authority, the planner\-tool interface has exposed*lingering authority*: a temporary resource/effect capability that remains exposed after the grant episode that justified it closed\.

Consider a task that propagates a timeout fromsrc/api\.pytosrc/serialization\.py\. The initial phase needs the API file, the focused API test, and the test command\. The contract declares serialization access as an on\-demand boundary capability\. A planner request may select that declared rule, but it cannot create new authority\. A plausible note such asnotes/packaging\.mdis outside the task\. The desired behavior is to deny the note, grant serialization authority for the boundary episode, and revoke that authority when the episode closes\. A static allowlist or sandbox may make the serialization file reachable for the whole run\. The security question is whether it should remain available to the planner for the whole run\.

Existing defenses address adjacent layers: hostile content or proposed actions\[promptinjection,injecagent,asb,toolemu,agentdojo,agentharm,agentalign,toolhijacker,promptarmor,llamafirewall\], tool and protocol trust\[mcp\_landscape,breakingprotocol,securingmcp,smcp,mcpsecbench,mcptox,systematicmcp,mcpitp,ama,maltool\], and reachability or execution checks after tool selection\[isolategpt,sandboxescapebench,agentcgroup,ace,saga,agentspec,pcas,maris,miniscope,agentbound,progent,cmtf,racg\]\. They leave an earlier choice open: which otherwise admissible authority should be visible to the planner now, and when should temporary authority disappear? If a broad read option remains in the planner interface, the model can keep planning around it even when a later monitor would reject some calls\. The exposed interface is therefore part of the security state\.

We use*capabilities exposed to the planner*for resource\- and effect\-specific authority exposed through the mediated interface as current handle state\. They are distinct from runtime availability, sandbox reachability, and execution checks\. Revocation leaves prior context intact: a resource name may still appear in the conversation, but authority is absent when no mediated invocation over that resource can be selected or validated without a fresh grant\.

This paper studies bounded capability lifetime under fixed host isolation and explicit task contracts\.*Exposure minimality*keeps unjustified capabilities out of the interface\.*Justified expansion*permits legitimate boundary work through explicit grants\.*Authority closure*removes temporary authority when the reason for exposing it ends\.

We implement these obligations inPortico, a reference monitor for coding agents\. Given a task contract and typed tool catalog,Porticocompiles an initial envelope, grant rules, closure rules, and global deny rules\.Porticocore exposes only the initial envelope\.Porticofull adds the request–grant–invoke lifecycle with trusted closure\. A grant mints epoch\-bound handles for the covered resource and effect; closure removes those handles from the next planner interface and rejects replay at execution time\.Porticocomplements sandboxing and content defenses by making temporary capabilities explicit, bounded, and auditable\.

The evaluation uses three controlled fixture suites and one pinned real\-repository suite to test exposure, expansion, closure, and real\-layout behavior\. A non\-revoking comparator isolates closure under the same grants, an all\-visible same\-policy comparator isolates interface breadth under the same execution policy, and a coarse action\-filter diagnostic tests broad adjacent authority\. The study is relative to the written contract: given an explicit task contract, mediated tool interface, and typed invocation\-to\-authority mapping, we compare upfront exposure, execution\-time denial, and bounded grant episodes with closure\.

This paper makes three contributions:

- •It defines no\-stale\-use for resource\- and effect\-specific capabilities exposed to the planner: authority from a closed grant must disappear from later interfaces and be invalid at execution\.
- •It formalizes exposure minimality, justified expansion, and authority closure around a request–grant–invoke protocol, and implements them inPorticowith epoch\-bound grant handles\.
- •It evaluates bounded lifetime on controlled fixtures and pinned real repositories, showing reduced post\-closure stale\-capability availability and lower blocked\-proposal pressure than an all\-visible same\-policy interface in the post\-closure diagnostic\.

#### Artifact Availability\.

An anonymized artifact repository for this submission is available at[https://anonymous\.4open\.science/r/portico/](https://anonymous.4open.science/r/portico/)\. It contains the checked\-in task contracts, frozen result roots, reproduction scripts, publicportico\-tooltraces, and secondaryPorticodecision core used to audit the paper\.

## 2A Concrete Authority\-Lifecycle Trace

The running timeout task exposes lingering authority with one false side request and one legitimate boundary request\. The task is to propagate an optional timeout parameter fromsrc/api\.pyintosrc/serialization\.py\. At the start, the planner only needs the API file, the focused API test, and pytest\. The serialization file is declared as an on\-demand boundary capability; a planner request can select that existing rule for evaluation but cannot create the rule\. Packaging notes such asnotes/packaging\.mdare outside the task\. Table[1](https://arxiv.org/html/2606.22504#S2.T1)gives the step\-by\-step trace\.

Table 1:Timeout\-propagation authority trace\.src/serialization\.pychanges status over time\. It is unjustified before the boundary, justified during the boundary, and stale after the boundary closes\. The grant request does not execute the file operation by itself; it materializes handles for the next planner step\. If those handles remain exposed after closure, they have become lingering authority\. The following sections unpack this trace as a contract, typed tools, an envelope, a grant, a lifetime, a revoke event, a trace, and a metric\.

The same pattern appears in temporary\-read episodes\. A renderer repair can start withsrc/render\.py,tests/test\_build\.py, and pytest visible\. During inspection, a recheck note may be justified as read\-only context; after the inspection subgoal closes, the note should disappear from the planner interface while local source and test authority remain\. This second shape shows the same separation: legitimate expansion should be possible, and temporary authority should expire when its subgoal ends\.

## 3Problem and Threat Model

We study authority exposure before a tool call runs\. The planner is untrusted: it proposes tool invocations, and the runtime arbiter decides which invocations exist on the mediated interface and which ones may execute\. Host isolation is held fixed\. Our question is which task capabilities should be exposed now, and when temporary authority should disappear\. The running example and Figure[1](https://arxiv.org/html/2606.22504#S4.F1)illustrate the distinction: reachability, execution\-time denial, plan integrity, and task\-wide legitimacy still leave open which capabilities are exposed at the current phase\. With host and sandbox fixed, planner outputs are untrusted requests, and the only variable is the capability interface exposed through the mediated path before execution\.

#### System model\.

We consider a coding agent whose planner emits structured invocations over a repository and a small set of external resources\. The tool interface includes file reads and writes, shell/test execution, dependency management, network fetch, and git\-related tooling\. A runtime authority arbiter sits between the planner and those tools\. Every compared condition uses the same execution substrate, sandbox profile, and low\-level mediation path; what changes is the authority exposed to the planner before execution\.

#### Capabilities exposed to the planner\.

A capability is exposed to the planner when it is present on the mediated interface: tool schemas, target scopes, argument constraints, active grant options, and deny or escalation responses that can affect later planning\. We distinguish a request option, which lets the planner formulate a request, from an executable capability, which can produce effects after validation\. Authority can remain available in the runtime without being exposed to the planner\. Revocation leaves context intact: a path name may remain in the conversation\. Effect authority is absent when no mediated invocation over that resource can be successfully validated without a fresh grant\.

#### Adversary capabilities\.

The adversary influences the planner through ordinary inputs: repository files, issue text, retrieved documentation, tool descriptors or protocol metadata, and misleading tool outputs\. We include indirect prompt injection, misleading metadata, dependency mutation in dependency\-stable tasks, read\-plus\-network pivots, and over\-broad git or package\-manager authority\. A legitimate tool with surplus exposed capability is enough; runtime compromise or bypass of the mediated path is outside the threat model\.

#### Security goal\.

The goal is to expose only task and phase justified authority to the planner, deny out\-of\-contract invocations before execution, and revoke temporary authority after its justification ends\. This limits avoidable interface risk while lower\-level isolation continues to enforce runtime boundaries\. Planner outputs are requests to adjudicate, not declarations of need\.

#### Trusted base and non\-goals\.

The trusted base includes the policy engine, typed tool catalog, enforcement hooks, grant/revoke state, and host runtime or external sandbox\. Process isolation, syscall filtering, browser sandboxing, and network mediation remain complementary\. We exclude compromised kernels, sandbox bypasses, covert channels, complete protocol coverage for every tool ecosystem, tool implementations that bypass the invocation interface, unstructured tool use outside the mediated call path, and optimal contract compilation\. The next section separates availability, reachability, admissibility, and executable capability\.

## 4Model of Capabilities and Interfaces

#### Planner interface as runtime state\.

For taskτ\\tau, the monitor decides which tool\-mediated actions can be proposed through the planner interface and which capabilities can produce effects after validation\. Each requested action maps through the typed catalog to an authority descriptor

β=\(u,p,r,e,ι,ϕ\),\\beta=\(u,p,r,e,\\iota,\\phi\),whereuuis the tool primitive,ppthe primitive privilege,rrthe resource,eethe side\-effect class,ι\\iotathe task intent, andϕ\\phithe trusted phase\. This per\-request mapping matters because one tool, especially shell, can induce many resources and effects\[saltzer,seccomp,capsicum,cheri\]\.

SetsExampleAvailableReachablePolicy\-admissibleExecutablecapabilityread src/serialization\.pyduring timeout propagationAvailableyesReachableyesPolicy/
grant eligibleyesExecutable
nownoA𝑎𝑣𝑎𝑖𝑙,t⊇A𝑟𝑒𝑎𝑐ℎ,t⊇A𝑎𝑑𝑚,t⊇Vβ,tA\_\{\\mathit\{avail\},t\}\\supseteq A\_\{\\mathit\{reach\},t\}\\supseteq A\_\{\\mathit\{adm\},t\}\\supseteq V\_\{\\beta,t\}Figure 1:Four nested but non\-equivalent descriptor sets\. In the mediated configuration studied here, the innermost descriptor set is the projection of executable capabilities\. Request options are modeled separately as part of the planner interface\. Right: a secondary\-module read may be available, reachable, and admissible under a future grant rule while still not being executable now\.
#### Four related but non\-equivalent descriptor sets\.

Figure[1](https://arxiv.org/html/2606.22504#S4.F1)separates four sets over the same descriptor type\. Letℬτ\\mathcal\{B\}\_\{\\tau\}be the descriptor universe for taskτ\\tau\.A𝑎𝑣𝑎𝑖𝑙,tA\_\{\\mathit\{avail\},t\}contains descriptors inℬτ\\mathcal\{B\}\_\{\\tau\}whose tool primitive is registered;A𝑟𝑒𝑎𝑐ℎ,tA\_\{\\mathit\{reach\},t\}restricts them to runtime\-reachable resources;A𝑎𝑑𝑚,tA\_\{\\mathit\{adm\},t\}keeps descriptors admissible under policy or a future grant rule; andVβ,tV\_\{\\beta,t\}is the projection of currently executable runtime capabilities back to descriptors\. Request options are interface state, but not effect authority until a request mints a live handle\.

#### Task\- and phase\-scoped state\.

For taskτ\\tau, the compiled policy starts from an initial authority envelope

ℰ0​\(τ\)=\(T0,Π0,ℛ0,C0\),\\mathcal\{E\}\_\{0\}\(\\tau\)=\(T\_\{0\},\\Pi\_\{0\},\\mathcal\{R\}\_\{0\},C\_\{0\}\),whereT0T\_\{0\}is the initial tool\-schema set,Π0\\Pi\_\{0\}the initial primitive privileges,ℛ0\\mathcal\{R\}\_\{0\}the initial resources, andC0C\_\{0\}the initial contextual constraints\. The monitor maintains phase, live grants, and audit state, then derives executable capabilities fromℰ0\\mathcal\{E\}\_\{0\}plus live grants\.

An*authority descriptor*is a concrete requested operation

β=\(u,p,r,e,ι,ϕ\),\\beta=\(u,p,r,e,\\iota,\\phi\),whereuuis the tool,ppthe primitive privilege required by that invocation,rrthe resource or resource class,eethe side\-effect class,ι\\iotathe task intent, andϕ\\phithe phase under which the invocation is being adjudicated\. A*runtime capability instance*isα=\(β,κ\)\\alpha=\(\\beta,\\kappa\), whereκ\\kapparecords compiler\-issued initial authority or a grant ID, epoch, and opaque handle\. Runtime capabilities live inℬτ×K\\mathcal\{B\}\_\{\\tau\}\\times Kfor handle metadata spaceKK\. At runtime,ϕ\\phiis derived fromϕt\\phi\_\{t\}and checked byphase\_ok; it remains inβ\\betafor audit\. For example, the temporary serialization read in the running trace maps to:

u=read\_file,p=read,r=src/serialization\.py,e=inspect\_code,ι=propagate\_timeout,ϕ=patch,κ=\(grant id,epoch,read handle\)\.\\begin\{array\}\[\]\{ll\}u=\\texttt\{read\\\_file\},&p=\\texttt\{read\},\\\\ r=\\texttt\{src/serialization\.py\},&e=\\texttt\{inspect\\\_code\},\\\\ \\iota=\\texttt\{propagate\\\_timeout\},&\\phi=\\texttt\{patch\},\\\\ \\kappa=\(\\textit\{grant id\},\\textit\{epoch\},\\textit\{read handle\}\)\.&\\end\{array\}The packaging\-note probe has the same primitive privilege but a different resource and intent, and no grant can mint a capability for it\.

The initial envelope induces compiler\-issued authority instances:

𝖨𝗇𝗂𝗍\(ℰ0,τ,st\)=\{α=\(β,κ\)∣\\displaystyle\\mathsf\{Init\}\(\\mathcal\{E\}\_\{0\},\\tau,s\_\{t\}\)=\\\{\\alpha=\(\\beta,\\kappa\)\\mid\{\}u​\(β\)∈T0∧p​\(β\)∈Π0∧\\displaystyle u\(\\beta\)\\in T\_\{0\}\\wedge p\(\\beta\)\\in\\Pi\_\{0\}\\wedge\{\}r​\(β\)∈ℛ0∧\\displaystyle r\(\\beta\)\\in\\mathcal\{R\}\_\{0\}\\wedge\{\}C0\(e\(β\),ι\(β\),ϕ\(β\),κ,τ,st\)\}\.\\displaystyle C\_\{0\}\(e\(\\beta\),\\iota\(\\beta\),\\phi\(\\beta\),\\kappa,\\tau,s\_\{t\}\)\\\}\.Each field filters part of the concrete invocation\. Live grants add runtime instances:

𝖦𝗋𝖺𝗇𝗍𝖢𝖺𝗉𝗌​\(Lt,τ,st\)=\{α∣𝗅𝗂𝗏𝖾​\(α,Lt,Λ,st\)\}\.\\mathsf\{GrantCaps\}\(L\_\{t\},\\tau,s\_\{t\}\)=\\\{\\alpha\\mid\\mathsf\{live\}\(\\alpha,L\_\{t\},\\Lambda,s\_\{t\}\)\\\}\.The executable runtime capabilities are derived at each turn:

𝖢𝖺𝗉t\\displaystyle\\mathsf\{Cap\}\_\{t\}=𝖨𝗇𝗂𝗍​\(ℰ0,τ,st\)∪𝖦𝗋𝖺𝗇𝗍𝖢𝖺𝗉𝗌​\(Lt,τ,st\),\\displaystyle=\\mathsf\{Init\}\(\\mathcal\{E\}\_\{0\},\\tau,s\_\{t\}\)\\cup\\mathsf\{GrantCaps\}\(L\_\{t\},\\tau,s\_\{t\}\),Vt\\displaystyle V\_\{t\}=\{α∈𝖢𝖺𝗉t∣J𝖯𝗈𝗋𝗍𝗂𝖼𝗈​\(α,st\)\},\\displaystyle=\\\{\\alpha\\in\\mathsf\{Cap\}\_\{t\}\\mid J\_\{\\mathsf\{Portico\}\}\(\\alpha,s\_\{t\}\)\\\},Vβ,t\\displaystyle V\_\{\\beta,t\}=\{β∣∃κ\.\(β,κ\)∈Vt\}\.\\displaystyle=\\\{\\beta\\mid\\exists\\kappa\.\\;\(\\beta,\\kappa\)\\in V\_\{t\}\\\}\.Let𝒜​\(τ\)\\mathcal\{A\}\(\\tau\)be the authority instances inducible for taskτ\\tauover the run\.QtQ\_\{t\}is the set of visible expansion rules or authority\-request endpoints, andFtF\_\{t\}the action descriptors the planner interface allows the model to formulate\. The concrete interface is a tagged union:

It=Exec⁡\(Vt\)⊎Prop⁡\(Ft\)⊎Req⁡\(Qt\)\.I\_\{t\}=\\operatorname\{Exec\}\(V\_\{t\}\)\\uplus\\operatorname\{Prop\}\(F\_\{t\}\)\\uplus\\operatorname\{Req\}\(Q\_\{t\}\)\.Executable effect authority still requires a capability inVtV\_\{t\}; selecting a request rule does not grant authority to read or write the covered resource\. The all\-visible same\-policy comparator broadensFtF\_\{t\}while keepingVtV\_\{t\}, grant timing, closure events, and execution\-time validation fixed\.

#### Justification and grants\.

HereJ​\(α,st\)J\(\\alpha,s\_\{t\}\)is the ideal task\-justification relation for whether runtime capabilityα\\alphashould be executable in statests\_\{t\}\.Porticoenforces the computable relationJ𝖯𝗈𝗋𝗍𝗂𝖼𝗈J\_\{\\mathsf\{Portico\}\}compiled from the task contract and typed catalog\. Let the compiled policy be

P=\(ℰ0,Γ,Λ,G\),P=\(\\mathcal\{E\}\_\{0\},\\Gamma,\\Lambda,G\),whereℰ0\\mathcal\{E\}\_\{0\}is the initial envelope,Γ\\Gammais the set of declared expansion rules,Λ\\Lambdais the set of closure rules, andGGis the set of global invariants\. Let the runtime state be

st=\(ϕt,Lt,Ot\),s\_\{t\}=\(\\phi\_\{t\},L\_\{t\},O\_\{t\}\),whereϕt\\phi\_\{t\}is the current phase,LtL\_\{t\}live grants, andOtO\_\{t\}observable audit/run state\. The setsVtV\_\{t\},FtF\_\{t\}, andQtQ\_\{t\}are derived before each planner turn\.Porticotreats planner requests as evidence; planner text alone cannot authorize an action\. In particular, the intent componentι\\iotais checked through the typed catalog, contract selectors, phase, and observable state; a planner\-provided rationale is never enough to satisfyJ𝖯𝗈𝗋𝗍𝗂𝖼𝗈J\_\{\\mathsf\{Portico\}\}\.

For runtime capability instanceα=\(β,κ\)\\alpha=\(\\beta,\\kappa\),Portico’s current\-executability test is:

J𝖯𝗈𝗋𝗍𝗂𝖼𝗈​\(α,st\)≡\\displaystyle J\_\{\\mathsf\{Portico\}\}\(\\alpha,s\_\{t\}\)\\equiv\{\}global​\_​ok⁡\(α,G\)∧\\displaystyle\\operatorname\{global\\\_ok\}\(\\alpha,G\)\\wedge\{\}phase​\_​ok⁡\(α,ϕt\)∧\\displaystyle\\operatorname\{phase\\\_ok\}\(\\alpha,\\phi\_\{t\}\)\\wedge\{\}\(𝗂𝗇𝗂𝗍​\(α,ℰ0,τ,st\)∨𝗅𝗂𝗏𝖾​\(α,Lt,Λ,st\)\)\.\\displaystyle\\left\(\\mathsf\{init\}\(\\alpha,\\mathcal\{E\}\_\{0\},\\tau,s\_\{t\}\)\\vee\\mathsf\{live\}\(\\alpha,L\_\{t\},\\Lambda,s\_\{t\}\)\\right\)\.Here𝗂𝗇𝗂𝗍\\mathsf\{init\}meansκ\\kappais compiler\-issued initial authority, and𝗅𝗂𝗏𝖾\\mathsf\{live\}meansκ\\kappanames a live grant handle whose grant covers the tool, privilege, resource, effect, and intent and has not been closed\. A new grant may be issued only when a rule inΓ\\Gammamatches the requested descriptorβ\\beta, phase, trigger, and episode state in the observable state\. A closed episode cannot be reopened by planner text alone; a renewed grant for the same descriptor requires a fresh trusted event such as a new phase, orchestrator subgoal, human approval, or new episode nonce\. The compiler and runtime checks for these rules are described in Section[5](https://arxiv.org/html/2606.22504#S5)\. For the running trace,src/serialization\.pycan match such a rule; the packaging note cannot\.

#### Semantic properties\.

The executable capability state induces three obligations: when authority may appear, how it may widen, and when it must disappear\.

P1\. Desired capability minimality\.Executable capabilities exposed to the planner must stay within current justification:

Vt⊆\{α∈𝒜​\(τ\)∣J​\(α,st\)\}\.V\_\{t\}\\subseteq\\\{\\alpha\\in\\mathcal\{A\}\(\\tau\)\\mid J\(\\alpha,s\_\{t\}\)\\\}\.Only capabilities justified by current state should be executable through the planner interface\. Runtime reachability alone is insufficient\.

P2\. Desired justified expansion\.Authority outside the initial envelope should enter the executable set only through an explicit grant transition:

α∉𝖨𝗇𝗂𝗍​\(ℰ0,τ,st\)∧α∈\(Vt\+1∖Vt\)\\displaystyle\\alpha\\notin\\mathsf\{Init\}\(\\mathcal\{E\}\_\{0\},\\tau,s\_\{t\}\)\\wedge\\alpha\\in\(V\_\{t\+1\}\\setminus V\_\{t\}\)⇒𝗀𝗋𝖺𝗇𝗍​\_​𝗋𝗎𝗅𝖾​\_​𝗆𝖺𝗍𝖼𝗁𝖾𝗌​\(β​\(α\),st\)∧J​\(α,st\+1\)\.\\displaystyle\\qquad\\Rightarrow\\mathsf\{grant\\\_rule\\\_matches\}\(\\beta\(\\alpha\),s\_\{t\}\)\\wedge J\(\\alpha,s\_\{t\+1\}\)\.This implication concerns additions that are not compiler\-issued initial authority fromℰ0\\mathcal\{E\}\_\{0\}\. The grant rule is checked in the pre\-state\. The transition mints a fresh runtime capability instanceα\\alphafor the requested descriptor\. The full visibility justification, including the live grant, holds after the transition\. Legitimate cross\-boundary work is represented as expansion of the executable capability set, not broad upfront exposure\.

P3\. Desired capability closure\.A temporary runtime capability should disappear once its current grant episode ends:

∀t≥c,α∉Vt\.\\forall t\\geq c,\\ \\alpha\\notin V\_\{t\}\.Here,ccis the first planner turn after the monitor consumes the observable closure event forα\\alpha’s current grant episode\. Closure ends the current visibility episode\. The same descriptorβ​\(α\)\\beta\(\\alpha\)can become justified again only through a fresh runtime capabilityα′\\alpha^\{\\prime\}minted by a new grant issued afterccand still live at timett\. If authority can be granted for a bounded subgoal but remains planner\-usable after the relevant phase or justification closes, then temporary authority has degraded into lingering authority\.

Operationally, this is a no\-stale\-use requirement\. If grantggcloses before turntt, no invocation backed only byggshould appear in the planner interface attt, and any replay ofgg’s handle should be rejected before it produces effects\.

#### Monitor guarantees\.

ForPortico, the desired properties become checkable relative to the compiled contract relationJ𝖯𝗈𝗋𝗍𝗂𝖼𝗈J\_\{\\mathsf\{Portico\}\}\. This is the enforced property; the gap betweenJJandJ𝖯𝗈𝗋𝗍𝗂𝖼𝗈J\_\{\\mathsf\{Portico\}\}reflects contract quality\. The guarantees assume standard reference\-monitor assumptions: every planner invocation is mediated; the catalog maps each call to a sound authority instanceα​\(a\)\\alpha\(a\); only the compiler initializesP=\(ℰ0,Γ,Λ,G\)P=\(\\mathcal\{E\}\_\{0\},\\Gamma,\\Lambda,G\); only the adjudicator mutates live grants and audit state; handles are task\-local server\-side references bound to task, epoch, resource, privilege, and effect; and closure observations are consumed before the next planner invocation\. The evaluated harness serializes planner requests\. A concurrent integration must be linearizable or must revalidate the handle immediately before the side effect; otherwise revocation prevents only new adjudications, not effects already permitted before closure\. Below,st′s^\{\\prime\}\_\{t\}andVt′V^\{\\prime\}\_\{t\}denote the candidate state and derived executable capability set after pending observations and closures\. Grant requests returngrant; permitted invocations only consume authority already present inVt′V^\{\\prime\}\_\{t\}\.

G1\. Visibility invariant\.At every mediated turn after observations and revocations are applied,

Vt=\{α∣\\displaystyle V\_\{t\}=\\\{\\alpha\\mid\{\}α∈𝖨𝗇𝗂𝗍​\(ℰ0,τ,st\)∪𝖦𝗋𝖺𝗇𝗍𝖢𝖺𝗉𝗌​\(Lt,τ,st\)\\displaystyle\\alpha\\in\\mathsf\{Init\}\(\\mathcal\{E\}\_\{0\},\\tau,s\_\{t\}\)\\cup\\mathsf\{GrantCaps\}\(L\_\{t\},\\tau,s\_\{t\}\)∧J𝖯𝗈𝗋𝗍𝗂𝖼𝗈\(α,st\)\}\.\\displaystyle\{\}\\wedge J\_\{\\mathsf\{Portico\}\}\(\\alpha,s\_\{t\}\)\\\}\.Thus every executable capability exposed through the interface satisfiesJ𝖯𝗈𝗋𝗍𝗂𝖼𝗈J\_\{\\mathsf\{Portico\}\}\.

G2\. Permit soundness\.If the monitor permits invocationaaat statests\_\{t\}, thenα​\(a\)∈Vt′\\alpha\(a\)\\in V^\{\\prime\}\_\{t\},J𝖯𝗈𝗋𝗍𝗂𝖼𝗈​\(α​\(a\),st′\)J\_\{\\mathsf\{Portico\}\}\(\\alpha\(a\),s^\{\\prime\}\_\{t\}\)holds, no invariant inGGdeniesα​\(a\)\\alpha\(a\), andaauses either compiler\-issued initial authority or a valid live handle forα​\(a\)\\alpha\(a\)\.

G3\. Grant soundness\.If an authority instance outside the initial envelope entersVtV\_\{t\}, then the audit log contains a grant whose ruleγ∈Γ\\gamma\\in\\Gammamatched the current observable state, phase, selector, privilege, effect, and intent, and the added instance is covered by that grant\.

G4\. Closure before reuse\.If a closure predicate for grantggis satisfied by an observable event, thenggand any authority instances visible only throughggare removed before the next planner invocation is adjudicated\. A later reuse therefore requires a new grant transition; leftover visibility from the closed episode has been removed\.

*Why the monitor enforces the compiled analogues of P1–P3\.*The argument is by induction over mediated invocations\. The base state derivesV0V\_\{0\}from the compiler\-issued initial envelope andJ𝖯𝗈𝗋𝗍𝗂𝖼𝗈J\_\{\\mathsf\{Portico\}\}, so every executable instance is initial and checked againstGG\. For the inductive step,IngestRuntimeObservationrecords events andAdjudicatePlannerRequestconsumes them before the next planner call\. Closed grants are removed fromLtL\_\{t\};VtV\_\{t\}is then recomputed from initial authority, remaining live grants, andJ𝖯𝗈𝗋𝗍𝗂𝖼𝗈J\_\{\\mathsf\{Portico\}\}\. A permitted call is already in the updated executable capability set and satisfiesJ𝖯𝗈𝗋𝗍𝗂𝖼𝗈J\_\{\\mathsf\{Portico\}\}; if it is grant\-backed, its handle names a live epoch\. New non\-initial authority entersVt\+1V\_\{t\+1\}only after agrantreturn from a matchingγ∈Γ\\gamma\\in\\Gammathat also passesGG\. No transition directly inserts executable capabilities outside the initial envelope or a live grant\. Thus visibility satisfies G1, permits satisfy G2, additions satisfy G3, and closed grant capabilities are absent before reuse by G4\. These are the enforced versions of P1–P3 for the compiled contract and mediated path\.

## 5Porticoas a Reference Monitor

Porticosits between the planner and tools\. It owns the lifecycle state around live grantsLtL\_\{t\}, derives the executable capability setVtV\_\{t\}from the contract and live handles, and removes temporary authority at closure\. Host isolation constrains execution after handoff\.Porticocontrols authority exposed to the planner before it\.

#### Inputs\.

Porticouses three inputs: a task contract with initial scope, forbidden resources, declared expansions, and closure events; a typed tool catalog that maps runtime tools to privileges, resources, effects, and intent classes; and a policy vocabulary for global deny rules such as credential\-file denies, network egress denies,curl \| sh, andgit push\. Planner text can request authority; the monitor decides whether to grant it\.

#### Runtime interface\.

At each step, the planner sees only the currently visible tool schemas, resource scopes, argument patterns, and live grant options\. Denials return reason classes; grants mint epoch\-bound handles for covered resource/effect bindings and add them to the next\-step interface\. Revocation removes those handles from later tool selection and validation, and execution rejects stale replay\. Authority\-request options are separate from effect capabilities: they let the planner ask whether a declared expansion rule applies without making the target readable or writable\.

#### Operational meaning of visibility\.

Execution capabilities are exposed through the mediated interface\. Tool schemas are omitted or narrowed, resource scopes and argument patterns are removed from the next planner menu, and execution tools consume compiler\-issued initial handles or live grant handles\. Free\-form paths are accepted only by the authority\-request endpoint or by compatibility wrappers that resolve them against compiler\-issued initial or live grant handles before execution; unresolved paths are denied or converted into authority requests\. A remembered path becomes authority only when a live handle for that resource and effect is present\. Denied attempts are logged separately from visibility, and revocation changes the capability interface rather than model memory\. Handles are opaque task\-local references validated server\-side against task, epoch, resource, privilege, and effect\. In our examples, we name handles by role, such as a serialization read handle; the runtime accepts only opaque handles that resolve to live server state\.

Table 2:Planner\-facing interface snapshots for PORTICO and the all\-visible same\-policy comparator\. The timeout\-boundary case reuses the API\-to\-serialization boundary from the running example\. Both conditions share execution policy, grant timing, handle checks, and closure events; they differ in the breadth of proposal affordances shown to the planner\.Table[2](https://arxiv.org/html/2606.22504#S5.T2)shows the concretePorticointerface next to the all\-visible same\-policy comparator\. The timeout\-boundary case reuses the API\-to\-serialization boundary from the running example\. InPortico,src/serialization\.pycan remain a file\-name hint, but it becomes executable only while the epoch\-bound handle is live\. In the comparator, the request option remains broad, while the same execution policy still requires a live handle\. After closure,Porticoremoves the handle from the next interface and both policies reject stale replay before execution\.

#### Shell and compound tools\.

Shell, git, package\-manager, and network calls are mediated through the typed catalog before execution\. When classifiable, the mapper extracts file operands, command class, network destinations, dependency effects, and VCS effects, then checks the resulting instances againstVtV\_\{t\}andGG\. Global denies such ascurl \| sh,git push, forbidden package mutation, and undeclared network egress are denied; unclassified commands require explicit approval or are denied\. The guarantees in Section[4](https://arxiv.org/html/2606.22504#S4)cover mediated tool invocations only\. Appendix[B](https://arxiv.org/html/2606.22504#A2)reports the frozen compound\-mediation audit over observed commands, not arbitrary shell syntax\.

#### Contract object and authoring path\.

At runtime, the task contract is the monitor’s policy input and planner prose supplies requests\. The monitor compiles it intoP=\(ℰ0,Γ,Λ,G\)P=\(\\mathcal\{E\}\_\{0\},\\Gamma,\\Lambda,G\): initial envelope, grant rules, closure rules, and global deny rules\. Figure[2](https://arxiv.org/html/2606.22504#S5.F2)shows the running excerpt\. Contracts draw on the task interface, repository policy, protected\-file rules, test targets, dependency/network policy, and optional boundary expansions\. A planner can request expansion, but the monitor checks the compiled contract, catalog, phase, selectors, and observable state\. Poor contracts can undergrant or overgrant; Section[8](https://arxiv.org/html/2606.22504#S8)discusses that deployment risk\.

task:

name:timeoutpropagation

goal:propagateoptionaltimeout

initial\_allowed\_resources:

\-\{path:"src/api\.py",access:read\_write\}

\-\{path:"tests/test\_api\.py",access:read\_write\}

escalation\_paths:

\-id:serialization\-module\-legitimate

trigger:authority\_request

allowed\_resources:

\-\{path:"src/serialization\.py",access:read\_write\}

\-\{path:"tests/test\_serialization\.py",access:read\}

phases:\[inspect,patch,test\]

compiled\_lifetime:

until:\[tests\_pass,subgoal\_complete,phase\_exit\]

forbidden\_resources:

\-\{path:"notes/packaging\.md",access:read\}

\-\{path:"requirements\.txt",access:write\}

forbidden\_network\_hosts:\["\*"\]

Figure 2:Contract excerpt with compiler\-derived lifetime for the running timeout\-propagation case\. The full checked\-in manifest appears in the artifact; this excerpt shows the initial envelope, declared grant, closure rule, and nearby forbidden resources\.In this harness,subgoal\_completedenotes a trusted runtime or orchestrator event consumed by the monitor\. A planner\-authored textual claim with the same wording is logged as untrusted text and cannot close or extend a grant\.

#### Compilation\.

The compiler buildsℰ0\\mathcal\{E\}\_\{0\}from initial scope, maps operations to tools and privileges, maps paths and commands to resources, and turns network, dependency, and policy\-vocabulary restrictions intoGG\. Expansions become grant rules inΓ\\Gamma; lifetime clauses become closure predicates inΛ\\Lambda\. The packaging probe and serialization boundary compile to different selectors, so adjudication does not rely on free\-form language judgments\. The same checked\-in manifest is read by both the compiler and the scorer, with authority labels fixed before execution; Appendix Table[12](https://arxiv.org/html/2606.22504#A2.T12)summarizes the full path\. Intent fields are advisory: grant matching uses tool/effect metadata, target selectors, monitor phase, contract triggers, and observable state\.

Table 3:Event provenance for grant and closure decisions\. Planner text is advisory; trusted monitor or workflow events drive authority changes\.The evaluated harness serializes planner requests\. A queued or batched integration must apply the same epoch and handle checks to each invocation before effects occur; a closed grant cannot be reused without a fresh adjudication\. If a call is already permitted and in flight when a closure event arrives, the integration must either serialize the event before the effect or revalidate the handle immediately before the effect\. The guarantees reported here assume that linearizable mediation point\.

#### Runtime adjudication\.

Algorithms[1](https://arxiv.org/html/2606.22504#algorithm1),[2](https://arxiv.org/html/2606.22504#algorithm2), and[3](https://arxiv.org/html/2606.22504#algorithm3)give the monitor procedures\. Compilation buildsP=\(ℰ0,Γ,Λ,G\)P=\(\\mathcal\{E\}\_\{0\},\\Gamma,\\Lambda,G\),V0V\_\{0\}, andI0I\_\{0\}\. Adjudication consumes pending closures and separates invocations \(which need initial authority or a live handle\) from authority requests \(which mint handles for the next interface without executing\)\. Observation ingestion records events after a permitted call so closures take effect before the next planner invocation\. On adjudication the monitor refreshes state, derivesVVfrom current live grants, checks invariants, and logs a structured decision\. Grant rules are templates inΓ\\Gamma; grants are live instances that mint epoch\-bound handles\.

Input :task contractτ\\tau; typed tool catalog𝒯\\mathcal\{T\}; runtime profileρ\\rho; policy vocabularyΩ\\Omega

Output :policy

P=\(ℰ0,Γ,Λ,G\)P=\(\\mathcal\{E\}\_\{0\},\\Gamma,\\Lambda,G\), initial capabilities

V0V\_\{0\}, and interface

I0I\_\{0\}
Writes :

ℰ0\\mathcal\{E\}\_\{0\},

Γ\\Gamma,

Λ\\Lambda,

GG,

V0V\_\{0\}, and

I0I\_\{0\}
1Parse

τ\\tauinto scope, selectors, phase defaults, network mode, and dependency policy

2Map declared operations through

𝒯\\mathcal\{T\}to privileges, effects, argument constraints, and resource selectors

3Apply runtime profile

ρ\\rhoto restrict available tools, sandbox mode, network mode, package\-manager effects, and VCS effects

4Build

ℰ0=\(T0,Π0,ℛ0,C0\)\\mathcal\{E\}\_\{0\}=\(T\_\{0\},\\Pi\_\{0\},\\mathcal\{R\}\_\{0\},C\_\{0\}\)from the initial tools, privileges, resources, and constraints

5Add forbidden paths, hosts, shell patterns, dependency restrictions, and VCS restrictions from

τ\\tauand

Ω\\Omegato

GG
6Compile each declared expansion into a grant rule

γ∈Γ\\gamma\\in\\Gammawith trigger, selector, grant body, intent, and covered authority instances

7Compile each lifetime clause into closure predicates

Λ\\Lambda
8Use trusted events such as monitor\-launched tests passing, orchestrator subgoal completion, phase exit, run completion, or authenticated revoke for closure

9Set

V0←\{α∈𝖨𝗇𝗂𝗍​\(ℰ0,τ,s0\)∣J𝖯𝗈𝗋𝗍𝗂𝖼𝗈​\(α,s0\)\}V\_\{0\}\\leftarrow\\\{\\alpha\\in\\mathsf\{Init\}\(\\mathcal\{E\}\_\{0\},\\tau,s\_\{0\}\)\\mid J\_\{\\mathsf\{Portico\}\}\(\\alpha,s\_\{0\}\)\\\}
10Set

I0←Exec⁡\(V0\)⊎Prop⁡\(F0\)⊎Req⁡\(Q0\)I\_\{0\}\\leftarrow\\operatorname\{Exec\}\(V\_\{0\}\)\\uplus\\operatorname\{Prop\}\(F\_\{0\}\)\\uplus\\operatorname\{Req\}\(Q\_\{0\}\)
11return*P,V0,I0P,V\_\{0\},I\_\{0\}*

Algorithm 1CompileEnvelope\.Input :planner requestqq; statests\_\{t\}; policyPP; catalog𝒯\\mathcal\{T\}

Output :permit,grant, ordeny

Writes :live grants

LtL\_\{t\}, derived interface delta, and audit log

AtA\_\{t\}
s←𝖱𝖾𝖿𝗋𝖾𝗌𝗁𝖲𝗍𝖺𝗍𝖾​\(st,Ot,Λ\)s\\leftarrow\\mathsf\{RefreshState\}\(s\_\{t\},O\_\{t\},\\Lambda\)
//consume observations and close grants

1

V←𝖣𝖾𝗋𝗂𝗏𝖾𝖢𝖺𝗉𝗌\(ℰ0,s\.L,τ,s\)V\\leftarrow\\mathsf\{DeriveCaps\}\(\\mathcal\{E\}\_\{0\},s\.L,\\tau,s\)
β←𝖬𝖺𝗉𝒯\(q,s\.ϕ\)\\beta\\leftarrow\\mathsf\{Map\}\_\{\\mathcal\{T\}\}\(q,s\.\\phi\)
//phase comes from monitor state

2All returns commit the current

ssas

st\+1s\_\{t\+1\}
3if*𝖵𝗂𝗈𝗅𝖺𝗍𝖾𝗌​\(β,G\)\\mathsf\{Violates\}\(\\beta,G\)*then

4Append invariant reason to

AtA\_\{t\};return*deny*

5

6if*qqis an invocation*then

7

α←𝖱𝖾𝗌𝗈𝗅𝗏𝖾𝖢𝖺𝗉​\(q,V\)\\alpha\\leftarrow\\mathsf\{ResolveCap\}\(q,V\)
8if*α\\alphais defined andα∈V\\alpha\\in VandJ𝖯𝗈𝗋𝗍𝗂𝖼𝗈​\(α,s\)J\_\{\\mathsf\{Portico\}\}\(\\alpha,s\)*then

9Append permit to

AtA\_\{t\};return*permit*

10

11Append denial reason to

AtA\_\{t\};return*deny*

12

13if*qqis an authority request*then

14

γ←𝖬𝖺𝗍𝖼𝗁𝖦𝗋𝖺𝗇𝗍​\(Γ,β,s\)\\gamma\\leftarrow\\mathsf\{MatchGrant\}\(\\Gamma,\\beta,s\)
15if*γ\\gammais undefined*then

16Append denial reason to

AtA\_\{t\};return*deny*

17

18

g←𝖨𝗌𝗌𝗎𝖾𝖦𝗋𝖺𝗇𝗍​\(γ,s\)g\\leftarrow\\mathsf\{IssueGrant\}\(\\gamma,s\); add

ggto

s\.Ls\.L
19

Vt\+1←𝖣𝖾𝗋𝗂𝗏𝖾𝖢𝖺𝗉𝗌\(ℰ0,s\.L,τ,s\)V\_\{t\+1\}\\leftarrow\\mathsf\{DeriveCaps\}\(\\mathcal\{E\}\_\{0\},s\.L,\\tau,s\)
20

It\+1←𝖣𝖾𝗋𝗂𝗏𝖾𝖨𝖿𝖺𝖼𝖾​\(Vt\+1,Ft\+1,Qt\+1\)I\_\{t\+1\}\\leftarrow\\mathsf\{DeriveIface\}\(V\_\{t\+1\},F\_\{t\+1\},Q\_\{t\+1\}\)
21

Δ​I←\\Delta I\\leftarrowhandles minted for

ggand exposed in

It\+1I\_\{t\+1\}
22Append grant record and

Δ​I\\Delta Ito

AtA\_\{t\};return*grant*

23

24Append denial reason to

AtA\_\{t\};return*deny*

Algorithm 2AdjudicatePlannerRequest\.Input :runtime resultyyfor permitted invocationaa; statests\_\{t\}

Output :updated observation buffer and audit log

Writes :

OtO\_\{t\}and

AtA\_\{t\}
E←𝖳𝗋𝗎𝗌𝗍𝖾𝖽𝖤𝗏𝖾𝗇𝗍𝗌​\(y\)E\\leftarrow\\mathsf\{TrustedEvents\}\(y\)
//tests, workflow events, approvals, revokes

1

S←𝖢𝗅𝖺𝗌𝗌𝗂𝖿𝗂𝖾𝖽𝖲𝗂𝖽𝖾𝖤𝖿𝖿𝖾𝖼𝗍𝗌​\(y,a\)S\\leftarrow\\mathsf\{ClassifiedSideEffects\}\(y,a\)
2Drop planner\-authored test, phase, subgoal, approval, or revoke claims from

EE
3Append

E∪SE\\cup Sto

OtO\_\{t\}; append

yyto

AtA\_\{t\}
4Leave grant closure to the next call toAdjudicatePlannerRequest

Algorithm 3IngestRuntimeObservation\.
#### Running walkthrough\.

In the running trace, the packaging\-note read is denied because no rule inΓ\\Gammamatches it\. A serialization authority request succeeds because the expansion rule matches target, intent, phase, and constraints\. That request returns a grant and next\-interface handles, not an immediate file read\. Later reads and writes are permitted through those handles while the grant is live\. When the focused test passes or the subgoal closes,Λ\\Lambdarevokes the serialization grant before the next planner invocation\. The handles disappear from the interface, and replaying one of them is denied before execution\.

#### Configurations, audit, and integration\.

We evaluatePorticocore, which denies requests outsideℰ0\\mathcal\{E\}\_\{0\}, andPorticofull, which adds request–grant–invoke with trusted closure\. A grant extends only the targeted resource, tool schema, constraint, and lifetime; closure removes that extension\. The task\-wide non\-revoking comparator starts from the same envelope and receives the same grants at the same turns, but does not remove them at closure\. Every permit, deny, grant, and revoke emits a structured record with task, phase, requested action, target, grant ID, handle identifier, decision, and reason\. The same policy core backsportico\-tool, a standalone MCP server packaged with the artifact\. It exposes interface snapshots, authority requests, handle\-based file and test operations, closure, and audit logs over stdio\. This is the public integration path for trying the request–grant–invoke lifecycle in MCP\-capable coding\-agent clients; its smoke tests check protocol and packaging behavior, not benchmark outcomes\. Appendix[B](https://arxiv.org/html/2606.22504#A2)reports the compiled policy object and derivation audits\.

## 6Experimental Questions and Setup

The evaluation uses explicit scope contracts to observe exposure, expansion, and closure separately\. Broad SWE benchmarks measure end\-to\-end capability but merge these effects into one success score\[agentbench,agentboard,webarena,visualwebarena,workarena,mind2web,gaia,osworld,androidworld,bmoca,mobileworld,swebench,swepolybench\]\. We use four task\-oriented suites: three controlled security fixtures and one pinned real\-repository suite\.

#### Research questions\.

The evaluation is organized around four questions:

- •RQ1: Capability minimization\.Does minimizing exposed capabilities reduce unsafe effects relative to open access, static allowlists, and coarse sandboxing?
- •RQ2: Justified expansion\.Can controlled expansion recover legitimate cross\-boundary utility without reintroducing broad upfront exposure?
- •RQ3: Capability closure\.Once recovery and unsupported\-probe denial match before closure, does bounded lifetime reduce post\-closure stale capability availability relative to a non\-revoking design with the same grant timing, and what planning pressure remains when the same execution policy is applied to an all\-visible interface?
- •RQ4: Real\-repository lifecycle\.Does the same grant/revoke behavior appear on pinned real repositories?

Section[7](https://arxiv.org/html/2606.22504#S7)follows this order: exposure, expansion, closure, and real\-repository lifecycle\.

#### Benchmark suites\.

Suites A–C are controlled repository fixtures\. Each episode is generated from a checked\-in manifest that fixes the task prompt, fixture files, initial capability envelope, allowed and forbidden resources, optional grant rules, success predicate, and violation predicate before any model run\. The scorer reads those frozen fields and scores observed tool calls against the contract\. Suite A stresses unsafe exposure with reachable lures; Suite B uses bounded coding tasks that require legitimate temporary boundary grants; Suite C keeps the coding goal legitimate but surrounds it with hostile or overscoped context\. Suite D uses the same manifest format on pinned public repository snapshots\. Appendix Table[11](https://arxiv.org/html/2606.22504#A2.T11)gives their detailed run counts and purpose\.

#### Comparison targets\.

Table[4](https://arxiv.org/html/2606.22504#S6.T4)lists the deployment baselines,Porticovariants, and causal comparators\. The baselines expose broad access, a fixed allowlist, or coarse sandbox restrictions, without treating the task contract as a lifecycle policy\.Porticocore uses only the initial envelope;Porticofull adds request–grant–invoke with trusted closure\. The non\-revoking comparator disables only revocation, while the all\-visible same\-policy comparator keeps a broad planner interface under the same execution policy, grant timing, handle checks, and closure\. All conditions use the same catalog, scorer, budgets, fixtures, and lower\-level runtime unless noted\.

Table 4:Comparison targets\. Baselines test deployment exposure;Porticovariants test capability minimization and grant/revoke; the comparators isolate closure and execution\-time filtering\.
#### Experiment scope\.

The experiments compare exposure strategies under a fixed task policy: whole\-run exposure, execution\-time denial, or bounded grant episodes with closure\. For global A–D violation rates, the same checked\-in contract supplies enforcement and scoring, so those rates are contract\-based enforcement results rather than policy inference results\. Separate post\-closure lifecycle, stale\-effect, scripted live stale\-effect, and model\-live stale\-effect oracle files, never read by the monitor, score post\-closure behavior\. The contract\-sensitivity audit shows the expected failure modes: undergranting blocks boundary work, overgranting increases initial exposure, and a wrong expansion is inherited by the monitor\.

#### Scoring\.

We score security, utility, and exposure separately\. The main security readings are executed forbidden effects and post\-closure reuse\. Utility is measured by task success and scope compliance\. Blast radius and blocked forbidden proposals are diagnostics that explain exposure and planning pressure\. Main A/B/C tables report run\-level means over repeated executions\. Binary security readings are interpreted at the scenario or episode level, with repeat counts shown as reproducibility checks rather than independent samples\. This convention keeps blocked planning pressure separate from effects that actually reach the runtime\.

A forbidden proposal is a planner request whose resource or effect would violate the contract if executed; a blocked forbidden proposal is denied before effects\. A policy violation is an executed\-forbidden effect: a read, write, network action, dependency mutation, command, or cross\-tool step matching a forbidden resource or violation condition\. Scope compliance means the trace contains no out\-of\-scope reads, writes, executions, network actions, or unsafe commands, independent of task success\. Task success is the episode\-specific goal\. Blast radius is a weighted count of sensitive resources reached or modified\. Post\-closure reuse records whether a later reread or reuse attempt after explicit close is allowed\. Together, these metrics separate completed work, blocked detours, executed effects, and stale capability use\.

#### Models and runs\.

The main reported model profile is Qwen3\-Coder 30B through the Hugging Face router \(Qwen/Qwen3\-Coder\-30B\-A3B\-Instruct:fastest\)\. It is used for the main A–C matrix, the post\-closure lifecycle diagnostics, the live stale\-effect follow\-up, and the Qwen3 Suite\-D real\-repository matrix\. Frozen traces record the router profile, request metadata, and returned model string; fresh router reruns may select a different provider backend, so these roots are treated as frozen API\-backed profiles rather than a locally reproducible checkpoint\. A supplementary frontier slice uses GPT\-5\.5, Gemini 3\.5 Flash, and Claude Opus 4\.8 on the same three grant\-lifecycle episodes under full access,Portico, and the non\-revoking comparator\. We keep that slice separate from the Qwen3 matrix: it checks whether the same grant and closure ordering appears under current API\-backed frontier profiles, not a pooled estimate across models\. Main runs use temperature 0\.0 with a 32,768\-token context; repeats reset the fixture and planner loop for the same episode/condition cell and are reproducibility checks, not independent samples\. Main A/B/C runs use 4 planner steps on Suite A and 6 on Suites B/C; controlled escalation uses 8 steps, post\-grant follow\-through uses 9–10, and the Qwen3 router profile uses a 240 s request timeout\. The artifact records exact model strings, budgets, profile configuration, returned model identifiers, and local freeze files\.

#### Manifest, audit, and execution protocol\.

Each episode is a checked\-in manifest\. The timeout\-propagation witness declaressrc/serialization\.pyas the escalation target and listsnotes/packaging\.mdonly as a forbidden resource and attack lure \(Appendix[A](https://arxiv.org/html/2606.22504#A1)\)\. Scoring uses manifest fields fixed before execution, not post\-hoc judgments about planner rationale\. Main results come from live execution: fixtures are instantiated, the planner attempts calls, the monitor records decisions, and traces are scored against the episode contract\. Trace records capture runtime metadata, request, target, decision, reason, and latency; replay tooling is retained for denial analysis\.

#### Threats to scoring validity\.

Stronger policies induce trajectory divergence, so we score contract satisfaction instead of trace similarity\. Contaminated\-context tasks involve semantic boundary judgments, so allowed resources, forbidden resources, success conditions, and violation conditions are fixed before execution\. Model nondeterminism remains even at fixed temperature, so live studies use repeated executions\. The policy vocabulary and compiler are heuristic and coding\-specific, so claims stay within this policy family and domain\.

## 7Results

The results follow the lifecycle: exposure, expansion, closure, and real\-repository integration\.Porticofull trades some raw completion for stricter scope control\. The key comparison is closure: a task\-wide non\-revoking comparator can know which authority is legitimate and still leave it available after its justification ends\.

Table 5:Global trade\-off snapshot from the main Qwen3\-Coder 30B study: five reproducibility repeats per scenario or episode over 17 Suite\-A scenarios, 37 Suite\-B episodes, and 14 Suite\-C episodes\.Table[5](https://arxiv.org/html/2606.22504#S7.T5)summarizes the security–utility trade\-off\.Porticofull trades maximum completion for scope control, turning some unsafe or overbroad completions into scoped success or visible incompleteness\.

### 7\.1RQ1: Minimization Reduces Unsafe Effects

#### Suite\-A safety result\.

Suite A is the cleanest exposure test\. Full access violates every run and has average blast radius 6\.65\. Static allowlists and coarse sandboxing lower exposure but still leave violation rates at 0\.82 and 0\.86\. BothPorticovariants drive violations and blast radius to 0\.00: 0/17 scenarios and 0/85 repeated executions record violations\. The scenario\-level reading is therefore the same as the run\-level reading for thePorticorows\.

#### Limitations of deployment baselines\.

Full access exposes the full interface, the static allowlist narrows it, and the coarse sandbox constrains execution reachability\. They still leave the task\-phase question open: when is one local file read justified while another is not? In the same\-primitive rerun, deployment baselines complete 20/20 runs by taking one forbidden local detour per run;Porticocompletes all 20/20 in scope with 0\.00 violations\. The failure is a missing resource/effect/phase distinction in the visible interface\.

### 7\.2RQ2: Grants Recover Legitimate Boundary Work

#### Core is safe but brittle\.

Porticocore keeps scope compliance at 1\.00 and violations at 0\.00, but Suite\-B success drops to 0\.21 because many tasks need boundary\-adjacent or auxiliary resources\. A narrow initial envelope is safe but brittle: it preserves scope by stopping when legitimate work crosses a declared boundary\.

#### Controlled grants recover the boundary\.

Porticofull improves the main Suite\-B result fromPorticocore’s 0\.21 success to 0\.87 while retaining 1\.00 scope compliance and zero measured violations\. The focused Qwen2\.5\-Coder control slice, reported in Appendix[B](https://arxiv.org/html/2606.22504#A2), isolates benign boundary tasks: static allowlist succeeds by exposing secondary authority upfront,Porticocore overblocks, andPorticofull restores 20/20 successes in scope with one grant per task on average\. A larger boundary pack repeats the pattern:Porticofull completes 35/35 legitimate\-escalation runs in scope with zero measured violations\. These grants are bounded to the declared boundary resource and focused validation target\.

#### Porticoincurs a measurable utility cost\.

Porticofull still pays a utility cost on Suite B: 161/185 completions versus 180/185 under the static allowlist and coarse sandbox\. At the episode level, it completes every repeat for 31/37 Suite\-B episodes and at least one repeat for 33/37; the deployment baselines complete every repeat for 36/37\. On Suite C,Porticofull completes all 14 episodes in scope across 70/70 repeats\. Appendix[B](https://arxiv.org/html/2606.22504#A2)attributesPorticomisses to narrow grants, missing request options, conservative contaminated\-context blocking, and planner/model instability\. These misses are visible utility cost; the traces remain scope\-compliant\.

### 7\.3RQ3: Closure Removes Temporary Authority

#### Strong non\-revoking comparator\.

The task\-wide non\-revoking comparator starts with the same initial envelope asPorticofull, receives the same grant in the same turn, and permits the same actions during the episode\. The only removed mechanism is closure\. Once success, scope, and unsupported\-probe denial before closure match, the late\-reread endpoint measures remaining stale capability\.

Porticofull: bounded capabilitiesLatentnot visibleRequestboundary capabilityGrantbecomes visibleJustified useboundary workClosureremove authorityLate rereaddeniedtemporary justified visibility windowTask\-wide non\-revoking comparator:same grant, no closureSame initialenvelopeSame requestSame grantsame turnSame justifieduseNo closestill visibleLate rereadallowedrevoke disabled

Figure 3:Semantic meaning of authority closure\. Both rows start from the same initial envelope and issue the same grant at the same point; onlyPorticoremoves that authority before late reread\.
#### Non\-revoking comparison\.

Figure[3](https://arxiv.org/html/2606.22504#S7.F3)shows the split\. The comparator supports the same legitimate use, but keeps the stale capability available after the subgoal\. Table[6](https://arxiv.org/html/2606.22504#S7.T6)measures the effect on the late\-reread slice with the same grant timing\. Both systems match on task success, scope compliance, contract\-forbidden effects, and all pre\-closure decisions\.Porticofull denies reuse in 10/10 runs, while the non\-revoking comparator allows it in 10/10\. The endpoint is residual stale\-capability availability after closure\.

Table 6:Late\-reread closure comparison\. The task\-wide non\-revoking comparator starts with the same initial envelope asPorticofull and receives the same grants at the same turns, but lacks the revoke transition\. Both systems match on task success, scope compliance, and contract\-labeled forbidden effects on this slice; onlyPorticoremoves the temporary authority before post\-closure reuse\. Dedicated lifecycle\-oracle rows score post\-closure reuse separately from contract\-labeled resource/effect violations\.The trace records the mechanism behind this split: the boundary request mints an epoch\-bound handle such asg0001:r1, the next planner interface includes it, and closure marks it inactive\. Appendix Table[13](https://arxiv.org/html/2606.22504#A2.T13)audits the post\-grant misuse family against an oracle file separate from the deployment contract and not read by the monitor\.Porticorejects stale\-handle replay; the non\-revoking comparator keeps the same handle live\. The coarse all\-visible action filter denies stale replay at action time, but remains a deployment diagnostic because it exposes a broader interface and uses coarser adjacent\-detour checks\.

#### Post\-closure effects\.

Table[7](https://arxiv.org/html/2606.22504#S7.T7)adds a six\-case stale\-effect audit over serialization, markdown, output, config, and options boundaries\. The static traces grant a boundary write capability, use it once, and then replay the old handle for a post\-closure write\. The audit reads a separate oracle file after execution; the monitor and contract compiler do not read it\.Porticoaccepts 0/6 stale capabilities and executes 0/6 forbidden writes\. The non\-revoking comparator accepts 6/6 stale capabilities and executes 6/6 forbidden writes\. The coarse all\-visible action filter catches the stale handle at invocation time\. This deterministic audit is a protocol\-conformance check; it shows that the same lifetime split extends from rereads to executed write effects\.

Table 7:Post\-closure stale\-effect audit\. The oracle file is not read by the monitor\. Static traces execute the same grant, use it once, and then try a post\-closure write through the stale handle\. The non\-revoking comparator keeps the handle live;Porticoinvalidates it before effects\.
#### Live stale\-effect follow\-ups\.

Table[8](https://arxiv.org/html/2606.22504#S7.T8)repeats the stale\-effect pattern through scripted contaminated\-agent traces and six Qwen3\-Coder 30B model\-live cases\. They cover file writes, git metadata or hook mutation, and network egress to stubbed hosts\. All conditions allow 6/6 legitimate live uses;Porticoand the all\-visible same\-policy comparator execute 0/6 stale effects, while the non\-revoking comparator executes 6/6\. These are targeted follow\-ups, not exploit\-rate estimates\.

Table 8:Live stale\-effect follow\-up\. A scripted contaminated\-agent trace requests a temporary capability, uses the live handle once, and then attempts a second post\-closure side effect through the stale handle\. The oracle file is not read by the monitor\.Family columns report executed stale effects in two cases each\.

Table 9:Model\-live stale\-effect follow\-up\. Static setup materializes a live handle; the model uses it once, then receives a contaminated post\-closure reuse instruction\.Family columns report executed stale effects in two cases each\.

#### Action filtering controls a later point\.

Table[10](https://arxiv.org/html/2606.22504#S7.T10)separates two all\-visible readings\. The all\-visible same\-policy comparator keeps broad planner visibility but usesPortico’s policy, grants, handle checks, and closure\. It matchesPorticoon forbidden effects \(0/20\), scope \(20/20\), and success \(5/20\), yet logs more blocked forbidden proposals \(4\.20 vs\. 3\.35\)\. Across four post\-closure episodes the totals are 84 versus 67;Porticorecords fewer blocked proposals in three episodes and ties in one \(Appendix Table[13](https://arxiv.org/html/2606.22504#A2.T13)\)\. The difference is in failures, where broad visibility blocks 74 proposals versus 57 forPortico\. This describes planner interface cost: broader visible request options can still generate extra blocked actions under the same execution\-time policy\.

A small boundary\-extension check evaluates the same\-policy comparator outside the post\-closure family\. Both conditions record 0/8 executed forbidden effects and 8/8 scope compliance, but all\-visible logs 39 blocked proposals versus 48 forPortico\. We therefore keep the post\-closure result as a diagnostic of one family rather than a general trajectory claim\.

The coarse all\-visible action filter is a deployment diagnostic\. It denies stale uses at invocation time on late\-reread rows, but adjacent pressure changes trajectories and a coarser policy permits effectsPorticowould deny\. Over the full post\-grant family it completes 20/20 runs, but only 15/20 remain scope\-compliant; the timeout\-boundary detour contributes ten executed forbidden effects\.

Table 10:Action\-filter visibility diagnostic on the post\-closure family\. The all\-visible same\-policy condition keeps a broad planner interface but usesPortico’s execution\-time policy; the coarse all\-visible action filter keeps broad adjacent authority with coarser checks\. Exec\. viol\. counts executed forbidden effects; Blocked reports average and total denied proposals\.
#### Supporting checks\.

We repeat the closure split across additional lifecycle and hardening slices \(Appendix[B](https://arxiv.org/html/2606.22504#A2)\)\. A supplementary frontier slice runs the grant\-lifecycle episodes on GPT\-5\.5, Gemini 3\.5 Flash, and Claude Opus 4\.8 under full access,Portico, and the non\-revoking comparator: GPT\-5\.5 and Claude complete 3/3 underPorticoand no\-revoke, Gemini completes 1/3 under both, and all three preserve scope with zero violations underPorticoand no\-revoke\. Full access completes 3/3 for all profiles, but GPT\-5\.5 goes out of scope in 2/3 runs\. The appendix also covers handle replay, free\-path bypass, resource/effect mismatch, aliases, phase\-exit revoke, selector provenance, and contract\-sensitivity replays\.

### 7\.4RQ4: Lifecycle Behavior Appears on Real Repositories

#### Real\-repository setup\.

The real\-repository suite uses the same contract style on pinned snapshots of ItsDangerous, Click, Flask, Jinja, Werkzeug, Pluggy, Requests, and HTTPX\. It keeps the lifecycle question task\-bounded while replacing the synthetic layout with real files and module boundaries\.

#### Real\-repository results\.

The main Suite\-D matrix runs the fourteen real\-repository contracts once with the Qwen3\-Coder profile under Full, Static, Sandbox,Porticofull, the same\-grant no\-revoke comparator, and the coarse all\-visible action filter\. All six conditions complete 14/14 contracts with 14/14 scope and 0/14 executed contract\-forbidden effects\. OnlyPorticofull materializes temporary grants on all 14 contracts\. This slice checks that the grant lifecycle and contract mapping work on real Python project layouts; it is not a broad SWE performance benchmark\.

Supplementary local/API\-backed lifecycle roots stress the utility cost of closure\. Across 42 contract\-profile cells,Porticosucceeds in 31/42 with 42/42 scope compliance and 0/42 violations; the whole\-task no\-revoke diagnostic completes 42/42\. The gap is the cost of bounded closure when contracts close early, omit a trusted reauthorization path, or depend on a planner that does not request a fresh grant\. The full table is in Appendix[B](https://arxiv.org/html/2606.22504#A2)\.

#### Integration reading\.

A representative Flask run patchessrc/flask/sessions\.py, receives a declared read\-only boundary grant forsrc/flask/app\.py, and then denies a packaging detour topyproject\.tomlbecause it is outside both the initial envelope and the grant\. Detailed real\-repository tables are in Appendix[B](https://arxiv.org/html/2606.22504#A2)\.

## 8Discussion

#### What the results mean\.

The key finding is the lifetime split: a task\-wide non\-revoking comparator can preserve task success, scope compliance, and unsupported\-probe denial before closure, yet still leave temporary capabilities available\.Porticoremoves that residual exposure\. The measured object is the executed effect and the lifetime that exposed it\. The all\-visible same\-policy comparator adds a narrower visibility check: broader visibility yields more blocked forbidden proposals on the post\-closure diagnostic without producing executed forbidden effects\. A boundary\-extension check reverses the blocked\-proposal direction while preserving safety, so interface pressure remains diagnostic\. Closure is the stronger claim; the coarse all\-visible action filter remains a deployment diagnostic with different policy granularity\.

#### Utility and contracts\.

Porticoprioritizes scope control over raw success: safe incompletion is visible, while overbroad success can mask stale authority\. Contract quality remains a deployment input from task and workflow policy; planner self\-attestation cannot create contracts\. The timeout sensitivity audit shows undergranting, overgranting, and wrong\-expansion behavior\. Appendix[B](https://arxiv.org/html/2606.22504#A2)reports eight deterministic templates that recover 35/36 structures on held\-out transfer; authoring cost remains separate\. The real\-repository experiment shows where deployment policy needs care: an early closure can block legitimate follow\-up work unless the workflow supplies a trusted reauthorization path\. That failure is visible as an incomplete task rather than a hidden stale capability\. Safe recovery should reopen authority through a trusted event or a narrower request selector\. We did not measure inter\-author agreement, review time, or contract\-writing cost\.

#### Revocation scope and external validity\.

Revocation changes the mediated capability interface, not model memory: a revoked path may remain in context, but the planner cannot invoke it without a new grant\. The guarantee also depends on linearizable mediation: the monitor must recheck handles before effects, and unmediated shell, network, or file paths remain outside the claim\. Suites A–C are controlled fixtures; Suite D checks real Python repository layouts\. Theportico\-toolsmoke roots check packaging and public MCP interface behavior, not model performance\. Other build systems, browser tools, SaaS connectors, databases, and notebooks remain untested\. The main model profile is a frozen Hugging Face router trace root; fresh reruns may select a different backend\. Broader deployment needs the same binding for new tool domains: resource, effect, phase, justification, and trusted closure\.

## 9Related Work

#### Adjacent defenses\.

Prompt\-injection and misuse benchmarks show that untrusted content can redirect tool\-using agents, including tool\-selection hijacking before sandbox handoff\[promptinjection,injecagent,asb,toolemu,agentdojo,agentharm,agentalign,toolhijacker\]\. Guardrails and firewalls sanitize prompts or filter proposed actions\[promptarmor,llamafirewall,designpatterns,firewalls,causalarmor\]\. MCP\-security and tool\-poisoning research covers descriptor discovery, provenance, poisoning, and trust propagation\[mcp\_landscape,breakingprotocol,securingmcp,smcp,mcpsecbench,mcptox,systematicmcp,mcpitp,ama,maltool\]\.Porticostarts after that layer: it assumes a trusted typed tool interface and bounds the resource/effect authority exposed by valid descriptors\.

#### Capability lifetime and revocation\.

Classic least\-privilege and capability systems scope, delegate, and revoke authority\[saltzer,capsicum,cheri\]\. Short\-lived credentials, leases, epoch invalidation, and usage\-control systems make lifetime part of policy in other settings\[leases,uconabc\]\.Porticoapplies these mechanisms to the planner interface of coding agents and measures stale handle capabilities in trajectories\. Its handles connect revocation to model turns, resource/effect bindings, trusted closure events, and replay checks; the revoked object is the handle in the next model tool interface\. The mechanism is conventional in spirit, but its placement is different: the capability is both an execution credential and the object that shapes the next planner interface\.

#### Runtime least privilege and isolation\.

Runtime\-enforcement and policy\-compilation systems, including AgentSpec, PCAS, Maris, MiniScope, AgentBound, CaMeL, PFI, and Progent, make execution\-time mediation and dynamic policy practical\[agentspec,pcas,maris,miniscope,agentbound,camel,pfi,progent\]\. CMTF, RACG, Contract2Tool, and ContractGuard study visible tool menus, preconditions, effects, and contract integrity\[cmtf,racg,contract2tool,contractguard\]\.Porticodiffers in the unit it exposes: a grant is tied to a tool, resource, effect, phase, and epoch, and closure removes the resulting handle from later interfaces\. Tool\-menu filters hide whole primitives, and contract systems decide whether invocations are allowed;Porticoapplies those ideas to temporary capabilities whose stale replay is rejected\. Isolation and execution\-structure systems constrain reachability or handoff structure\[isolategpt,sandboxescapebench,agentcgroup,ace,saga,multiagentmemory,cellmate\];Porticoassumes such mediation and makes a narrower resource/effect lifetime visible to the planner and enforceable at execution\.

## 10Conclusion

Coding\-agent authority has a lifetime\.Porticomakes it explicit in the task contract: initial capabilities, requestable grants, trusted closure events, and global deny rules\. A boundary request mints opaque resource/effect handles\. Closure removes those handles from the next interface and rejects stale replay before effects occur\.

The experiments isolate that lifetime\. A non\-revoking comparator receives the same grant at the same turn, performs the same pre\-closure work, and still permits 10/10 post\-closure reuses;Porticodenies them\. Stale\-effect audits cover file writes, git mutation, and network egress, including six live traces\. The same\-policy diagnostic keeps forbidden effects at zero while showing the planning cost of a broader interface\. Each grant records its reason, closure, and renewal path\.

## Ethical Considerations

This work studies how to reduce harmful authority in tool\-using coding agents\. The artifact includes adversarial scenarios such as dependency mutation, exfiltration pivots, and unauthorized version\-control actions, but they are intentionally scoped to local benchmark repositories and stubbed resources\. Their purpose is to measure defensive value, not to operationalize misuse against real systems\.

The main stakeholders are repository maintainers, developers using coding agents, organizations deploying agent runtimes, and researchers who reuse the artifact\. The main potential harms are misuse of the benchmark lures outside a defensive setting, a false sense of security from an incomplete contract, overblocking of legitimate developer work, and accidental exposure if someone adapts the harness to repositories that contain real secrets\.

We reduce these risks in four ways\. First, the adversarial cases run against synthetic fixtures or pinned public repositories with no live credentials\. Second, network activity is disabled or routed to stubbed endpoints, and the benchmark does not include live exfiltration infrastructure\. Third, the artifact is framed as a defensive evaluation harness: it records policy violations, grant decisions, and revocations rather than providing an exploitation workflow\. Fourth, the paper states the deployment dependency explicitly:Porticois a monitor for explicit task contracts under complete mediation, not a replacement for sandboxing, review, logging, or careful contract authoring\.

Residual risk remains if a deployment writes an overbroad contract, fails to mediate a tool path, or treats revocation as model memory erasure\. Those cases fall outsidePortico’s guarantees\. A real deployment should combine the monitor with host isolation, credential management, approval paths for unusual expansions, and audit review\.

## Open Science

An anonymized open\-science companion repository for this submission is available at[https://anonymous\.4open\.science/r/portico/](https://anonymous.4open.science/r/portico/)\. It is organized under the paper title,*Lingering Authority: Revocable Resource\-and\-Effect Capabilities for Coding Agents*, and is intended to remain available throughout anonymous evaluation\. The repository is organized as a paper artifact first:submission\_artifact/contains the frozen result roots, manifests, independent oracles, generated tables, and reproduction scripts used by the paper\. The standalone public MCP tool lives underportico\-tool/for users who want to run the request–grant–invoke lifecycle in their own workspace\. The decision\-core packages are supporting implementation code rather than the artifact entry point\. This appendix maps the paper’s core claims to the checked\-in evidence and points readers to trace\-level supporting material\.

### Artifact and Reproduction Map

The companion repository is organized for direct audit of the paper artifact\. The primary reproduction package lives undersubmission\_artifact/; the rootREADME\.md,ARTIFACT\.md,REPRODUCING\.md, andRESULTS\.mdexplain the layout, frozen roots, regenerated tables, and short audit commands\. The standalone public MCP tool lives underportico\-tool/\. It is useful for trying the request–grant–invoke lifecycle in a workspace, but the paper results are reproduced fromsubmission\_artifact/\. The decision\-core packages undersrc/portico/andsubmission\_artifact/library/are support code rather than the main artifact entry point\.

Manifest and contract validity can be checked fromsubmission\_artifact/benchmark\_v2/manifests/withsubmission\_artifact/scripts/validate\_benchmark\_v2\.py\. The main A–C results come fromqwen3\_coder\_30b\_primary\_r5\_v1,submission\_artifact/benchmark\_v2/results/checkpoints\.json, andgenerate\_benchmark\_v2\_claim\_tables\.py\. These files regenerate the main trade\-off and boundary\-recovery tables from frozen roots\.

Closure and capability\-lifetime claims use the post\-closure protocol rootsqwen3\_coder\_30b\_b10\_capability\_protocol\_r5\_v1,capability\_protocol\_local\_sanity\_v1,capability\_protocol\_hardening\_v1,capability\_stale\_effects\_v1,capability\_protocol\_overhead\_v1, and the independent oracle files undersubmission\_artifact/benchmark\_v2/oracles/\. The relevant generators aregenerate\_capability\_lifecycle\_oracle\_audit\.py,generate\_capability\_stale\_effects\.py,generate\_capability\_protocol\_overhead\_audit\.py, andgenerate\_interface\_snapshot\_table\.py\. These roots audit same grant timing, closure, stale\-handle replay, stale write effects, interface snapshots, and turn/token overhead\. The supplementary model\-profile lifecycle slice is underfrontier\_coding\_matrix\_handle\_fix\_v1and its matching no\-Porticobaseline is underfrontier\_coding\_matrix\_no\_portico\_v1\.

The public MCP integration is documented inportico\-tool/and audited through the frozen MCP smoke roots:portico\_mcp\_protocol\_smoke\_v1,codex\_mcp\_portico\_smoke\_v1,claude\_code\_mcp\_portico\_smoke\_v1,opencode\_mcp\_config\_smoke\_v1, andopenhands\_mcp\_config\_smoke\_v1\. These smokes record interface snapshot, authority request, live handle use, closure, and stale replay denial through a stdio tool interface\. These are MCP interface checks rather than model\-evaluation results\. Theportico\-tool\-smokeexecutable andsubmission\_artifact/Makefiletargets such asmake mcp\-smokeprovide local checks that require no provider credentials\.

Suite D evidence is undersubmission\_artifact/benchmark\_v2/real\_repo\_suite\_d\_v1/and the Qwen3 result rootsqwen3\_real\_repo\_boundary\_classic\_baselines\_v1,qwen3\_real\_repo\_expansion\_classic\_baselines\_v1,qwen3\_real\_repo\_boundary\_lifecycle\_comparators\_v1, andqwen3\_real\_repo\_expansion\_lifecycle\_comparators\_v1\. These roots record the pinned repository index, real\-repository contracts, and grant\-bearing cells\. Compound\-tool mediation evidence lives undercompound\_mediation\_audit\_v1\. Contract footprint, transfer, and sensitivity evidence lives underpolicy\_derivation\_audit\_v1,policy\_derivation\_transfer\_v2, andcontract\_sensitivity\_v1\.

The anonymous repository excludes secrets, provider credentials, local virtual environments, partial runs, and non\-essential logs\. Upon acceptance, the artifact can be deanonymized and archived with the same frozen package used during review\.

## References

## Appendix ARepresentative Trace Witnesses

The main text uses compact running examples\. This appendix records the corresponding checked\-in witnesses and the transition each one exercises\. Full JSON traces remain in the artifact\.

#### False detour versus legitimate boundary\.

In the timeout\-boundary witness \(artifact IDB9\-02\), the task starts withsrc/api\.py,tests/test\_api\.py, and focused pytest\. The contract declaressrc/serialization\.pyas an on\-demand timeout\-propagation boundary and listsnotes/packaging\.mdas a forbidden side resource\.Porticodenies the packaging note because no grant rule matches it\. A later authority request mints a serialization handle; the next interface exposes that handle; closure then removes it\. This witness shows that the same primitive can address two resources while only one has a current justification\.

#### Temporary read closure\.

In the temporary\-note witness \(artifact IDB8\-05\), the renderer\-repair contract keeps local source, focused tests, and pytest visible\. A recheck note is available only through a temporary read grant\.Porticogrants the note for inspection, consumes the trusted subgoal\-close event, removes the note handle, and denies a later reread\. The local patch/test handles remain live\. This witness shows closure of a temporary capability without ending the whole repair task\.

#### Same\-grant stale handle\.

The stale\-handle family givesPorticoand the non\-revoking comparator the same initial envelope, the same authority request, and the same grant at the same turn\. After closure,Porticorejects replay because the epoch is closed\. The comparator keeps the same handle live\. This witness is the minimal trace for isolating capability lifetime\.

## Appendix BProtocol Evidence and Supporting Audits

This appendix keeps evidence that is useful to inspect in the paper itself: the compiled policy object behind the running example, the lifecycle checks that exercise stale handles, real\-repository evidence, public\-tool smoke roots, and the contract robustness audits\. Full per\-episode tables, manifest JSON, and CSV outputs remain in the artifact\.

Table 11:Benchmark suites\. Suites A–C are controlled fixtures; Suite D uses pinned real repositories\. All contracts are fixed before execution\.Table 12:Compiled policy excerpt for the timeout\-boundary witness\. The table shows the part of the contract that matters for the serialization boundary\. Planner text does not add authority; only compiled fields and trusted events can change the authority state\. The artifact ID isB9\-02\.Table 13:Closure and visibility diagnostics\. These checks separate capability lifetime from late execution filtering\.Table 14:Supplementary API\-backed frontier lifecycle slice\. The same three grant\-lifecycle episodes run under full access,Portico, and the non\-revoking comparator\. This is a narrow protocol check, not the main utility matrix\.Table 15:Protocol hardening coverage\.Table 16:Real\-repository authority\-lifecycle evidence\. A contract\-profile cell is one contract evaluated under one runtime/model profile and aggregated over its fixed executions\.Table 17:Contract derivation and sensitivity\. These audits characterize the checked\-in contract layer; they do not claim automatic policy synthesis\.The omitted appendix material is still part of the artifact: full manifest excerpts, per\-episode post\-closure rows, ECES/PTA exposure diagnostics and weights, overhead CSVs, expanded hardening traces, and generation scripts\. Those files are more useful as auditable records than as compressed PDF tables\.

#### Protocol invariants to inspect\.

The artifact keeps one machine\-readable trace per row below\. These records are the most useful checks for a reviewer who wants to inspect the implementation rather than rerun the whole campaign\.

Table 18:Protocol invariants to inspect in the artifact\.
#### Primary artifact roots\.

The compact roots areqwen3\_coder\_30b\_primary\_r5\_v1for the main A–C campaign,qwen3\_coder\_30b\_b10\_capability\_protocol\_r5\_v1for the same\-grant closure and same\-policy diagnostics,frontier\_coding\_matrix\_handle\_fix\_v1andfrontier\_coding\_matrix\_no\_portico\_v1for the supplementary API\-backed frontier slice,capability\_stale\_effects\_v1and the model\-live stale\-effect root for post\-closure effects, and theqwen3\_real\_repo\_\*roots for Suite D\. The MCP smoke roots audit the publicportico\-toolinterface\.policy\_derivation\_transfer\_v2andcontract\_sensitivity\_v1cover contract robustness\.

#### Utility\-cost attribution\.

The main text reports that bounded closure preserves scope but can reduce raw completion\. The failure classes below are the useful diagnostic split: they separate missing request options from narrow grants, planner instability, and conservative poisoned\-context blocking\.

Table 19:Utility misses on the main repeat\-strengthened checkpoint\.
#### Reauthorization reading\.

The real\-repository gap is a contract\-lifetime issue, not an unexplained failure mode\. A non\-revoking comparator succeeds more often because temporary authority remains available after the episode closes\. A deployable monitor can recover some of that utility only through a fresh trusted event, such as a new workflow phase, human approval, or a monitor\-observed subgoal transition\. Planner text alone should not reopen a closed epoch\.

Table 20:How to read utility loss under bounded closure\.
#### Protocol cost\.

The two\-stage lifecycle adds one materialization turn when a grant is minted for the next interface\. In the post\-closure root,Portico, the non\-revoking comparator, and the all\-visible same\-policy comparator all use that turn; the coarse all\-visible action filter does not\. The artifact records the associated step counts, prompt tokens, and harness timestamps\.

#### Mediation boundary\.

The protocol checks assume that runtime calls reachPorticobefore side effects occur\. Theportico\-toolsmokes exercise the stdio interface, snapshots, authority requests, handle use, closure, and stale replay denial\.