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

En el mundo moderno de la creación de software, ha surgido un nuevo tipo de ayudante: el agente de codificación. Estos son programas de inteligencia artificial que pueden escribir código, corregir errores y gestionar archivos tal como lo haría un desarrollador humano. Para mantener estos asistentes digitales seguros y en el camino correcto, los desarrolladores les escriben archivos de instrucciones. Piense en estos archivos como un conjunto de reglas escritas, como una receta o un código de conducta, donde un humano le dice al agente qué tiene permitido hacer y qué nunca debe hacer. Un desarrollador podría escribir: "Nunca guarde contraseñas en texto plano" o "Pregunte antes de eliminar datos importantes". Durante años, este método de dar instrucciones ha sido la forma estándar de guiar a estas herramientas inteligentes. La suposición ha sido que si se escribe una regla con claridad, el agente la entenderá y la seguirá, creando un entorno seguro para el software que se está construyendo.

Sin embargo, un estudio reciente de la investigadora Ting Yan revela una brecha silenciosa pero significativa en este sistema. La investigación se centra en un tipo específico de archivo de instrucciones utilizado con un popular agente de codificación llamado Claude Code. El estudio plantea una pregunta simple pero crítica: cuando un desarrollador escribe una regla de seguridad en inglés sencillo, ¿tiene el software realmente un mecanismo integrado para hacer cumplir esa regla, o es la regla solo una sugerencia que la inteligencia artificial tiene que adivinar cómo seguir? Los hallazgos sugieren que, para la gran mayoría de estas reglas escritas, la respuesta es esto último. El archivo actúa como una calle de un solo sentido donde el desarrollador habla, pero el sistema nunca confirma si la regla se está aplicando. Esto crea una falsa sensación de seguridad, donde un desarrollador cree que una acción peligosa está bloqueada, cuando en realidad el sistema solo depende de que la inteligencia artificial recuerde y obedezca la instrucción sin que exista un freno real en su lugar.

Para entender la escala de este problema, los investigadores recopilaron casi quinientos archivos de instrucciones públicos de desarrolladores de todo el mundo. Trataron estos archivos como una colección de notas manuscritas, escaneándolos línea por línea para encontrar oraciones que sonaran como reglas de seguridad. Buscaron frases como "no debe", "nunca" o "no haga", que señalan una restricción. De estos archivos, extrajeron miles de reglas candidatas. El siguiente paso fue actuar como un traductor entre el lenguaje humano de la regla y el lenguaje técnico del software. Se preguntaron si el agente de codificación específico, Claude Code, ya tenía un interruptor o ajuste integrado que pudiera bloquear automáticamente la acción descrita en la regla. Por ejemplo, si una regla decía "no ejecute este comando específico", los investigadores comprobaron si el software tenía un ajuste de permiso que pudiera simplemente denegar ese comando antes de que ocurriera. Si el software no tenía tal interruptor, la regla quedaba a la interpretación de la inteligencia artificial, lo que significaba que el agente tendría que decidir por sí mismo si seguía la instrucción.

Los resultados de esta comparación fueron contundentes. Cuando los investigadores aplicaron un estándar estricto —exigiendo que el control integrado cubriera la acción exacta, el objetivo exacto y la condición exacta de la regla escrita— solo una pequeña fracción de las reglas tenía un mecanismo de seguridad coincidente. Específicamente, encontraron que solo alrededor del cuatro al seis por ciento de las reglas de seguridad que los desarrolladores escribieron estaban respaldadas por un control integrado que podía aplicarlas sin trabajo adicional. Incluso cuando utilizaron un estándar más laxo, permitiendo coincidencias parciales, la cifra aumentó a solo un dieciséis por ciento. Esto significa que, para aproximadamente el noventa y cinco por ciento de las reglas de seguridad escritas en estos archivos, no había una red de seguridad automática. La regla existía solo como texto, dependiendo enteramente de que la inteligencia artificial la interpretara correctamente cada vez.

