Toegestane tools vs open-ended agents

Definities van tools met minimale rechten

Ik begin met het schrijven van een toolcontract dat exact aangeeft wat de agent mag doen en wat niet. Een 'leesticket'-tool moet alleen een GET-bewerking blootleggen voor een specifieke ticket-id, zonder de mogelijkheid om het ticket te muteren, bestanden toe te voegen of andere eindpunten aan te roepen. Een 'verstuur e-mail'-tool moet alleen een vooraf gedefinieerde ontvangerlijst, een vaste onderwerpregel en een lichaam accepteren dat is gesanitiseerd voor newline-injectie. Door het contract te verkleinen, wordt een enkele fout in de output van het model een begrensd evenement in plaats van een cascade.

Definieer de verbbestand

Lijst alle HTTP-methoden, databaseopdrachten of bestandsbewerkingen die de tool nodig heeft. Als de tool alleen leestoegang nodig heeft, slaat u POST, PUT, DELETE en alle administratieve opdrachten over. Ik hou een spreadsheet bij die elke toolnaam koppelt aan de toegestane werkwoorden en ik bekijk deze wanneer een nieuw eindpunt wordt toegevoegd.

Beperk argumenten

Voor elk argument specificeer ik een type, een limiet voor de lengte en een toegestane tekenset. Een ticket-id kan een UUID zijn, beperkt tot 36 tekens. Een bestandspad kan worden beperkt tot een subdirectory onder /var/agent/data en mag geen '..' of absolute paden bevatten. Ik gebruik een schemavalidatiebibliotheek die elke aanvraag die niet voldoet aan de specificaties afwijst voordat de tool wordt uitgevoerd.

Versie van het contract

Ik sla de tooldefinitie op als een JSON-bestand in de versiebeheer. Elke wijziging activeert een pull-aanvraag die een goedkeuring van een beveiligingsreviewer vereist. Dit creëert een audittrail die aangeeft wanneer het privilege-oppervlak is uitgebreid en waarom.

Om te zien hoe prompt-injectie misbruik kan maken van tools met te brede rechten, bekijk de OWASP LLM01-guidance: https://genai.owasp.org/llmrisk/llm01-prompt-injection. Het cheat sheet toont concrete voorbeelden waarin een model werd misleid om een shell-opdracht aan te roepen omdat de tool onbeperkte invoer accepteerde.

Toolnaam | Toegestane werkwoord | Argumentbeperkingen | Voorbeeld van een veilige oproep leesticket | GET | ticket_id: UUID, 36 tekens | /tickets/123e4567-e89b-12d3-a456-426614174000 verstuur e-mail | POST | aan: lijst van goedgekeurde domeinen, onderwerp: max. 78 tekens, lichaam: gesanitiseerd | {"aan":["gebruiker@example.com"],"onderwerp":"Update","lichaam":"Gelieve het bijgevoegde rapport te bekijken."} lijst_bestanden | GET | pad: moet beginnen met /var/agent/data/, geen '..' | /var/agent/data/logs/2024-09-01.txt

Bevestiging van onomkeerbare acties

Acties die de staat buiten het zandbakje van de agent veranderen - zoals het verzenden van een bericht, het verwijderen van een record of het implementeren van een build - moeten worden geblokkeerd door een aparte goedkeuringsstap die de agent niet zelf kan aanroepen. Ik behandel deze als éénrichtingsdeuren en ontwerp het beleid om een menselijke token of een tijdelijke goedkeuringsdienst te vereisen voordat het hulpmiddel wordt uitgevoerd.

Afzonderlijke goedkeuringsendpoint

Ik exposeer een interne API die een ondertekend verzoek van de agent accepteert, het verzoek logt en vervolgens wacht tot een mens op 'goedkeuren' klikt in een UI of reageert op een chatopdracht. De agent ontvangt alleen een pendende identifier; het kan de goedkeuringsendpoint niet polleren om een toekenning af te dwingen.

Tijdsgebonden tokens

Wanneer goedkeuring wordt verleend, geeft het systeem een token uit die slechts één keer geldig is en na vijf minuten verloopt. De hulpmiddelendpoint controleert de handtekening en verloop van de token voordat deze doorgaat. Als de token ontbreekt of verouderd is, retourneert het hulpmiddel een fout en wordt de poging gelogd.

Logging van de poort

Elk goedkeuringsverzoek en -beslissing wordt geschreven naar een onveranderlijke log met tijdstempels, de agentidentifier, de hulpmiddelnaam en de argumenten die werden gepresenteerd. Deze log laat me reconstructeren of een vergiftigde instructie erin slaagde de poort te omzeilen of werd gestopt bij de goedkeuringsstap.

Voor richtlijnen over het beveiligen van referentiehygiëne in geautomatiseerde pijplijnen, zie de OWASP CI/CD-beveiligingsrisico-blad: https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-06-Insufficient-Credential-Hygiene. Het versterkt het principe dat geheimen nooit op een plaats moeten worden opgeslagen waar een agent ze zonder een expliciete goedkeuringsstroom kan lezen.

Controlelogboeken als controle, niet als een nagekomen gedachte

Ik behandelt het controlelogboek als het primaire bewijs dat een beleid wordt afgedwongen. Zonder een betrouwbaar logboek zijn beweringen over het minste privilege onverifieerbare claims. Ik ontwerp de loggingslaag om alleen vanuit het perspectief van de agent te worden geschreven en opgeslagen in een systeem dat de agent niet kan wijzigen of verwijderen.

Wat te loggen

- Tijdstempel met millisecondepresisie - Agentidentificator (modelversie, implementatie-ID) - Toolnaam en de exacte werkwoord dat wordt aangeroepen - Alle argumenten die worden doorgegeven aan de tool, na validatie - Resultaatstatuscode en eventuele geretourneerde gegevenssamenvatting (grootte, niet volledige inhoud) - Bron van de aanvraag (geïnitieerd door de gebruiker, geplande trigger of beleidsengine)

