When "Do Not" Is Not Deny: Security Rules in CLAUDE.md vs Built-In Controls

In de moderne wereld van softwarecreatie is een nieuw soort helper opgekomen: de coderingsagent. Dit zijn kunstmatige intelligentieprogramma's die code kunnen schrijven, bugs kunnen oplossen en bestanden kunnen beheren, net zoals een menselijke ontwikkelaar dat zou doen. Om deze digitale assistenten veilig en op het juiste pad te houden, schrijven ontwikkelaars instructiebestanden voor hen. Beschouw deze bestanden als een reeks geschreven regels, zoals een recept of een gedragscode, waarbij een mens de agent vertelt wat hij wel en niet mag doen. Een ontwikkelaar zou kunnen schrijven: "Sla nooit wachtwoorden op in platte tekst," of "Vraag toestemming voordat belangrijke gegevens worden verwijderd." Jarenlang was deze methode van instructies geven de standaardmanier om deze intelligente tools te sturen. De aanname was dat als je een regel duidelijk opschrijft, de agent deze zal begrijpen en opvolgen, wat een veilige omgeving creëert voor de gebouwde software.

Echter, een recent onderzoek door onderzoeker Ting Yan onthult een stille maar significante kloof in dit systeem. Het onderzoek richt zich op een specifiek type instructiebestand dat wordt gebruikt bij een populaire coderingsagent genaamd Claude Code. De studie stelt een eenvoudige maar cruciale vraag: wanneer een ontwikkelaar een beveiligingsregel in gewone Engelse taal schrijft, heeft de software dan daadwerkelijk een ingebouwd mechanisme om die regel af te dwingen, of is de regel slechts een suggestie waarbij de kunstmatige intelligentie moet raden hoe deze moet worden opgevolgd? De bevindingen suggereren dat voor de overgrote meerderheid van deze geschreven regels het antwoord het laatste is. Het bestand fungeert als eenrichtingsverkeer waar de ontwikkelaar spreekt, maar het systeem nooit bevestigt of de regel wordt gehandhaafd. Dit creëert een vals gevoel van veiligheid, waarbij een ontwikkelaar gelooft dat een gevaarlijke actie wordt geblokkeerd, terwijl het systeem in werkelijkheid alleen vertrouwt op de kunstmatige intelligentie om de instructie te onthouden en op te volgen zonder dat er een harde stop aanwezig is.

Om de omvang van dit probleem te begrijpen, verzamelden de onderzoekers bijna vijfhonderd publieke instructiebestanden van ontwikkelaars over de hele wereld. Ze behandelden deze bestanden als een collectie handgeschreven aantekeningen en scanden ze regel voor regel om zinnen te vinden die klonken als beveiligingsregels. Ze zochten naar zinnen als "mag niet", "nooit" of "doe niet", die een beperking signaleren. Uit deze bestanden haalden ze duizenden kandidaat-regels. De volgende stap was om als een vertaler te fungeren tussen de menselijke taal van de regel en de technische taal van de software. Ze vroegen zich af of de specifieke coderingsagent, Claude Code, al een ingebouwde schakelaar of instelling had die de beschreven actie automatisch kon blokkeren. Bijvoorbeeld, als een regel zei "voer dit specifieke commando niet uit", controleerden de onderzoekers of de software een machtigingsinstelling had die dat commando simpelweg kon weigeren voordat het überhaupt plaatsvond. Als de software geen dergelijke schakelaar had, werd de regel aan de kunstmatige intelligentie gelaten om te interpreteren, wat betekende dat de agent zelf moest beslissen of hij de instructie zou opvolgen.

De resultaten van deze vergelijking waren schokkend. Wanneer de onderzoekers een strikte standaard toepasten — waarbij vereist werd dat de ingebouwde controle exact de actie, het exacte doel en de exacte voorwaarde van de geschreven regel moest dekken — bleek slechts een fractie van de regels een overeenkomstige beveiligingsmechanisme te hebben. Specifiek vonden zij dat slechts ongeveer vier tot zes procent van de beveiligingsregels die ontwikkelaars schreven, werd ondersteund door een ingebouwde controle die deze zonder extra werk kon afdwingen. Zelfs toen ze een lossere standaard gebruikten, waarbij gedeeltelijke overeenkomsten werden toegestaan, steeg het aantal naar slechts ongeveer zestien procent. Dit betekent dat voor ongeveer vijfentallen procent van de beveiligingsregels in deze bestanden geen automatisch vangnet bestond. De regel bestond alleen als tekst en vertrouwde volledig op de kunstmatige intelligentie om het elke keer correct te interpreteren.

