Technische Samenvatting: Lingering Authority in Coding Agents

Probleemdefinitie: Lingering Authority

Het artikel identificeert een specifieke beveiligingskloof in coding agents die wordt aangeduid als lingering authority (aanhoudende autoriteit). Coding agents ontvangen vaak brede toegang tot tools voor een volledige taak, zelfs wanneer een specifieke bron of effect slechts vereist is voor één subdoel. Het kernproblek is temporeel: autoriteit die gerechtvaardigd is voor één subdoel blijft blootgesteld in de interface van de planner nadat dat subdoel is afgesloten.

Hoewel bestaande verdedigingsmechanismen zich richten op kwaadaardige inhoud, tool-vertrouwen en controles tijdens de uitvoering, laten ze de planner interface zelf vaak blootgesteld aan capaciteiten die niet langer gerechtvaardigd zijn. Als een brede leesoptie zichtbaar blijft voor de planner nadat een subdoel is beëindigd, kan het model blijven plannen rondom deze optie, wat een beveiligingsstatus creëert waarin tijdelijke capaciteiten voortbestaan voorbij hun rechtvaardiging. Het artikel stelt dat de blootgestelde interface deel uitmaakt van de beveiligingsstatus, onderscheiden van runtime-bereikbaarheid of sandbox-grenzen.

Methodologie: PORTICO Reference Monitor

De auteurs introduceren PORTICO, een reference monitor die ontworpen is om bounded capability lifetimes (beperkte levensduur van capaciteiten) af te dwingen voor coding agents. PORTICO werkt onder een vast host-isolatiemodel en vertrouwt op expliciete taakcontracten en een solide, getypeerde tool-catalogus.

Kernmechanismen

PORTICO compileert een taakcontract naar vier componenten:

1. Initial Envelope ($E_0$): De set capaciteiten die worden blootgesteld aan het begin van de taak.
2. Grant Rules ($\Gamma$): Regels die definiëren hoe tijdelijke autoriteit kan worden uitgebreid via expliciete verzoeken.
3. Closure Rules ($\Lambda$): Predicaten (bijv. geslaagde test, fase-exit, voltooiing van subdoel) die de intrekking van tijdelijke autoriteit triggeren.
4. Global Deny Rules ($G$): Invarianten zoals verboden netwerkhosts of toegang tot credential-bestanden.

De Request–Grant–Invoke Lifecycle

PORTICO materialiseert uitbreidingen als opaque, epoch-bound handles (ondoorzichtige, aan een tijdperk gebonden handles).

• Request: De planner kan autoriteit aanvragen op basis van verklaarde regels, maar kan geen nieuwe autoriteit creëren.
• Grant: Indien een regel overeenkomt, genereert de monitor een handle voor de specifieke bron/het specifieke effect/de specifieke fase. Deze handle wordt toegevoegd aan de volgende planner interface.
• Invoke: Executie is alleen toegestaan als een geldige, actieve handle aanwezig is.
• Closure: Wanneer een closure-event (bijv. een betrouwbaar testresultaat) plaatsvindt, verwijdert de monitor de bijbehorende handles uit de planner interface. Latere pogingen om de verouderde handle te gebruiken, worden geweigerd voordat er side-effects optreden.

Cruciaal is dat intrekking de autoriteit uit de interface verwijdert, maar de context (bijv. bestandsnamen in de conversatie) intact laat. De planner kan de tool voor die bron niet langer selecteren zonder een nieuwe grant.

Belangrijkste Bijdragen

Het artikel levert drie primaire bijdragen:

1. Definitie van No-Stale-Use: Het definieert de vereiste dat autoriteit van een gesloten grant moet verdwijnen uit latere planner interfaces en ongeldig moet zijn op het moment van uitvoering.
2. Formalisering en Implementatie: Het formaliseert exposure minimality (blootstellingsminimalisatie), justified expansion (gerechtvaardigde uitbreiding) en authority closure (autoriteitsafsluiting) rond een request–grant–invoke protocol. Deze zijn in PORTICO geïmplementeerd met behulp van epoch-bound handles.
3. Empirische Evaluatie: Het evalueert bounded lifetimes op gecontroleerde fixtures en vastgelegde echte repositories, waarbij wordt aangetoond dat de beschikbaarheid van stale-capaciteiten na afsluiting lager is vergeleken met niet-intrekkende ontwerpen.