Opslaggaranties

Ik schrijf elke logboekregel naar een alleen-lezen opslag zoals een write-ahead log in een cloud-opslagbucket met objectversiebeheer ingeschakeld. Het bucketbeleid weigert elke verwijder- of overschrijfoperatie vanuit het serviceaccount van de agent. Dit zorgt ervoor dat zelfs als het model wordt gecompromitteerd, de geschiedenis intact blijft.

Query's voor onderzoeken

Wanneer een incident wordt gemeld, voer ik een eenvoudige SQL-achtige query uit tegen de logindex om alle uitvoeringen van een bepaalde tool binnen een tijdsvenster te vinden. Ik vermijd complexe joins die langzaam kunnen zijn; in plaats daarvan vertrouw ik op gepartitioneerde tabellen per datum en toolnaam. De query retourneert de lijst met identificatoren die ik vervolgens voor diepere forensische analyse opvraag.

Om te begrijpen hoe invoervalidatie kan voorkomen dat kwaadwillige argumenten een tool bereiken, raadpleeg de SQL-injectiepreventie-cheat sheet: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html. Het blad toont parameterquery's en strikte typen, die de argumentvalidatiebenadering weerspiegelen die ik voor agenttools gebruik.

Wanneer open-ended toegang gerechtvaardigd is

Er zijn legitieme gevallen waarin een agent een bredere bereik nodig heeft, zoals exploratoire data-analyse of threat-hunting in een geïsoleerde omgeving. In die situaties verleen ik alleen toegang nadat ik de agent in een sandbox heb geplaatst die elke verbinding met productiedata of externe betalingssystemen blokkeert.

Sandbox-grenzen

De sandbox biedt een shell, een browser-engine en een mailbox die alleen berichten kan verzenden naar een specifiek testdomein. Het netwerkbeleid blokkeert uitgaand verkeer naar elk IP-adres dat behoort tot de interne CIDR-bereiken van het bedrijf. Egress is alleen toegestaan naar een set goedgekeurde openbare mirrors voor pakketinstallatie.

Credential-isolatie

Geen productiesecreten worden gemount in het sandbox-bestandssysteem. In plaats daarvan ontvangt de agent een tijdelijke token die kan lezen uit een openbare dataset-bucket. Als de agent probeert een bestand buiten het toegestane mountpunt te lezen, retourneert de kernel een machtigingsfout en wordt de poging gelogd.

Tijdgebonden sessies

Elke sandbox-sessie duurt maximaal twee uur. Na het time-out wordt de omgeving ontmanteld en wordt een nieuwe afbeelding gelanceerd. Dit beperkt het venster waarin een misdragende agent gegevens kan verkennen of exfiltreren.

Ik pas nog steeds least-privilege tool-definities toe binnen de sandbox; het verschil is dat de gevolgen van een fout beperkt zijn tot de wegwerpomgeving in plaats van tot productiesystemen.

Behandel gegenereerde beleidsregels als concepten

Wanneer een model of een junior-engineer een beleidsbestand produceert, beoordeel ik het net zoals ik onbetrouwde code zou beoordelen die op het punt staat te worden geïmplementeerd in een kritische service. De controlelijst omvat het verifiëren van elke regel tegen de daadwerkelijke tooldefinities, het bevestigen dat ontkenningpaden bestaan en het waarborgen dat het bestand is versiebeheerd.

Toewijzing van regel aan tool

Ik maak een spreadsheet die alle tools op één as en elke beleidsregel op de andere as vermeldt. Voor elke cel markeer ik of de regel de werking van de tool toestaat, weigert of daarover zwijgt. Elke zwijgende cel activeert een opmerking die de auteur vraagt de bedoeling te verduidelijken.

Standaardweigering-controle

Ik voer een script voor statische analyse uit dat probeert elke tool met een reeks onjuist gevormde argumenten aan te roepen. Als het script een combinatie vindt die het beleid toestaat, maar die zou moeten worden geweigerd (bijvoorbeeld een 'verwijder'-tool die een wildcard-identifier accepteert), faalt het script de build en moet het beleid worden herzien.

Versiebeheer en beoordeling

Het beleidsbestand bevindt zich in een Git-repository met branchbeveiliging die twee goedkeuringen vereist voordat het kan worden samengevoegd. Ik tag elke uitgegeven versie met een semantische nummer (bijv. v1.2.0) en voeg de corresponderende tooldefinitie-snapshot toe. Dit maakt het mogelijk om terug te keren naar een bekende goede staat als een nieuwe versie een te permissieve regel introduceert.

Ik beschouw nooit een gegenereerd beleid als definitief totdat het deze beoordelingscyclus heeft doorstaan. Een beleid dat nooit wordt onderzocht, creëert een vals gevoel van veiligheid en kan lacunes verhullen die alleen onder echte belasting verschijnen.

Wat dit niet is

Deze handleiding belooft niet dat het volgen van de stappen elke mogelijke foutmodus uitsluit. Ik beweer niet 100 % bescherming tegen prompt-injectie, credential-lekkage of logische fouten. Ik stel ook niet dat een agent nooit een kwaadaardige instructie zal missen; detectie hangt af van de kwaliteit van de logbestanden, de tijdigheid van de menselijke controle en de correctheid van de toolcontracten. Behandel de patronen als maatregelen om het risico te verkleinen, niet als een garantie voor absolute veiligheid.

Gerelateerde artikelen

- AI-agentbeleidspakketten door een NIST AI RMF-bril - Verken de volledige AI micro-SaaS-onderwerpmatrix →