Lingering Authority: Revocable Resource-and-Effect Capabilities for Coding Agents
arXiv:2606.22504v1 [cs.CR] 21 Jun 2026
Igor Santos-Grueiro International University of La Rioja
Abstract
closes. If the agent later uses this stale authority, the plannertool 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 from src/api. py to src/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 as notes/packaging.md is 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 [1, 2, 8, 11, 42, 44, 46, 56–58], tool and protocol trust [15–18, 21, 29, 33, 37, 49, 54], and reachability or execution checks after tool selection [4, 7, 9, 19, 28, 34, 38, 45, 47, 48, 52, 59, 61]. 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 resourceand 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
Coding agents often receive broad tool access for an entire task, even when a resource is needed only for one subgoal. We call this gap lingering authority: a temporary resource/effect capability remains exposed after the episode that justified it has closed. P ORTICO is 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, P ORTICO records 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; P ORTICO then 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.
1
Introduction
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 1
expansion permits legitimate boundary work through explicit grants. Authority closure removes temporary authority when the reason for exposing it ends. We implement these obligations in P ORTICO, a reference monitor for coding agents. Given a task contract and typed tool catalog, P ORTICO compiles an initial envelope, grant rules, closure rules, and global deny rules. P ORTICO core exposes only the initial envelope. P ORTICO full 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. P ORTICO complements 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 samepolicy 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:
src/api.py into src/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 as notes/packaging.md are outside the task. Table 1 gives the step-by-step trace. Table 1: Timeout-propagation authority trace. Planner event
0
Start task.
1 2
3a 3b 4
5a 5b
P ORTICO decision and visible capabilities
Expose E0 : src/api.py, tests/ test_api.py, and focused pytest. Read notes/packaging.md. Deny; packaging notes are never justified. Visible capabilities unchanged. Request serialization authority. Grant serialization capability; mint epoch-bound handles for the next planner interface. Read src/serialization.py Permit under the live grant handle. through the read handle. Edit src/serialization.py Permit under the live grant handle. through the write handle. Focused tests pass. Revoke the serialization grant; visible capabilities return to the initial API scope. Replay the serialization handle. Deny; the handle is stale after closure. Reread notes/packaging.md. Deny; packaging notes were never in the contract.
src/serialization.py changes 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 with src/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.
• 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 in P ORTICO with epochbound 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/. It contains the checked-in task contracts, frozen result roots, reproduction scripts, public portico-tool traces, and secondary P ORTICO decision core used to audit the paper.
2
Step
3
Problem 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 illustrate the distinction: reachability, execution-time denial, plan integrity, and task-wide legitimacy still leave open which capabilities are exposed
A 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 from 2
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.
Sets
Example
Available
read src/serialization.py during timeout propagation Reachable
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.
Executable capability
Policy-admissible
Available
yes
Reachable
yes
Policy/ grant eligible
yes
Executable now
no
Aavail,t ⊇ Areach,t ⊇ Aadm,t ⊇ Vβ,t
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.
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. 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.
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 overbroad 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.
4
Model of Capabilities and Interfaces
Planner interface as runtime state. For task τ, 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, ι, φ),
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.
where u is the tool primitive, p the primitive privilege, r the resource, e the side-effect class, ι the task intent, and φ the trusted phase. This per-request mapping matters because one tool, especially shell, can induce many resources and effects [30, 43, 50, 51]. Four related but non-equivalent descriptor sets. Figure 1 separates four sets over the same descriptor type. Let Bτ be the descriptor universe for task τ. Aavail,t contains descriptors in Bτ whose tool primitive is registered; Areach,t restricts them to runtime-reachable resources; Aadm,t keeps descriptors admissible under policy or a future grant rule; and Vβ,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.
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 3
Task- and phase-scoped state. For task τ, the compiled policy starts from an initial authority envelope
Executable effect authority still requires a capability in Vt ; selecting a request rule does not grant authority to read or write the covered resource. The all-visible same-policy comparator broadens Ft while keeping Vt , grant timing, closure events, and execution-time validation fixed.
E0 (τ) = (T0 , Π0 , R0 ,C0 ), where T0 is the initial tool-schema set, Π0 the initial primitive privileges, R0 the initial resources, and C0 the initial contextual constraints. The monitor maintains phase, live grants, and audit state, then derives executable capabilities from E0 plus live grants. An authority descriptor is a concrete requested operation
Justification and grants. Here J(α, st ) is the ideal taskjustification relation for whether runtime capability α should be executable in state st . P ORTICO enforces the computable relation JPortico compiled from the task contract and typed catalog. Let the compiled policy be
β = (u, p, r, e, ι, φ),
P = (E0 , Γ, Λ, G),
where u is the tool, p the primitive privilege required by that invocation, r the resource or resource class, e the sideeffect class, ι the task intent, and φ the phase under which the invocation is being adjudicated. A runtime capability instance is α = (β, κ), where κ records compiler-issued initial authority or a grant ID, epoch, and opaque handle. Runtime capabilities live in Bτ × K for handle metadata space K. At runtime, φ is derived from φt and checked by phase_ok; it remains in β for audit. For example, the temporary serialization read in the running trace maps to:
where E0 is the initial envelope, Γ is the set of declared expansion rules, Λ is the set of closure rules, and G is the set of global invariants. Let the runtime state be st = (φt , Lt , Ot ), where φt is the current phase, Lt live grants, and Ot observable audit/run state. The sets Vt , Ft , and Qt are derived before each planner turn. P ORTICO treats planner requests as evidence; planner text alone cannot authorize an action. In particular, the intent component ι is checked through the typed catalog, contract selectors, phase, and observable state; a planner-provided rationale is never enough to satisfy JPortico . For runtime capability instance α = (β, κ), P ORTICO’s current-executability test is:
u = read_file, p = read, r = src/serialization.py, e = inspect_code, ι = propagate_timeout, φ = patch, κ = (grant id, epoch, read handle). 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:
JPortico (α, st ) ≡ global_ok(α, G) ∧ phase_ok(α, φt ) ∧ (init(α, E0 , τ, st ) ∨ live(α, Lt , Λ, st )) .
Init(E0 , τ, st ) = {α = (β, κ) | u(β) ∈ T0 ∧ p(β) ∈ Π0 ∧
Here init means κ is compiler-issued initial authority, and live means κ names 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 Γ matches the requested descriptor β, 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. For the running trace, src/serialization.py can match such a rule; the packaging note cannot.
r(β) ∈ R0 ∧ C0 (e(β), ι(β), φ(β), κ, τ, st )}. Each field filters part of the concrete invocation. Live grants add runtime instances: GrantCaps(Lt , τ, st ) = {α | live(α, Lt , Λ, st )}. The executable runtime capabilities are derived at each turn: Capt = Init(E0 , τ, st ) ∪ GrantCaps(Lt , τ, st ), Vt = {α ∈ Capt | JPortico (α, st )}, Vβ,t = {β | ∃κ. (β, κ) ∈ Vt }.
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 ⊆ {α ∈ A (τ) | J(α, st )}.
Let A (τ) be the authority instances inducible for task τ over the run. Qt is the set of visible expansion rules or authorityrequest endpoints, and Ft 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 ). 4
G1. Visibility invariant. At every mediated turn after observations and revocations are applied,
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:
Vt = {α | α ∈ Init(E0 , τ, st ) ∪ GrantCaps(Lt , τ, st ) ∧ JPortico (α, st )}. Thus every executable capability exposed through the interface satisfies JPortico . G2. Permit soundness. If the monitor permits invocation a at state st , then α(a) ∈ Vt′ , JPortico (α(a), st′ ) holds, no invariant in G denies α(a), and a uses either compiler-issued initial authority or a valid live handle for α(a). G3. Grant soundness. If an authority instance outside the initial envelope enters Vt , then the audit log contains a grant whose rule γ ∈ Γ matched 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 grant g is satisfied by an observable event, then g and any authority instances visible only through g are 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 derives V0 from the compilerissued initial envelope and JPortico , so every executable instance is initial and checked against G. For the inductive step, IngestRuntimeObservation records events and AdjudicatePlannerRequest consumes them before the next planner call. Closed grants are removed from Lt ; Vt is then recomputed from initial authority, remaining live grants, and JPortico . A permitted call is already in the updated executable capability set and satisfies JPortico ; if it is grant-backed, its handle names a live epoch. New non-initial authority enters Vt+1 only after a GRANT return from a matching γ ∈ Γ that also passes G. 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.
α∈ / Init(E0 , τ, st ) ∧ α ∈ (Vt+1 \Vt ) ⇒ grant_rule_matches(β(α), st ) ∧ J(α, st+1 ). This implication concerns additions that are not compilerissued initial authority from E0 . The grant rule is checked in the pre-state. The transition mints a fresh runtime capability instance α for 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 . Here, c is the first planner turn after the monitor consumes the observable closure event for α’s current grant episode. Closure ends the current visibility episode. The same descriptor β(α) can become justified again only through a fresh runtime capability α′ minted by a new grant issued after c and still live at time t. 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 grant g closes before turn t, no invocation backed only by g should appear in the planner interface at t, and any replay of g’s handle should be rejected before it produces effects. Monitor guarantees. For P ORTICO, the desired properties become checkable relative to the compiled contract relation JPortico . This is the enforced property; the gap between J and JPortico 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); only the compiler initializes P = (E0 , Γ, Λ, 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′ and Vt′ denote the candidate state and derived executable capability set after pending observations and closures. Grant requests return GRANT; permitted invocations only consume authority already present in Vt′ .
5
P ORTICO as a Reference Monitor
P ORTICO sits between the planner and tools. It owns the lifecycle state around live grants Lt , derives the executable capability set Vt from the contract and live handles, and removes temporary authority at closure. Host isolation constrains execution after handoff. P ORTICO controls authority exposed to the planner before it. Inputs. P ORTICO uses three inputs: a task contract with initial scope, forbidden resources, declared expansions, and 5
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, and git push. Planner text can request authority; the monitor decides whether to grant it.
task: name: timeout propagation goal: propagate optional timeout 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: ["*"]
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.
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.
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 authorityrequest 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 shows the concrete P ORTICO interface next to the all-visible same-policy comparator. The timeout-boundary case reuses the API-to-serialization boundary from the running example. In P ORTICO, src/serialization.py can 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, P ORTICO removes the handle from the next interface and both policies reject stale replay before execution.
push, forbidden package mutation, and undeclared network egress are denied; unclassified commands require explicit approval or are denied. The guarantees in Section 4 cover mediated tool invocations only. Appendix B 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 into P = (E0 , Γ, Λ, G): initial envelope, grant rules, closure rules, and global deny rules. Figure 2 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 discusses that deployment risk. In this harness, subgoal_complete denotes 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 E0 from initial scope, maps operations to tools and privileges, maps paths and commands to resources, and turns network, dependency, and policy-vocabulary restrictions into G. Expansions become grant rules in Γ; lifetime clauses become closure predicates in Λ. 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 summarizes
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 against Vt and G. Global denies such as curl | sh, git 6
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. Moment
PORTICO interface
Schema shape
request_authority(selector,effect); same request endpoint plus broad proposal descrip- same policy; descriptors alone cannot exeread/write(handle enum) over initial and live tors; read/write still require initial or live handles cute effects handles initial API/test handles; serialization execution han- broad proposal surface includes the serialization same policy; authority request returns grant; dles absent; authority request available descriptor; no live serialization execution handle handles next turn initial handles plus live grant handles: g0001:r1 → broad proposal surface remains visible; execution same policy; invocation with live handle resrc/serialization.py (read/write); g0001:r2 → test- still requires the same live grant handles turns allow s/test_serialization.py (read) initial handles only; serialization grant handles ab- broad proposal surface remains visible; closed han- same policy; stale replay returns deny: stale sent dles are rejected at execution handle
Before request Grant live
After closure
All-visible same-policy interface
Algorithm 1: CompileEnvelope.
Table 3: Event provenance for grant and closure decisions. Planner text is advisory; trusted monitor or workflow events drive authority changes. Event
Source
Trust
Role in authority transition
Planner rationale Authority request and request.intent Focused test result
Model text Planner request over typed schema Process launched by monitor Orchestrator or runtime state Authenticated UI or policy hook Model text
Untrusted Advisory
No Selects candidate rule only Can close a grant Can close a grant Can grant or close No
Workflow subgoal or phase transition Human approval or revocation Textual subgoal_complete claim
Trusted Trusted Trusted Untrusted
Execution policy
:task contract τ; typed tool catalog T ; runtime profile ρ; policy vocabulary Ω Output :policy P = (E0 , Γ, Λ, G), initial capabilities V0 , and interface I0 Writes : E0 , Γ, Λ, G, V0 , and I0 1 Parse τ into scope, selectors, phase defaults, network mode, and dependency policy 2 Map declared operations through T to privileges, effects, argument constraints, and resource selectors 3 Apply runtime profile ρ to restrict available tools, sandbox mode, network mode, package-manager effects, and VCS effects 4 Build E0 = (T0 , Π0 , R0 ,C0 ) from the initial tools, privileges, resources, and constraints 5 Add forbidden paths, hosts, shell patterns, dependency restrictions, and VCS restrictions from τ and Ω to G 6 Compile each declared expansion into a grant rule γ ∈ Γ with trigger, selector, grant body, intent, and covered authority instances 7 Compile each lifetime clause into closure predicates Λ 8 Use trusted events such as monitor-launched tests passing, orchestrator subgoal completion, phase exit, run completion, or authenticated revoke for closure 9 Set V0 ← {α ∈ Init(E0 , τ, s0 ) | JPortico (α, s0 )} 10 Set I0 ← Exec(V0 ) ⊎ Prop(F0 ) ⊎ Req(Q0 ) 11 return P,V0 , I0 Input
the full path. Intent fields are advisory: grant matching uses tool/effect metadata, target selectors, monitor phase, contract triggers, and observable state. 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.
Running walkthrough. In the running trace, the packagingnote read is denied because no rule in Γ matches 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, Λ revokes the serialization grant before the next planner invocation. The handles disappear from the interface, and replaying one of them is denied before execution.
Runtime adjudication. Algorithms 1, 2, and 3 give the monitor procedures. Compilation builds P = (E0 , Γ, Λ, G), V0 , and I0 . 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, derives V from current live grants, checks invariants, and logs a structured decision. Grant rules are templates in Γ; grants are live instances that mint epoch-bound handles.
Configurations, audit, and integration. We evaluate P OR TICO core, which denies requests outside E0 , and P ORTICO
full, which adds request–grant–invoke with trusted closure. A grant extends only the targeted resource, tool schema, con7
6
Algorithm 2: AdjudicatePlannerRequest. Input :planner request q; state st ; policy P; catalog T Output : PERMIT, GRANT, or DENY Writes :live grants Lt , derived interface delta, and audit log At 1 s ← RefreshState(st , Ot , Λ) // consume observations and close grants 2 V ← DeriveCaps(E0 , s.L, τ, s) 3 β ← MapT (q, s.φ) // phase comes from monitor state 4 All returns commit the current s as st+1 5 if Violates(β, G) then 6 Append invariant reason to At ; return DENY 7 if q is an invocation then 8 α ← ResolveCap(q,V ) 9 if α is defined and α ∈ V and JPortico (α, s) then 10 Append permit to At ; return PERMIT 11 Append denial reason to At ; return DENY 12 if q is an authority request then 13 γ ← MatchGrant(Γ, β, s) 14 if γ is undefined then 15 Append denial reason to At ; return DENY 16 g ← IssueGrant(γ, s); add g to s.L 17 Vt+1 ← DeriveCaps(E0 , s.L, τ, s) 18 It+1 ← DeriveIface(Vt+1 , Ft+1 , Qt+1 ) 19 ∆I ← handles minted for g and exposed in It+1 20 Append grant record and ∆I to At ; return GRANT 21 Append denial reason to At ; return DENY
Experimental 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 [12, 13, 22, 25–27, 31, 32, 36, 40, 41, 53, 60]. 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?
Algorithm 3: IngestRuntimeObservation. Input :runtime result y for permitted invocation a; state st Output :updated observation buffer and audit log Writes :Ot and At 1 E ← TrustedEvents(y) // tests, workflow events, approvals, revokes 2 S ← ClassifiedSideEffects(y, a) 3 Drop planner-authored test, phase, subgoal, approval, or revoke claims from E 4 Append E ∪ S to Ot ; append y to At 5 Leave grant closure to the next call to AdjudicatePlannerRequest
• RQ4: Real-repository lifecycle. Does the same grant/revoke behavior appear on pinned real repositories? Section 7 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 gives their detailed run counts and purpose.
straint, and lifetime; closure removes that extension. The taskwide 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 backs portico-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 reports the compiled policy object and derivation audits.
Comparison targets. Table 4 lists the deployment baselines, P ORTICO variants, and causal comparators. The baselines expose broad access, a fixed allowlist, or coarse sandbox restrictions, without treating the task contract as a lifecycle policy. P ORTICO core uses only the initial envelope; P OR TICO full adds request–grant–invoke with trusted closure. The non-revoking comparator disables only revocation, while the 8
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.
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, P OR TICO , 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.
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.
Manifest, audit, and execution protocol. Each episode is a checked-in manifest. The timeout-propagation witness declares src/serialization.py as the escalation target and lists notes/packaging.md only as a forbidden resource and attack lure (Appendix A). 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.
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.
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 codingspecific, so claims stay within this policy family and domain.
7
Results
The results follow the lifecycle: exposure, expansion, closure, and real-repository integration. P ORTICO full 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 summarizes the security–utility trade-off. P ORTICO full trades maximum completion for scope control, turning some unsafe or overbroad completions into scoped success or visible incompleteness.
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 9
Table 4: Comparison targets. Baselines test deployment exposure; P ORTICO variants test capability minimization and grant/revoke; the comparators isolate closure and execution-time filtering. Condition
Planner interface
What it controls
What it cannot show alone
Full access
Full tool menu and broad resources
Least privilege, semantic scoping, or closure.
Static allowlist
Fixed task-independent allowlist plus basic path restrictions Workspace confinement, sensitive-path denies, egress and process restrictions Initial task-derived envelope only
Raw model behavior under maximum exposed authority Coarse tool availability and basic resource reachability Post-handoff reachability after a tool call is selected
Coarse sandbox P ORTICO core P ORTICO full Task-wide revoking
non-
All-visible policy
same-
Coarse all-visible action filter
Initial envelope plus request–grant–invoke lifecycle with trusted closure Same initial envelope and same grant timing as P ORTICO full, but grants persist after closure Broad proposal interface over resources, with P ORTICO’s execution-time policy, grant timing, handle checks, and closure events Broad proposal interface over resources plus invocation-time checks, including closedgrant stale-handle denial
Capability minimization, semantic checks, global deny rules, and auditability Controlled expansion and closure of temporary capabilities Same task policy, same boundary recovery, and unsupported-probe denial, but no revocation Interface breadth versus late enforcement under the same semantic policy Whether late denial is enough when adjacent capabilities remain exposed to the planner
Full Static Sandbox P ORTICO full P ORTICO core
Suite A viol. ↓ Suite A blast ↓ Suite B succ. ↑ Suite B scope ↑ Suite C succ. ↑ Suite C scope ↑ Suite C viol. ↓
1.00 6.65 0.97 0.92 1.00 0.69 0.31
0.82 2.73 0.97 0.92 1.00 0.70 0.30
0.86 4.09 0.97 0.91 1.00 0.70 0.30
0.00 0.00 0.87 1.00 1.00 1.00 0.00
Whether the post-closure proposal difference generalizes or causes harm under imperfect mediation. It is a deployment diagnostic, not the closure comparator with the same grant timing; adjacent-pressure rows use a coarser filter and can permit oracle-forbidden detours.
7.2 RQ2: Grants Recover Legitimate Boundary Work
Table 5: Global trade-off snapshot from the main Qwen3Coder 30B study: five reproducibility repeats per scenario or episode over 17 Suite-A scenarios, 37 Suite-B episodes, and 14 Suite-C episodes. Metric
Task- and phase-specific distinction between two uses of the same primitive. Which admissible capabilities should be exposed for the current task state. Legitimate work that requires later boundary expansion. Whether a non-revoking design could match utility without bounded visibility. Whether stale capabilities persist when only revocation is removed.
Core is safe but brittle. P ORTICO core 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.
0.00 0.00 0.21 1.00 0.94 1.00 0.00
Controlled grants recover the boundary. P ORTICO full improves the main Suite-B result from P ORTICO core’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, isolates benign boundary tasks: static allowlist succeeds by exposing secondary authority upfront, P ORTICO core overblocks, and P ORTICO full restores 20/20 successes in scope with one grant per task on average. A larger boundary pack repeats the pattern: P OR TICO full 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.
7.1 RQ1: 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. Both P ORTICO variants 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 the P ORTICO rows.
P ORTICO incurs a measurable utility cost. P ORTICO full 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, P OR TICO full completes all 14 episodes in scope across 70/70 repeats. Appendix B attributes P ORTICO misses to narrow grants, missing request options, conservative contaminatedcontext blocking, and planner/model instability. These misses are visible utility cost; the traces remain scope-compliant.
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; P ORTICO completes all 20/20 in scope with 0.00 violations. The failure is a missing resource/effect/phase distinction in the visible interface. 10
P ORTICO full: bounded capabilities
Latent not visible
Request boundary capability
Grant becomes visible
Justified use boundary work
Closure remove authority
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; P ORTICO invalidates it before effects.
Late reread denied
temporary justified visibility window Task-wide non-revoking comparator: same grant, no closure revoke disabled Same initial envelope
Same request
Same grant same turn
Same justified use
No close still visible
Condition
Late reread allowed
PORTICO full Non-revoking comparator Coarse all-visible action filter
Figure 3: Semantic meaning of authority closure. Both rows start from the same initial envelope and issue the same grant at the same point; only P ORTICO removes that authority before late reread.
Success Scope Contract-labeled forbidden effects Late reread allowed Late reread denied
P ORTICO full
Non-revoking
10/10 10/10 0/10 0/10 10/10
10/10 10/10 0/10 10/10 0/10
6 6 6
0/6 6/6 0/6
0/6 6/6 0/6
Table 8: Live stale-effect follow-up. A scripted contaminatedagent 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.
Table 6: Late-reread closure comparison. The task-wide nonrevoking comparator starts with the same initial envelope as P ORTICO full 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; only P ORTICO removes the temporary authority before post-closure reuse. Dedicated lifecycleoracle rows score post-closure reuse separately from contractlabeled resource/effect violations. Endpoint
Cases Stale cap. accepted Executed forbidden effect
Condition
Live use Stale effects File Git Network
PORTICO full 6/6 0/6 0/2 0/2 0/2 Non-revoking comparator 6/6 6/6 2/2 2/2 2/2 All-visible same-policy 6/6 0/6 0/2 0/2 0/2 Family columns report executed stale effects in two cases each.
misuse family against an oracle file separate from the deployment contract and not read by the monitor. P ORTICO rejects 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.
7.3 RQ3: Closure Removes Temporary Authority
Post-closure effects. Table 7 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. P ORTICO accepts 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 allvisible 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.
Strong non-revoking comparator. The task-wide nonrevoking comparator starts with the same initial envelope as P ORTICO full, 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 latereread endpoint measures remaining stale capability. Non-revoking comparison. Figure 3 shows the split. The comparator supports the same legitimate use, but keeps the stale capability available after the subgoal. Table 6 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. P OR TICO full denies reuse in 10/10 runs, while the non-revoking comparator allows it in 10/10. The endpoint is residual stalecapability availability after closure. The trace records the mechanism behind this split: the boundary request mints an epoch-bound handle such as g0001:r1, the next planner interface includes it, and closure marks it inactive. Appendix Table 13 audits the post-grant
Live stale-effect follow-ups. Table 8 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; P OR TICO and 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. 11
access, P ORTICO, and the non-revoking comparator: GPT5.5 and Claude complete 3/3 under P ORTICO and no-revoke, Gemini completes 1/3 under both, and all three preserve scope with zero violations under P ORTICO and 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.
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. Condition
Live use Stale effects File Git Network
PORTICO full 6/6 0/6 0/2 0/2 0/2 Non-revoking comparator 6/6 6/6 2/2 2/2 2/2 All-visible same-policy 6/6 0/6 0/2 0/2 0/2 Family columns report executed stale effects in two cases each.
7.4 RQ4: Lifecycle Behavior Appears on Real Repositories
Table 10: Action-filter visibility diagnostic on the post-closure family. The all-visible same-policy condition keeps a broad planner interface but uses P ORTICO’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. Condition P ORTICO full All-visible same-policy Task-wide non-revoking Coarse all-visible action filter
Ep./Runs
Succ.
Scope
Exec. viol.
Blocked avg/total
4/20 4/20 4/20 4/20
5/20 5/20 5/20 20/20
20/20 20/20 20/20 15/20
0/20 0/20 0/20 10/20
3.35/67 4.20/84 3.00/60 1.25/25
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, P ORTICO full, the samegrant 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. Only P ORTICO full 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, P OR TICO succeeds 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.
Action filtering controls a later point. Table 10 separates two all-visible readings. The all-visible same-policy comparator keeps broad planner visibility but uses P ORTICO’s policy, grants, handle checks, and closure. It matches P ORTICO on 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; P ORTICO records fewer blocked proposals in three episodes and ties in one (Appendix Table 13). The difference is in failures, where broad visibility blocks 74 proposals versus 57 for P ORTICO. 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 samepolicy 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 for P ORTICO. 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 effects P ORTICO would 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.
Integration reading. A representative Flask run patches src/flask/sessions.py, receives a declared read-only boundary grant for src/flask/app.py, and then denies a packaging detour to pyproject.toml because it is outside both the initial envelope and the grant. Detailed realrepository tables are in Appendix B.
8
Discussion
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. P ORTICO removes 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
Supporting checks. We repeat the closure split across additional lifecycle and hardening slices (Appendix B). A supplementary frontier slice runs the grant-lifecycle episodes on GPT-5.5, Gemini 3.5 Flash, and Claude Opus 4.8 under full 12
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.
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 [43, 50, 51]. Short-lived credentials, leases, epoch invalidation, and usage-control systems make lifetime part of policy in other settings [14, 39]. P ORTICO applies 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.
Utility and contracts. P ORTICO prioritizes 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 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.
Runtime least privilege and isolation. Runtimeenforcement and policy-compilation systems, including AgentSpec, PCAS, Maris, MiniScope, AgentBound, CaMeL, PFI, and Progent, make execution-time mediation and dynamic policy practical [7, 9, 10, 23, 38, 45, 48, 61]. CMTF, RACG, Contract2Tool, and ContractGuard study visible tool menus, preconditions, effects, and contract integrity [3, 4, 19, 20]. P ORTICO differs 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; P ORTICO applies those ideas to temporary capabilities whose stale replay is rejected. Isolation and execution-structure systems constrain reachability or handoff structure [28, 34, 35, 47, 52, 55, 59]; P ORTICO assumes such mediation and makes a narrower resource/effect lifetime visible to the planner and enforceable at execution.
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. The portico-tool smoke 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.
9
10
Conclusion
Coding-agent authority has a lifetime. P ORTICO makes 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; P ORTICO denies 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.
Related Work
Adjacent defenses. Prompt-injection and misuse benchmarks show that untrusted content can redirect tool-using agents, including tool-selection hijacking before sandbox handoff [1, 2, 11, 42, 44, 56–58]. Guardrails and firewalls sanitize prompts or filter proposed actions [5, 6, 8, 24, 46]. MCPsecurity and tool-poisoning research covers descriptor discovery, provenance, poisoning, and trust propagation [15–18, 21, 29, 33, 37, 49, 54]. P ORTICO starts after that layer: it assumes 13
Ethical Considerations
Artifact and Reproduction Map
This work studies how to reduce harmful authority in toolusing 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: P ORTICO is 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 outside P ORTICO’s guarantees. A real deployment should combine the monitor with host isolation, credential management, approval paths for unusual expansions, and audit review.
The companion repository is organized for direct audit of the paper artifact. The primary reproduction package lives under submission_artifact/; the root README.md, ARTIFACT. md, REPRODUCING.md, and RESULTS.md explain the layout, frozen roots, regenerated tables, and short audit commands. The standalone public MCP tool lives under portico-tool/. It is useful for trying the request–grant–invoke lifecycle in a workspace, but the paper results are reproduced from submission_artifact/. The decision-core packages under src/portico/ and submission_artifact/library/ are support code rather than the main artifact entry point. Manifest and contract validity can be checked from submission_artifact/benchmark_v2/manifests/ with submission_artifact/scripts/validate_ benchmark_v2.py. The main A–C results come from qwen3_coder_30b_primary_r5_v1, submission_ artifact/benchmark_v2/results/checkpoints.json, and generate_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 roots qwen3_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 under submission_artifact/ benchmark_v2/oracles/. The relevant generators are generate_capability_lifecycle_oracle_audit.py, generate_capability_stale_effects.py, generate_capability_protocol_overhead_audit.py, and generate_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 under frontier_coding_matrix_handle_fix_v1 and its matching no-P ORTICO baseline is under frontier_coding_matrix_no_portico_v1. The public MCP integration is documented in portico-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, and openhands_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 modelevaluation results. The portico-tool-smoke executable and submission_artifact/Makefile targets such as make mcp-smoke provide local checks that require no provider credentials. Suite D evidence is under submission_artifact/
Open Science An anonymized open-science companion repository for this submission is available at 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 under portico-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. 14
benchmark_v2/real_repo_suite_d_v1/ and the Qwen3 result roots qwen3_real_repo_boundary_ classic_baselines_v1, qwen3_real_repo_expansion_ classic_baselines_v1, qwen3_real_repo_boundary_ lifecycle_comparators_v1, and qwen3_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 under compound_mediation_audit_v1. Contract footprint, transfer, and sensitivity evidence lives under policy_derivation_audit_v1, policy_derivation_ transfer_v2, and contract_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.
Dvijotham, and Alexandre Lacoste. Indirect prompt injections: Are firewalls all you need, or stronger benchmarks? arXiv:2510.05244, 2025. [7] Christoph Bühler, Matteo Biagiola, Luca Di Grazia, and Guido Salvaneschi. AgentBound: Securing execution boundaries of AI agents. Proceedings of the ACM on Software Engineering, 3(FSE), 2026. [8] Sahana Chennabasappa, Cyrus Nikolaidis, Daniel Song, David Molnar, Stephanie Ding, Shengye Wan, Spencer Whitman, Lauren Deason, Nicholas Doucette, Abraham Montilla, Alekhya Gampa, Beto de Paola, Dominik Gabi, James Crnkovich, Jean-Christophe Testud, Kat He, Rashnil Chaturvedi, Wu Zhou, and Joshua Saxe. LlamaFirewall: An open source guardrail system for building secure AI agents. arXiv:2505.03574, 2025. [9] Jian Cui, Zichuan Li, Luyi Xing, and Xiaojing Liao. Maris: A formally verifiable privacy policy enforcement paradigm for multi-agent collaboration systems. arXiv:2505.04799, 2025.
References [1] Sahar Abdelnabi, Kai Greshake, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz. Not what you’ve signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection. In Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security, AISec ’23, pages 79–90, Copenhagen, Denmark, 2023. Association for Computing Machinery.
[10] Edoardo Debenedetti, Ilia Shumailov, Tianqi Fan, Jamie Hayes, Nicholas Carlini, Daniel Fabian, Christoph Kern, Chongyang Shi, Andreas Terzis, and Florian Tramèr. Defeating prompt injections by design. In IEEE Conference on Secure and Trustworthy Machine Learning (SaTML), Munich, Germany, 2026.
[2] Maksym Andriushchenko, Alexandra Souly, Mateusz Dziemian, Derek Duenas, Maxwell Lin, Justin Wang, Dan Hendrycks, Andy Zou, J. Zico Kolter, Matt Fredrikson, Yarin Gal, and Xander Davies. AgentHarm: A benchmark for measuring harmfulness of LLM agents. In The Thirteenth International Conference on Learning Representations, Singapore, 2025. OpenReview.net.
[11] Edoardo Debenedetti, Jie Zhang, Mislav Balunovic, Luca Beurer-Kellner, Marc Fischer, and Florian Tramèr. AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents. In Advances in Neural Information Processing Systems, volume 37, pages 82895–82920, Vancouver, BC, Canada, 2024. Curran Associates, Inc.
[3] Rahul Suresh Babu and Laxmipriya Ganesh Iyer. Contract2Tool: Learning preconditions and effects for reliable tool-augmented LLM agents. arXiv:2606.07904, 2026.
[12] Xiang Deng, Yu Gu, Boyuan Zheng, Shijie Chen, Sam Stevens, Boshi Wang, Huan Sun, and Yu Su. Mind2Web: Towards a generalist agent for the web. In Advances in Neural Information Processing Systems, volume 36, pages 28091–28114, New Orleans, LA, USA, 2023. Curran Associates, Inc.
[4] Rahul Suresh Babu and Laxmipriya Ganesh Iyer. ToolChoiceConfusion: Causal minimal tool filtering for reliable LLM agents. arXiv:2606.06284, 2026. [5] Luca Beurer-Kellner, Beat Buesser, Ana-Maria Creţu, Edoardo Debenedetti, Daniel Dobos, Daniel Fabian, Marc Fischer, David Froelicher, Kathrin Grosse, Daniel Naeff, Ezinwanne Ozoani, Andrew Paverd, Florian Tramèr, and Václav Volhejn. Design patterns for securing LLM agents against prompt injections. arXiv:2506.08837, 2025.
[13] Alexandre Drouin, Maxime Gasse, Massimo Caccia, Issam H. Laradji, Manuel Del Verme, Tom Marty, David Vázquez, Nicolas Chapados, and Alexandre Lacoste. WorkArena: How capable are web agents at solving common knowledge work tasks? In Forty-first International Conference on Machine Learning, volume 235 of Proceedings of Machine Learning Research, pages 11642–11662, Vienna, Austria, 2024. PMLR.
[6] Rishika Bhagwatkar, Kevin Kasa, Abhay Puri, Gabriel Huang, Irina Rish, Graham W. Taylor, Krishnamurthy Dj
[14] Cary G. Gray and David R. Cheriton. Leases: An efficient fault-tolerant mechanism for distributed file cache 15
consistency. In Proceedings of the Twelfth ACM Symposium on Operating Systems Principles, pages 202–210, 1989.
VisualWebArena: Evaluating multimodal agents on realistic visual web tasks. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pages 881–905, Bangkok, Thailand, 2024. Association for Computational Linguistics.
[15] Yongjian Guo, Puzhuo Liu, Wanlun Ma, Zehang Deng, Xiaogang Zhu, Peng Di, Xi Xiao, and Sheng Wen. MCPXKIT: The unified toolkit for analyzing model context protocol security. arXiv:2508.12538, 2025.
[26] Quyu Kong, Xu Zhang, Zhenyu Yang, Nolan Gao, Chen Liu, Panrong Tong, Chenglin Cai, Hanzhang Zhou, Jianan Zhang, Liangyu Chen, Zhidan Liu, Steven Hoi, and Yue Wang. MobileWorld: Benchmarking autonomous mobile agents in agent-user interactive and MCP-augmented environments. arXiv:2512.19432, 2025.
[16] Xinyi Hou, Shenao Wang, Yifan Zhang, Ziluo Xue, Yanjie Zhao, Cai Fu, and Haoyu Wang. SMCP: Secure model context protocol. arXiv:2602.01129, 2026. [17] Xinyi Hou, Yanjie Zhao, Shenao Wang, and Haoyu Wang. Model context protocol (MCP): Landscape, security threats, and future research directions. arXiv:2503.23278, 2025.
[27] Juyong Lee, Taywon Min, Minyong An, Dongyoon Hahm, Haeone Lee, Changyeon Kim, and Kimin Lee. Benchmarking mobile device control agents across diverse configurations. arXiv:2404.16660, 2024.
[18] Yuepeng Hu, Yuqi Jia, Mengyuan Li, Dawn Song, and Neil Gong. MalTool: Malicious tool attacks on LLM agents. arXiv:2602.12194, 2026.
[28] Evan Li, Tushin Mallick, Evan Rose, William Robertson, Alina Oprea, and Cristina Nita-Rotaru. ACE: A security architecture for LLM-integrated app systems. In Network and Distributed System Security Symposium (NDSS), San Diego, CA, USA, 2026. The Internet Society.
[19] Laxmipriya Ganesh Iyer and Rahul Suresh Babu. Capability minimization as a safety primitive: Riskaware causal gating for least-privilege LLM agents. arXiv:2606.13884, 2026. [20] Laxmipriya Ganesh Iyer and Rahul Suresh Babu. The gate is only as honest as its contracts: ContractGuard for the contract layer of risk-aware causal gating. arXiv:2606.18550, 2026.
[29] Ruiqi Li, Zhiqiang Wang, Yunhao Yao, and Xiang-Yang Li. MCP-ITP: An automated framework for implicit tool poisoning in MCP. arXiv:2601.07395, 2026.
[21] Saeid Jamshidi, Arghavan Moradi Dakhel, Kawser Wazed Nafi, and Foutse Khomh. Semantic attacks on tool-augmented LLMs: Securing the model context protocol against descriptor-level manipulation. arXiv:2512.06556, 2025.
[30] Linux man-pages project. seccomp(2) — Linux manual page. Linux man-pages project, 2025. [31] Xiao Liu, Hao Yu, Hanchen Zhang, Yifan Xu, Xuanyu Lei, Hanyu Lai, Yu Gu, Hangliang Ding, Kaiwen Men, Kejuan Yang, Shudan Zhang, Xiang Deng, Aohan Zeng, Zhengxiao Du, Chenhui Zhang, Sheng Shen, Tianjun Zhang, Yu Su, Huan Sun, Minlie Huang, Yuxiao Dong, and Jie Tang. AgentBench: Evaluating LLMs as agents. In The Twelfth International Conference on Learning Representations, Vienna, Austria, 2024. OpenReview.net.
[22] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik R. Narasimhan. SWE-bench: Can language models resolve real-world GitHub issues? In The Twelfth International Conference on Learning Representations, Vienna, Austria, 2024. OpenReview.net. [23] Juhee Kim, Woohyuk Choi, and Byoungyoung Lee. Prompt flow integrity to prevent privilege escalation in LLM agents. arXiv:2503.15547, 2025.
[32] Chang Ma, Junlei Zhang, Zhihao Zhu, Cheng Yang, Yujiu Yang, Yaohui Jin, Zhenzhong Lan, Lingpeng Kong, and Junxian He. AgentBoard: An analytical evaluation board of multi-turn LLM agents. In Advances in Neural Information Processing Systems, volume 37, pages 74325–74362, Vancouver, BC, Canada, 2024. Curran Associates, Inc.
[24] Minbeom Kim, Mihir Parmar, Phillip Wallis, Lesly Miculicich, Kyomin Jung, Krishnamurthy Dj Dvijotham, Long T. Le, and Tomas Pfister. CausalArmor: Efficient indirect prompt injection guardrails via causal attribution. arXiv:2602.07918, 2026.
[33] Narek Maloyan and Dmitry Namiot. Breaking the protocol: Security analysis of the model context protocol specification and prompt injection vulnerabilities in toolintegrated LLM agents. arXiv:2601.17549, 2026.
[25] Jing Yu Koh, Robert Lo, Lawrence Jang, Vikram Duvvur, Ming Chong Lim, Po-Yu Huang, Graham Neubig, Shuyan Zhou, Russ Salakhutdinov, and Daniel Fried. 16
[34] Rahul Marchand, Art O Cathain, Jerome Wynne, Philippos Maximos Giavridis, Sam Deverett, John Wilkinson, Jason Gwartz, and Harry Coppock. Quantifying frontier LLM capabilities for container sandbox escape. arXiv:2603.02277, 2026.
[44] Jiawen Shi, Zenghui Yuan, Guiyao Tie, Pan Zhou, Neil Zhenqiang Gong, and Lichao Sun. Prompt injection attack to tool selection in LLM agents. In Network and Distributed System Security Symposium (NDSS), San Diego, CA, USA, 2026. The Internet Society.
[35] Luoxi Meng, Henry Feng, Ilia Shumailov, and Earlence Fernandes. ceLLMate: Sandboxing browser AI agents. arXiv:2512.12594, 2025.
[45] Tianneng Shi, Jingxuan He, Zhun Wang, Linyu Wu, Hongwei Li, Wenbo Guo, and Dawn Song. Progent: Securing AI agents with privilege control. arXiv:2504.11703, 2025.
[36] Grégoire Mialon, Clémentine Fourrier, Thomas Wolf, Yann LeCun, and Thomas Scialom. GAIA: A benchmark for general AI assistants. In The Twelfth International Conference on Learning Representations, Vienna, Austria, 2024. OpenReview.net.
[46] Tianneng Shi, Kaijie Zhu, Zhun Wang, Yuqi Jia, Will Cai, Weida Liang, Haonan Wang, Hend Alzahrani, Joshua Lu, Kenji Kawaguchi, Basel Alomair, Xuandong Zhao, William Yang Wang, Neil Gong, Wenbo Guo, and Dawn Song. PromptArmor: Simple yet effective prompt injection defenses. arXiv:2507.15219, 2025.
[37] Kanghua Mo, Li Hu, Yucheng Long, and Zhihao Li. Attractive metadata attack: Inducing LLM agents to invoke malicious tools. arXiv:2508.02110, 2025.
[47] Georgios Syros, Anshuman Suri, Jacob Ginesin, Cristina Nita-Rotaru, and Alina Oprea. SAGA: A security architecture for governing AI agentic systems. In Network and Distributed System Security Symposium (NDSS), San Diego, CA, USA, 2026. The Internet Society.
[38] Nils Palumbo, Sarthak Choudhary, Jihye Choi, Guy Amir, Prasad Chalasani, and Somesh Jha. Formal policy enforcement for real-world agentic systems. arXiv:2602.16708, 2026.
[48] Haoyu Wang, Christopher M. Poskitt, and Jun Sun. AgentSpec: Customizable runtime enforcement for safe and reliable LLM agents. In Proceedings of the IEEE/ACM International Conference on Software Engineering (ICSE 2026), pages 1–12, Rio de Janeiro, Brazil, 2026. Association for Computing Machinery.
[39] Jaehong Park and Ravi Sandhu. The UCONABC usage control model. ACM Transactions on Information and System Security, 7(1):128–174, 2004. [40] Muhammad Shihab Rashid, Christian Bock, Yuan Zhuang, Alexander Buccholz, Tim Esler, Simon Valentin, Luca Franceschi, Martin Wistuba, Prabhu Teja Sivaprasad, Woo Jung Kim, et al. SWE-PolyBench: A multi-language benchmark for repository-level evaluation of coding agents. arXiv:2504.08703, 2025.
[49] Zhiqiang Wang, Yichao Gao, Yanting Wang, Suyuan Liu, Haifeng Sun, Haoran Cheng, Guanquan Shi, Haohua Du, and Xiangyang Li. MCPTox: A benchmark for tool poisoning attack on real-world MCP servers. arXiv:2508.14925, 2025.
[41] Chris Rawles, Sarah Clinckemaillie, Yifan Chang, Jonathan Waltz, Gabrielle Lau, Marybeth Fair, Alice Li, William Bishop, Wei Li, Folawiyo Campbell-Ajala, Daniel Toyama, Robert Berry, Divya Tyamagundlu, Timothy Lillicrap, and Oriana Riva. AndroidWorld: A dynamic benchmarking environment for autonomous agents. In The Thirteenth International Conference on Learning Representations, Singapore, 2025. OpenReview.net.
[50] Robert N. M. Watson, Jonathan Anderson, Ben Laurie, and Kris Kennaway. Capsicum: Practical capabilities for UNIX. In 19th USENIX Security Symposium (USENIX Security 2010), pages 29–44, Washington, DC, USA, 2010. USENIX Association. [51] Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Simon W. Moore, Jonathan Anderson, David Chisnall, Nirav Dave, Brooks Davis, Khilan Gudka, and Ben Laurie. CHERI: A hybrid capability-system architecture for scalable software compartmentalization. In 2015 IEEE Symposium on Security and Privacy, pages 20–37, San Jose, CA, USA, 2015. IEEE Computer Society.
[42] Yangjun Ruan, Honghua Dong, Andrew Wang, Silviu Pitis, Yongchao Zhou, Jimmy Ba, Yann Dubois, Chris J. Maddison, and Tatsunori Hashimoto. ToolEmu: Identifying the risks of LM agents with an LM-emulated sandbox. In The Twelfth International Conference on Learning Representations, Vienna, Austria, 2024. OpenReview.net.
[52] Yuhao Wu, Franziska Roesner, Tadayoshi Kohno, Ning Zhang, and Umar Iqbal. IsolateGPT: An execution isolation architecture for LLM-based systems. In Network and Distributed System Security Symposium (NDSS), San Diego, CA, USA, 2025. The Internet Society.
[43] Jerome H. Saltzer and Michael D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278–1308, 1975. 17
A
[53] Tianbao Xie, Danyang Zhang, Jixuan Chen, Xiaochuan Li, Siheng Zhao, Ruisheng Cao, Toh Jing Hua, Zhoujun Cheng, Dongchan Shin, Fangyu Lei, Yitao Liu, Yiheng Xu, Shuyan Zhou, Silvio Savarese, Caiming Xiong, Victor Zhong, and Tao Yu. OSWorld: Benchmarking multimodal agents for open-ended tasks in real computer environments. In Advances in Neural Information Processing Systems, volume 37, pages 52040–52094, Vancouver, BC, Canada, 2024. Curran Associates, Inc.
Representative 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 timeoutboundary witness (artifact ID B9-02), the task starts with src/api.py, tests/test_api.py, and focused pytest. The contract declares src/serialization.py as an on-demand timeout-propagation boundary and lists notes/packaging. md as a forbidden side resource. P ORTICO denies 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.
[54] Yixuan Yang, Cuifeng Gao, Daoyuan Wu, Yufan Chen, Yingjiu Li, and Shuai Wang. MCPSecBench: A systematic security benchmark and playground for testing model context protocols. arXiv:2508.13220, 2025. [55] Zhongming Yu, Naicheng Yu, Hejia Zhang, Wentao Ni, Mingrui Yin, Jiaying Yang, Yujie Zhao, and Jishen Zhao. Multi-agent memory from a computer architecture perspective: Visions and challenges ahead. arXiv:2603.10062, 2026. [56] Qiusi Zhan, Zhixiang Liang, Zifan Ying, and Daniel Kang. InjecAgent: Benchmarking indirect prompt injections in tool-integrated large language model agents. In Findings of the Association for Computational Linguistics: ACL 2024, pages 10471–10506, Bangkok, Thailand, 2024. Association for Computational Linguistics.
Temporary read closure. In the temporary-note witness (artifact ID B8-05), the renderer-repair contract keeps local source, focused tests, and pytest visible. A recheck note is available only through a temporary read grant. P ORTICO grants the note for inspection, consumes the trusted subgoalclose 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.
[57] Hanrong Zhang, Jingyuan Huang, Kai Mei, Yifei Yao, Zhenting Wang, Chenlu Zhan, Hongwei Wang, and Yongfeng Zhang. Agent security bench (ASB): Formalizing and benchmarking attacks and defenses in LLM-based agents. In The Thirteenth International Conference on Learning Representations, Singapore, 2025. OpenReview.net. [58] Jinchuan Zhang, Lu Yin, Yan Zhou, and Songlin Hu. AgentAlign: Navigating safety alignment in the shift from informative to agentic large language models. arXiv:2505.23020, 2025.
Same-grant stale handle. The stale-handle family gives P ORTICO and the non-revoking comparator the same initial envelope, the same authority request, and the same grant at the same turn. After closure, P ORTICO rejects replay because the epoch is closed. The comparator keeps the same handle live. This witness is the minimal trace for isolating capability lifetime.
[59] Yusheng Zheng, Jiakun Fan, Quanzhi Fu, Yiwei Yang, Wei Zhang, and Andi Quinn. AgentCgroup: Understanding and controlling OS resources of AI agents. arXiv:2602.09345, 2026. [60] Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, and Graham Neubig. WebArena: A realistic web environment for building autonomous agents. In The Twelfth International Conference on Learning Representations, Vienna, Austria, 2024. OpenReview.net.
B
Protocol 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, realrepository evidence, public-tool smoke roots, and the contract robustness audits. Full per-episode tables, manifest JSON, and CSV outputs remain in the artifact.
[61] Jinhao Zhu, Kevin Tseng, Gil Vernik, Xiao Huang, Shishir G. Patil, Vivian Fang, and Raluca Ada Popa. MiniScope: A least privilege framework for authorizing tool calling agents. arXiv:2512.11147, 2025. 18
Table 11: Benchmark suites. Suites A–C are controlled fixtures; Suite D uses pinned real repositories. All contracts are fixed before execution. Suite
Runs
A
17 scenarios × 5 repeats Unsafe exposure with reachable lures per condition and explicit forbidden resources. 37 episodes × 5 repeats Scoped repair, boundary grants, closure, per condition and same-policy diagnostics. 14 episodes × 5 repeats Legitimate coding goals surrounded by per condition hostile or overscoped context. 14 episodes; 84 Qwen3 Boundary grants and closure on pinned real-repository runs; Python project layouts. 126 supplementary local/API-backed lifecycle runs
B C D
Table 14: Supplementary API-backed frontier lifecycle slice. The same three grant-lifecycle episodes run under full access, P ORTICO, and the non-revoking comparator. This is a narrow protocol check, not the main utility matrix.
Purpose
Profile
Condition
GPT-5.5 GPT-5.5 GPT-5.5
Full access P ORTICO full Non-revoking comparator
3/3 3/3 3/3
1/3 3/3 3/3
2/3 0/3 0/3
– 3/3 3/3
Gemini 3.5 Flash Gemini 3.5 Flash Gemini 3.5 Flash
Full access P ORTICO full Non-revoking comparator
3/3 1/3 1/3
3/3 3/3 3/3
0/3 0/3 0/3
– 3/3 3/3
Claude Opus 4.8 Claude Opus 4.8 Claude Opus 4.8
Full access P ORTICO full Non-revoking comparator
3/3 3/3 3/3
3/3 3/3 3/3
0/3 0/3 0/3
– 3/3 3/3
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 is B9-02. Object
Concrete value
Table 15: Protocol hardening coverage.
Runtime effect
Case family
API source, API test, fo- Visible at task start. cused pytest Always denied by invariants. Forbidden re- notes/packaging.md, sources secrets, git push, network egress Grant rule γ src/serialization.py; Minted only by the declared read/write; focused serial- boundary request. ization tests Closure λ trusted test pass, trusted sub- Removes the grant handles begoal close, or phase exit fore later turns. Scoring labels success and violation predi- Used by scorer; not produced cates from the manifest by planner rationale. Initial handles
Setup
Expected decision pattern
Free-path bypass and path Ambient path attempts are denied unless they resolve aliases to an initial or live handle. Scope and effect mis- A handle for one resource/effect cannot authorize a match different resource/effect. Phase exit and stale replay Closure invalidates the epoch; replay is rejected before effects. Selector provenance Planner-authored rationale selects a candidate rule but cannot create authority. Stale file/git/network ef- P ORTICO and all-visible same-policy execute 0/6 fects stale effects; non-revoking executes 6/6.
Table 13: Closure and visibility diagnostics. These checks separate capability lifetime from late execution filtering. Diagnostic
Success Scope Viol. Grants
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.
Endpoint
Same-grant closure
Same initial envelope, P ORTICO denies 10/10 stale same request, same grant reuses; non-revoking permits turn. 10/10. Same-policy visibil- Same execution policy and Both execute 0/20 forbidden ity closure; broader proposal effects; blocked proposals are interface. 67 vs. 84. Boundary-extension Eight adaptive boundary Both execute 0/8 forbidden efvisibility episodes outside the post- fects; blocked proposals are closure family. 48 vs. 39. Frontier lifecycle Three grant-lifecycle The slice compares full slice episodes across three API- access, P ORTICO, and nonbacked model profiles. revoking runs. Local cross-model Same closure endpoint Security direction persists; persistence across local model back- utility varies by model/runbones. time.
Slice
P ORTICO endpoint
Comparator reading
Qwen3 real- P ORTICO full succeeds Full, Static, Sandbox, same-grant repository matrix, 84 14/14 with 14/14 no-revoke, and coarse all-visible runs scope, 0/14 violations, action filter each succeed 14/14 and grants on 14/14 with 14/14 scope and 0/14 violacontracts. tions. Supplementary Pal- Success 4/6, scope 6/6, Whole-task no-revoke succeeds lets boundary cells, violations 0/6. 6/6 without revocation; coarse 18 runs all-visible succeeds 6/6 with 9 blocked proposals. Supplementary expan- Success 27/36, scope Whole-task no-revoke succeeds sion cells, 108 runs 36/36, violations 0/36. 36/36; coarse all-visible succeeds 35/36 with 42 blocked proposals.
19
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 17: Contract derivation and sensitivity. These audits characterize the checked-in contract layer; they do not claim automatic policy synthesis. Audit
Headline result
Reading
Template coverage
Eight deterministic Contracts are not pertemplates cover the 70- episode code paths. episode corpus. Holdout transfer 35/36 paper-subset hold- Template reuse transfers outs match structures de- within the checked-in corrived from non-paper man- pus. ifests. Timeout-boundary sensi- Removing expansion The monitor inherits contivity blocks the boundary; tract quality. initial visibility removes the grant; wrong-note expansion causes the expected violation.
Table 19: Utility misses on the main repeat-strengthened checkpoint.
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.
Failure class
Runs
Interpretation
Missing action option
15
Narrow grant insufficient
20
Planner/model instability
15
Helper-file creation, documentation cross-read, or multi-target patching is not expressed cleanly. The declared expansion stays too small, so runs stop early without measured violations. Dedicated reruns recover several cases, so the miss is not always a policy failure. Zero violations are preserved, but adjacent benign reads or writes can be suppressed.
Conservative poisoned- 30 context blocking
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.
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 18: Protocol invariants to inspect in the artifact.
Table 20: How to read utility loss under bounded closure.
Invariant
Cause
Observed symptom
Closure too early
Work needs the same Add a trusted reauthorizaboundary after a trusted tion event or split the close. episode. Adjacent legitimate files re- Broaden the declared main denied. boundary, not the whole task. Planner cannot ask for the Add a requestable selector needed boundary. with typed resource/effect bounds. Same policy succeeds un- Treat as planner variance, der a rerun or alternate not a broader authority model. grant.
Artifact evidence
Execution tools consume han- Interface snapshot and free-path bypass traces. dles, not ambient paths. Grant IDs and epochs are task- Stale replay, cross-scope, and phase-exit traces. local and checked at execution. Canonicalization happens be- Alias and normalized-path hardening traces. fore authority comparison. Closure is driven by trusted Test-result, orchestrator close, and authenticated observations. revoke traces. Policy perturbations change contract_sensitivity_v1. outcomes predictably.
Grant too narrow
Missing request option
Model instability
Safe recovery path
Protocol cost. The two-stage lifecycle adds one materialization turn when a grant is minted for the next interface. In the post-closure root, P ORTICO, 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.
Primary artifact roots. The compact roots are qwen3_ coder_30b_primary_r5_v1 for the main A–C campaign, qwen3_coder_30b_b10_capability_protocol_r5_v1 for the same-grant closure and same-policy diagnostics, frontier_coding_matrix_handle_fix_v1 and frontier_coding_matrix_no_portico_v1 for the supplementary API-backed frontier slice, capability_stale_effects_v1 and the modellive stale-effect root for post-closure effects, and the qwen3_real_repo_* roots for Suite D. The MCP smoke roots audit the public portico-tool interface. policy_derivation_transfer_v2 and contract_sensitivity_v1 cover contract robustness.
Mediation boundary. The protocol checks assume that runtime calls reach P ORTICO before side effects occur. The portico-tool smokes exercise the stdio interface, snapshots, authority requests, handle use, closure, and stale replay denial. 20