El estudio también analizó por qué tantas reglas carecían de una coincidencia. Los investigadores descubrieron que las reglas a menudo pedían cosas que las herramientas integradas del software simplemente no podían ver o hacer. Una regla podría decir: "Nunca suba secretos al código", pero los ajustes de permisos del software pueden bloquear una ruta de archivo o un comando, no el contenido real dentro de un archivo. Para aplicar una regla sobre secretos, el software necesitaría leer el archivo y comprender qué hay dentro, lo cual es una tarea que no puede realizar con sus configuraciones estándar. Del mismo modo, una regla podría requerir la comprobación del estado de un sistema o la obtención de la aprobación de una persona específica, detalles que los controles integrados no podrían acceder. En estos casos, la regla no era un comando que el software pudiera ejecutar; era una petición para que la inteligencia artificial utilizara su juicio. Los investigadores señalaron que esta distinción es invisible para el desarrollador. El archivo de instrucciones se ve igual tanto si una regla está siendo aplicada por un bloqueo duro del sistema como si lo está haciendo la memoria blanda y falible de una inteligencia artificial.

Esta falta de retroalimentación crea lo que los investigadores llaman un canal de "solo escritura". En la mayoría del desarrollo de software, cuando un desarrollador escribe una regla, recibe retroalimentación inmediata. Si escribe código que rompe una regla, la computadora podría negarse a ejecutarlo, o una prueba podría fallar, diciéndole inmediatamente que algo anda mal. Con estos archivos de instrucciones, no existe tal señal. Un desarrollador puede escribir una regla, seguir adelante y nunca saber si el agente la está siguiendo realmente. El estudio destaca que esto es particularmente riesgoso para los desarrolladores que son nuevos en seguridad. Podrían escribir una regla pensando que han asegurado su sistema, sin darse cuenta de que el sistema no tiene forma de aplicar realmente esa restricción específica. La inteligencia artificial puede seguir la regla la mayor parte del tiempo, pero también puede cometer errores, confundirse o ser engañada por otras entradas, dejando el sistema vulnerable.

Los investigadores no encontraron que el software estuviera roto o que los desarrolladores estuvieran haciendo algo mal. En cambio, identificaron un fallo de diseño en cómo estas herramientas se comunican con sus usuarios. Las herramientas permiten a los usuarios escribir reglas en lenguaje natural, lo cual es fácil e intuitivo, pero no informan al usuario cuáles de esas reglas están siendo aplicadas por el sistema y cuáles son solo sugerencias. El estudio sugiere que, para que estas herramientas sean verdaderamente seguras, necesitan cerrar este ciclo. Necesitan dar a los desarrolladores una forma de ver qué reglas están respaldadas por controles duros y cuáles no lo están. Idealmente, el software debería advertir a un desarrollador si escribe una regla que el sistema no puede aplicar, o debería ayudarle a convertir esa regla en un ajuste que el sistema pueda utilizar realmente. Hasta que este ciclo de retroalimentación se cierre, la seguridad de estos sistemas dependerá en gran medida de la esperanza de que la inteligencia artificial recuerde y obedezca cada instrucción perfectamente, una esperanza que los datos muestran que a menudo es errónea.

El estudio concluye enfatizando que este es un problema solucionable, pero requiere un cambio en la forma en que se construyen estas herramientas. La brecha entre lo que un desarrollador escribe y lo que el sistema aplica no es un misterio; es un hecho medible. Al medirlo, los investigadores han demostrado que la forma actual de asegurar estos agentes es incompleta. La solución reside en hacer visible lo invisible, asegurando que cuando un desarrollador escribe una regla, sepa exactamente qué tipo de protección proporciona. Esto transformaría el archivo de instrucciones de una nota de un solo sentido en una conversación de dos vías, donde el sistema confirma que las reglas no solo están escritas, sino que realmente están funcionando.