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

Nel mondo moderno della creazione di software, è emerso un nuovo tipo di assistente: l'agente di codifica. Si tratta di programmi di intelligenza artificiale in grado di scrivere codice, correggere bug e gestire file proprio come farebbe uno sviluppatore umano. Per mantenere questi assistenti digitali sicuri e sulla giusta strada, gli sviluppatori scrivono dei file di istruzioni. Pensate a questi file come a un insieme di regole scritte, come una ricetta o un codice di condotta, dove un essere umano dice all'agente cosa è autorizzato a fare e cosa non deve mai fare. Uno sviluppatore potrebbe scrivere: "Non salvare mai le password in testo in chiaro" o "Chiedi prima di eliminare dati importanti". Per anni, questo metodo di fornire istruzioni è stato lo standard per guidare questi strumenti intelligenti. L'assunto è stato che, se si scrive una regola chiaramente, l'agente la comprenderà e la seguirà, creando un ambiente sicuro per il software in fase di costruzione.

Tuttavia, uno studio recente condotto dalla ricercatrice Ting Yan rivela una lacuna silenziosa ma significativa in questo sistema. La ricerca si concentra su un tipo specifico di file di istruzioni utilizzato con un popolare agente di codifica chiamato Claude Code. Lo studio pone una domanda semplice ma critica: quando uno sviluppatore scrive una regola di sicurezza in linguaggio naturale, il software ha effettivamente un meccanismo integrato per far rispettare quella regola, o la regola è solo un suggerimento che l'intelligenza artificiale deve cercare di interpretare? I risultati suggeriscono che, per la stragrande maggioranza di queste regole scritte, la risposta è la seconda. Il file agisce come una strada a senso unico dove lo sviluppatore parla, ma il sistema non conferma mai se la regola venga effettivamente applicata. Ciò crea un falso senso di sicurezza, in cui uno sviluppatore crede che un'azione pericolosa sia bloccata, quando in realtà il sistema si affida solo all'intelligenza artificiale affinché ricordi e obbedisca all'istruzione, senza che ci sia un vero blocco operativo in atto.

Per comprendere l'entità di questo problema, i ricercatori hanno raccolto quasi cinquecento file di istruzioni pubblici da sviluppatori di tutto il mondo. Hanno trattato questi file come una collezione di note scritte a mano, scansionandoli riga per riga per trovare frasi che sembrassero regole di sicurezza. Cercavano espressioni come "non deve", "mai" o "non fare", che segnalano una restrizione. Da questi file, hanno estratto migliaia di regole candidate. Il passo successivo è stato quello di agire come traduttori tra il linguaggio umano della regola e il linguaggio tecnico del software. Si sono chiesti se il particolare agente di codifica, Claude Code, avesse già un interruttore o un'impostazione integrata che potesse bloccare automaticamente l'azione descritta nella regola. Ad esempio, se una regola diceva "non eseguire questo specifico comando", i ricercatori hanno verificato se il software avesse un'impostazione di permessi che potesse semplicemente negare quel comando prima ancora che accadesse. Se il software non possedeva un tale interruttore, la regola veniva lasciata all'interpretazione dell'intelligenza artificiale, il che significava che l'agente avrebbe dovuto decidere autonomamente se seguire l'istruzione.

I risultati di questo confronto sono stati netti. Quando i ricercatori hanno applicato uno standard rigoroso — richiedendo che il controllo integrato coprisse l'azione esatta, il bersaglio esatto e la condizione esatta della regola scritta — solo una minima frazione delle regole aveva un meccanismo di sicurezza corrispondente. Nello specifico, hanno scoperto che solo circa il quattro o sei per cento delle regole di sicurezza scritte dagli sviluppatori era supportato da un controllo integrato in grado di applicarle senza alcun lavoro aggiuntivo. Anche utilizzando uno standard più permissivo, che consentiva corrispondenze parziali, il numero saliva solo a circa il sedici per cento. Ciò significa che per circa il novantacinque per cento delle regole di sicurezza scritte in questi file, non esisteva alcuna rete di sicurezza automatica. La regola esisteva solo come testo, affidandosi interamente all'intelligenza artificiale affinché la interpretasse correttamente ogni singola volta.

