Een agent harness van een leverancier adopteren met de gevaarlijke standaardinstellingen afgedwongen uit

Beslisrecords, negen van tien. Een architectuurbeslissing per stuk, uit een beheerst AI-agentplatform dat ik als prototype ontwierp en bouwde voor de Nederlandse lokale overheid.

De situatie

De agent harness van een leverancier, de runtime-lus die een model, een toolset en een sessie neemt en er een agent van maakt, was voor het platform geweigerd zolang hij prerelease was. Redelijk: het platform neemt geen afhankelijkheden op dingen die van de ene op de andere dag van vorm kunnen veranderen. Toen bereikte hij een stabiele release, en de weigering verviel op haar eigen voorwaarden.

De argumenten voor adoptie waren sterk. De rebuild-lus, sessieafhandeling en human-in-the-loop-plumbing zelf bouwen en onderhouden is maanden werk dat niets onderscheidends oplevert.

De argumenten tegen waren specifiek. Vier capabilities staan standaard aan, en elk breekt een regel die het platform al afdwingt. Hosted web search: onbeheerste egress, het model dat het internet bereikt buiten de control op retrieval-routing om. Bestandstoegang: niet-gesandboxte lees- en schrijfacties op de host, buiten isolatie. Bestandsgebaseerd geheugen: de harness die dingen onthoudt in bestanden die de kernel niet ziet, en zo het promotion path voor geheugen omzeilt. En heuristische auto-goedkeuring van tools: de harness die zelf besluit dat een tool call veilig genoeg oogt om niet te hoeven vragen, wat een modelnabije component is die een actie goedkeurt.

Een van die vier aan, en de garanties van het platform zijn onwaar.

De beslissing

Adopteer de harness. Dwing alle vier de capabilities uit af, op twee punten, beide fail-closed.

Het eerste punt is de agent host. Wanneer die een harness start, controleert hij de capability-toestand. Als een van de vier aanstaat, of de toestand niet kan worden vastgesteld, weigert de host te starten. Geen waarschuwing, een weigering.

Het tweede punt is toelating. Elk pakket dat declareert de harness te gebruiken, moet ook de toestand van de vier capabilities declareren. Een pakket dat de harness gebruikt en niet declareert, wordt geweigerd. Een ontbrekende declaratie wordt behandeld als een fout, niet als een standaardwaarde.

De check is uitgedrukt als capability-toestand, niet als ruwe configuratievlaggen. De vraag die de poort stelt is “staat hosted web search uit”, niet “staat vlag X op false”. Dat is belangrijk omdat de leverancier vlaggen kan hernoemen, hun polariteit kan omkeren of ze tussen versies kan verplaatsen, en een poort die tegen vlagnamen is geschreven zou stilletjes ophouden het juiste te controleren. Er is een test dat de polariteit van de poort niet kan worden omgekeerd: een fixture met de capability aan moet worden geweigerd, en een fixture met de capability uit moet slagen, in elke versie die het platform vastpint.

De wet van Hofstadter zegt dat alles langer duurt dan je verwacht, ook als je rekening houdt met de wet van Hofstadter. De beveiligingsversie: elke standaard staat aan, ook de standaarden die je je herinnert te hebben uitgezet, na de upgrade.

Wat ik afwees, en waarom

Permanente weigering. De lus, het sessiemodel en de human-in-the-loop-plumbing zelf blijven bouwen. Ik had daar genoeg van gedaan om de kosten te kennen, en het leverde geen enkele governance-eigenschap op die de capability-poort niet goedkoper leverde.

Uitstellen. Later adopteren, als de standaardinstellingen veranderen of het platform volwassener is. De standaardinstellingen gingen niet in het voordeel van het platform veranderen, en uitstel betekent dat de volgende persoon die een harness nodig heeft er een kiest zonder de poort.

Vertrouwen op configuratiediscipline. De vier uitzetten in de deployment-config en erop vertrouwen dat niemand ze weer aanzet. Een veiligheidseigenschap mag niet afhangen van iemand die eraan denkt. En leveranciersupgrades veranderen standaardinstellingen stilletjes; een minor-versiebump kan een capability weer aanzetten in een config die vorige week correct was. De poort moet bij elke start, bij elke toelating opnieuw controleren.

Wat het kost

De poort moet “bekend en uit” vaststellen, niet “niet aan gezien”. Dat is een strengere check en het betekent dat de poort het capability-model van de harness goed genoeg moet begrijpen om het positief te bevragen. Elke nieuwe versie-pin vereist opnieuw verifiëren dat de bevraging nog betekent wat ze betekende.

Een declaratieplicht voor pakketauteurs, wat papierwerk is, en papierwerk wekt wrevel. Hier is de anekdote. Op de dag dat ik de toelatingsregel opstelde, schreef ik hem zo dat elk pakket de capability-toestand van de harness moest declareren. Dat was te breed: een pakket zonder enige agent erin, een pure toolserver, werd nu geweigerd omdat het iets niet declareerde wat het onmogelijk kon hebben. Dezelfde dag gecorrigeerd, naar pakketten die harness-gebruik declareren. Het is een kleine fout en ik noem hem omdat dit precies het soort regel is dat te breed wordt geschreven, en het symptoom is geen beveiligingsgat maar een muur van weigeringen die mensen leert om de poort heen te werken.

Wat het niet doet

Het beheerst niet wat de harness doet met de capabilities die aan blijven. De rebuild-lus, het sessiemodel en de tool-call-plumbing zijn leverancierscode die binnen de isolatiegrens van het platform draait, en de poort zegt daar niets over. Ze worden gedekt, voor zover ze gedekt worden, door de vaste set kernel-controls.

De check aan de hostkant is gebouwd. De check aan de toelatingskant is gespecificeerd en deels gebouwd. De polariteitstest bestaat alleen voor de vastgepinde versie.

Als je een ding meeneemt

Maak een lijst van de capabilities waarmee je agent-runtime standaard aan wordt geleverd. Zeg voor elk ervan welke van je regels hij zou breken als hij aanstond. Controleer dan of iets anders dan een configbestand hem uit houdt.

De polariteit omkeren loste de meeste problemen op in Doctor Who. Een test dat de polariteit van vier vlaggen nooit omgekeerd kan worden, lost een stiller probleem op.

Verwijzingen

De knipogen en citaten in dit stuk, met hun herkomst:

• Douglas Hofstadter, Gödel, Escher, Bach (1979): Hofstadter’s law.
• Doctor Who, the Third Doctor era (1970s): “reverse the polarity”, the recurring fix.