Las herramientas de codificación con IA tienen un problema de confianza, y un estudio a escala de Reddit acaba de cuantificarlo
Los desarrolladores están cada vez más convencidos de que las herramientas de codificación impulsadas por IA son un lastre, y ahora hay un conjunto de datos a escala de revisión por pares que lo respalda. Un nuevo estudio analizó 1,1 millones de publicaciones de Reddit para catalogar exactamente cómo los IDE nativos de LLM (LIDE) como Cursor, Claude Code, GitHub Copilot y Codex de OpenAI rompen la confianza, desde eliminar archivos silenciosamente hasta enviar código no autorizado a producción.
El estudio, titulado Impossible to hide secret …, fue escrito por Mostafijur Rahman Akhond, Md Afif Al Mamun y Gias Uddin, de la Universidad de York, junto con Song Wang, de la Universidad de Calgary. Está publicado en arXiv con el identificador 2607.26390 y fue aceptado para su presentación en ASE, la conferencia de ingeniería de software automatizada de la IEEE/ACM, más adelante este año. The Register informó sobre el trabajo el 8 de agosto.
Lo que hicieron los investigadores
El equipo examinó 1,1 millones de publicaciones en 29 subreddits dedicados a los LIDE y luego se enfocó en 446 hilos de discusión con más de seis mil comentarios que describían incidentes de seguridad o privacidad. A partir de esos informes construyeron una taxonomía de modos de falla y un resultado principal contundente: la mayoría de los problemas se originan en cómo están diseñados estos productos y en los permisos que se les otorgan, no en los modelos de lenguaje subyacentes.
Las fallas de seguridad, en cifras
Entre las publicaciones relacionadas con la seguridad, las operaciones de archivos no autorizadas dominan y representan el 43,1 por ciento de los informes. Dentro de esa categoría, la queja más común (28,3 por ciento) es que la herramienta borra carpetas o archivos del proyecto que el usuario nunca le pidió tocar; el 8,8 por ciento describe archivos modificados sin consentimiento explícito y el 5,7 por ciento reporta que la herramienta lee contenido más allá del espacio de trabajo activo.
Los problemas de seguridad operativa ocupan el segundo lugar, con un 23,9 por ciento: incidentes con consecuencias reales en producción. Los desarrolladores describieron cómo Replit eliminó una base de datos de producción de SaaS y cómo Cursor envió código a producción pese a una instrucción explícita de no hacerlo. La generación de código inseguro representa el 18,2 por ciento de los informes, incluido un caso en el que un software escrito por Cursor provocó nueve detecciones de VirusTotal, y ejemplos de cambios impulsados por alucinaciones que se colaron en la base de código. Otro 16,5 por ciento corresponde a casos en que la herramienta ignora instrucciones del usuario, listas de permitidos, puertas de permisos o archivos .ignore, y el 4,7 por ciento involucra a las integraciones de terceros.
Los casos más graves son raros, pero desproporcionados en su impacto: en un incidente, Claude Code ejecutó chmod +x en scripts sin consentimiento, un cambio de permisos de archivos reportado en apenas el 0,6 por ciento de las publicaciones, pero exactamente el tipo de acción que puede comprometer un entorno completo.
El lado de la privacidad
Las quejas de privacidad, extraídas de 194 publicaciones, siguen un patrón similar. La categoría más grande (45,9 por ciento) es la falta de transparencia: los usuarios informaron que no podían saber qué datos recopilaba una herramienta, cuánto tiempo se conservaban, a dónde se enviaban, si alimentaban ejecuciones de entrenamiento o qué podían ver los administradores. El acceso no autorizado a los datos aparece en el 23,7 por ciento, las violaciones por fuga de privacidad en el 15,5 por ciento, la recopilación o transmisión no autorizada de datos en el 11,9 por ciento y las fallas de integridad del contexto en el 8,8 por ciento; estas últimas incluyen a un usuario de Claude Desktop que recibió mensajes de chat que provenían de la sesión de otra persona.
Mecanismos de contención en lugar de garantías
Quizás el hallazgo más revelador es lo que hacen los desarrolladores en respuesta. El estudio documenta 13 estrategias de mitigación distintas, con la gestión de configuración (33 por ciento) y la gobernanza del código (31 por ciento) a la cabeza de la lista: sandboxing, revisión manual y una selección cuidadosa de lo que la herramienta puede tocar. En otras palabras, los desarrolladores tratan estos productos como software no confiable y construyen sus propias salvaguardas a su alrededor. Ese no es el patrón de adopción que los proveedores están promocionando.
Lo que deberían cambiar los fabricantes de herramientas
El artículo cierra con seis recomendaciones: controles adecuados de seguridad y privacidad; salvaguardas aplicadas a nivel de arquitectura y no como una ocurrencia posterior; una capa de verificación que evalúe el código producido por IA frente a los requisitos de seguridad y privacidad; un protocolo formal para evaluar la confiabilidad de las herramientas de terceros; protección para los archivos sensibles; y, como petición principal, seguridad estricta por defecto.
Los investigadores sostienen que más vale prevenir que curar: los mecanismos de seguridad deberían incorporarse antes de que se permita a cualquier herramienta un acceso profundo a los archivos, los datos y los sistemas de un desarrollador. Las configuraciones seguras por defecto, sostienen, son la mejora más valiosa que estas herramientas podrían hacer. Los desarrolladores no deberían enterarse, solo después de un incidente, de que una herramienta tenía más margen de acción del que suponían. Los usuarios deberían poder seguir flexibilizando las restricciones, pero la configuración segura debería ser el punto de partida, no una tarea de configuración.
El estudio llega en un momento delicado para la industria. Todos los grandes proveedores están impulsando agentes con mayor acceso al sistema y cadenas autónomas más largas, precisamente la superficie que este artículo identificó como la fuente de la mayoría de los incidentes. Si los desarrolladores ya están votando con sandboxes y puertas de revisión, la próxima generación de herramientas tendrá que recuperar esa confianza a nivel de arquitectura.
Traducido por Alessandra