De studie onderzocht ook waarom zoveel regels geen match hadden. De onderzoekers ontdekten dat de regels vaak zaken vroegen die de ingebouwde tools van de software simpelweg niet konden zien of doen. Een regel zou kunnen zeggen: "Commit nooit geheimen naar de code," maar de machtigingsinstellingen van de software kunnen een bestandspad of een commando blokkeren, niet de werkelijke inhoud binnen een bestand. Om een regel over geheimen af te dwingen, zou de software het bestand moeten lezen en begrijpen wat erin staat, wat een taak is die het met zijn standaardinstellingen niet kan uitvoeren. Op dezelfde manier zou een regel kunnen vereisen dat de staat van een systeem wordt gecontroleerd of goedkeuring wordt gevraagd aan een specifieke persoon, details die de ingebouwde controles niet konden bereiken. In die gevallen was de regel geen commando dat de software kon uitvoeren; het was een verzoek aan de kunstmatige intelligentie om haar oordeel te gebruiken. De onderzoekers merkten op dat dit onderscheid onzichtbaar is voor de ontwikkelaar. Het instructiebestand ziet er hetzelfde uit, of een regel nu wordt afgedwongen door een hard systeemslot of door het zachte, feilbare geheugen van een kunstmatige intelligentie.

Dit gebrek aan feedback creëert wat de onderzoekers een "write-only" kanaal noemen. In de meeste softwareontwikkeling krijgen ontwikkelaars direct feedback wanneer ze een regel schrijven. Als ze code schrijven die een regel overtreedt, kan de computer weigeren deze uit te voeren, of een test kan falen, waardoor ze direct weten dat er iets mis is. Met deze instructiebestanden is er geen dergelijk signaal. Een ontwikkelaar kan een regel schrijven, verdergaan en nooit weten of de agent de regel daadwerkelijk volgt. De studie benadrukt dat dit bijzonder riskant is voor ontwikkelaars die nieuw zijn in beveiliging. Zij kunnen een regel schrijven in de veronderstelling dat ze hun systeem hebben beveiligd, zonder te beseffen dat het systeem geen manier heeft om die specifieke beperking daadwerkelijk af te dwingen. De kunstmatige intelligentie volgt de regel meestal wel, maar kan ook fouten maken, in de war raken of misleid worden door andere inputs, waardoor het systeem kwetsbaar wordt.

De onderzoekers vonden niet dat de software kapot was of dat de ontwikkelaars iets verkeerd deden. In plaats daarvan identificeerden zij een ontwerpfout in de manier waarop deze tools communiceren met hun gebruikers. De tools stellen gebruikers in staat om regels in natuurlijke taal te schrijven, wat gemakkelijk en intuïtief is, maar ze vertellen de gebruiker niet welke van die regels daadwerkelijk door het systeem worden afgedwongen en welke slechts suggesties zijn. De studie suggereert dat deze tools echt veilig moeten zijn door deze lus te sluiten. Ze moeten ontwikkelaars een manier bieden om te zien welke regels worden ondersteund door harde controles en welke dat niet. Ideaal gezien zou de software een waarschuwing moeten geven aan een ontwikkelaar als deze een regel schrijft die het systeem niet kan afdwingen, of het zou hen moeten helpen die regel om te zetten in een instelling die het systeem daadwerkelijk kan gebruiken. Totdat deze feedbacklus gesloten is, zal de beveiliging van deze systemen sterk afhangen van de hoop dat de kunstmatige intelligentie elke instructie perfect onthoudt en opvolgt, een hoop die volgens de data vaak ongegrond is.

De studie concludeert door te benadrukken dat dit een oplosbaar probleem is, maar dat het een verandering vereist in de manier waarop deze tools worden gebouwd. De kloof tussen wat een ontwikkelaar schrijft en wat het systeem afdwingt is geen mysterie; het is een meetbare feit. Door het te meten, hebben de onderzoekers aangetoond dat de huidige manier waarop deze agenten worden beveiligd incompleet is. De oplossing ligt in het zichtbaar maken van het onzichtbare, door ervoor te zorgen dat wanneer een ontwikkelaar een regel schrijft, hij precies weet welke bescherming deze biedt. Dit zou het instructiebestand transformeren van een eenrichtingsnotitie naar een tweerichtingsgesprek, waarbij het systeem bevestigt dat de regels niet alleen geschreven zijn, maar ook daadwerkelijk werken.