Lo studio ha anche esaminato il motivo per cui così tante regole mancavano di una corrispondenza. I ricercatori hanno scoperto che le regole spesso chiedevano cose che gli strumenti integrati del software semplicemente non potevano vedere o fare. Una regola potrebbe dire: "Non inserire segreti nel codice", ma le impostazioni dei permessi del software possono bloccare un percorso di file o un comando, non il contenuto effettivo all'interno di un file. Per far rispettare una regola sui segreti, il software dovrebbe leggere il file e capire cosa c'è dentro, un compito che non può svolgere con le sue impostazioni standard. Allo stesso modo, una regola potrebbe richiedere la verifica dello stato di un sistema o l'approvazione di una persona specifica, dettagli che i controlli integrati non potevano accedere. In questi casi, la regola non era un comando che il software poteva eseguire; era una richiesta affinché l'intelligenza artificiale usasse il proprio giudizio. I ricercatori hanno notato che questa distinzione è invisibile allo sviluppatore. Il file di istruzioni appare identico sia che una regola sia applicata da un blocco rigido del sistema, sia che sia affidata alla memoria morbida e fallibile di un'intelligenza artificiale.

Questa mancanza di feedback crea ciò che i ricercatori chiamano un canale "solo in uscita" (write-only). Nella maggior parte dello sviluppo software, quando uno sviluppatore scrive una regola, riceve un feedback immediato. Se scrive del codice che viola una regola, il computer potrebbe rifiutarsi di eseguirlo, o un test potrebbe fallire, comunicandogli immediatamente che qualcosa non va. Con questi file di istruzioni, non esiste un segnale simile. Uno sviluppatore può scrivere una regola, procedere e non sapere mai se l'agente la stia effettivamente seguendo. Lo studio evidenzia che questo è particolarmente rischioso per gli sviluppatori alle prime armi con la sicurezza. Potrebbero scrivere una regola pensando di aver messo in sicurezza il proprio sistema, senza rendersi conto che il sistema non ha modo di far rispettare effettivamente quella specifica restrizione. L'intelligenza artificiale potrebbe seguire la regola la maggior parte delle volte, ma può anche sbagliare, confondersi o essere ingannata da altri input, lasciando il sistema vulnerabile.

I ricercatori non hanno scoperto che il software fosse rotto o che gli sviluppatori stessero facendo qualcosa di sbagliato. Hanno invece identificato un difetto di progettazione nel modo in cui questi strumenti comunicano con i loro utenti. Gli strumenti permettono agli utenti di scrivere regole in linguaggio naturale, il che è facile e intuitivo, ma non dicono all'utente quali di quelle regole siano effettivamente applicate dal sistema e quali siano solo suggerimenti. Lo studio suggerisce che, affinché questi strumenti siano davvero sicuri, devono chiudere questo cerchio. Devono offrire ai developer un modo per vedere quali regole sono supportate da controlli rigidi e quali no. Idealmente, il software dovrebbe avvertire uno sviluppatore se scrive una regola che il sistema non può far rispettare, oppure dovrebbe aiutarlo a trasformare quella regola in un'impostazione che il sistema possa effettivamente utilizzare. Finché questo ciclo di feedback non verrà chiuso, la sicurezza di questi sistemi dipenderà pesantemente dalla speranza che l'intelligenza artificiale ricordi e obbedisca a ogni istruzione perfettamente, una speranza che i dati dimostrano essere spesso infondata.

Lo studio conclude sottolineando che questo è un problema risolvibile, ma richiede un cambiamento nel modo in cui questi strumenti vengono costruiti. Il divario tra ciò che uno sviluppatore scrive e ciò che il sistema applica non è un mistero; è un fatto misurabile. Misurandolo, i ricercatori hanno dimostrato che l'attuale modo di mettere in sicurezza questi agenti è incompleto. La soluzione risiede nel rendere visibile l'invisibile, assicurando che, quando uno sviluppatore scrive una regola, sappia esattamente che tipo di protezione essa fornisce. Ciò trasformerebbe il file di istruzioni da una nota a senso unico in una conversazione a due vie, dove il sistema conferma che le regole non sono solo scritte, ma sono realmente operative.