Experimentele Resultaten

De evaluatie gebruikt drie gecontroleerde fixture-suites (A–C) en één suite met echte repositories (D), waarbij PORTICO wordt vergeleken met baselines (Full Access, Static Allowlist, Coarse Sandbox) en specifieke comparators (Non-Revoking, All-Visible Same-Policy).

Belangrijkste Bevindingen

• Minimization (RQ1): PORTICO-varianten brengen beleidschendingen en de "blast radius" (bereikte gevoelige bronnen) terug naar 0.00 in Suite A, terwijl full access en statische allowlists significante schendingspercentages laten zien (1.00 en 0.82, respectievelijk).
• Justified Expansion (RQ2): PORTICO Core (alleen de initiële envelope) is veilig maar broos, en faalt bij veel taken die grensverlegging vereisen (0.21 succes in Suite B). PORTICO Full herstelt legitiem grenswerk, waarbij 0.87 succes wordt behaald in Suite B, terwijl het 1.00 scope compliance en 0.00 schendingen behoudt.
• Closure (RQ3): Dit is het primaire onderscheidend vermogen van het artikel. Een Non-Revoking Comparator (die dezelfde grants ontvangt op dezelfde momenten maar ze nooit verwijdert) komt met PORTICO overeen wat betreft taaksucces en beslissingen vóór de afsluiting. Echter, bij post-closure re-reads:
  • PORTICO Full: Weigert 10/10 pogingen tot hergebruik na afsluiting.
  • Non-Revoking Comparator: Staat 10/10 pogingen tot hergebruik na afsluiting toe.
  • Stale-Effect Audit: In deterministische tests met betrekking tot file writes, git mutaties en netwerk egress, voert PORTICO 0/6 verboden effecten uit, terwijl de non-revoking comparator 6/6 uitvoert.
• Interface Breadth (RQ3): Een All-Visible Same-Policy Comparator (brede interface, hetzelfde executiebeleid) komt overeen met PORTICO wat betreft uitgevoerde verboden effecten (0/20), maar genereert aanzienlijk meer blocked proposals (84 vs. 67), wat aangeeft dat een bredere interface de planningsdruk verhoogt, zelfs als de uitvoering uiteindelijk wordt geweigerd.
• Real Repositories (RQ4): Op vastgelegde echte Python-repositories (Flask, Requests, etc.) materialiseert PORTICO Full succesvol tijdelijke grants en handhaaft het de closure, waarbij scope compliance en nul schendingen worden behouden over 14 contracten.

Betekenis en Claims

Het artikel claimt dat PORTICO succesvol de "lifetime" van autoriteit isoleert als een afzonderlijke beveiligingsvariabele. De belangrijkste bevinding is dat een systeem taaksucces en scope compliance kan behouden vóór afsluiting, terwijl het nog steeds tijdelijke capaciteiten beschikbaar laat na afsluiting als intrekking niet wordt afgedwongen.

De auteurs positioneren PORTICO niet als een vervanging voor sandboxing of content-verdediging, maar als een complementaire laag die tijdelijke capaciteiten expliciet, begrensd en controleerbaar maakt. De betekenis ligt in de demonstratie dat intrekking noodzakelijk is om lingering authority te voorkomen, zelfs wanneer het executiebeleid en de grant-timing identiek zijn aan een non-revoking systeem.

Het artikel blijft bescheiden over de reikwijdte:

• Het gaat uit van een vertrouwde getypeerde tool-catalogus en gemedieerde executie; het claimt geen bescherming tegen ongemedieerde shell-commando's of sandbox-bypasses.
• Het erkent dat kwaliteit van contracten een input is voor implementatie; slechte contracten kunnen leiden tot onder-granting (blokkeren van werk) of over-granting (blootstelling van risico).
• Het merkt een utiliteitskosten op: PORTICO Full ruilt een deel van de ruwe voltooiingspercentages in voor striktere scope-controle, wat resulteert in zichtbare "veilige incompleetheid" in plaats van verborgen over-brede successen.

Uiteindelijk betoogt het werk dat voor coding agents de planner interface zelf dynamisch moet zijn, waarbij deze krimpt naarmate rechtvaardigingen verlopen, in plaats van een statisch, breed menu van toegestane tools te blijven.