Contáctenos

El imperativo sin secretos: por qué los modelos de seguridad tradicionales fallan cuando los agentes de IA tocan el código

Líderes del pensamiento

El imperativo sin secretos: por qué los modelos de seguridad tradicionales fallan cuando los agentes de IA tocan el código

mm

En abril 2023, Samsung descubrió que sus ingenieros habían filtrado información confidencial a ChatGPTPero eso fue accidental. Ahora imaginen si esos repositorios de código hubieran contenido instrucciones plantadas deliberadamente, invisibles para los humanos, pero procesadas por la IA, diseñadas para extraer no solo el código, sino también todas las claves de API, credenciales de base de datos y tokens de servicio a los que la IA pudiera acceder. Esto no es hipotético. Los investigadores de seguridad ya han demostrado Estos ataques de "instrucción invisible" funcionan. La pregunta no es si ocurrirá, sino cuándo.

El límite que ya no existe

Durante décadas, hemos construido la seguridad sobre una premisa fundamental: el código es código y los datos son datos. La inyección SQL nos enseñó a parametrizar consultas. Los scripts entre sitios nos enseñaron a escapar las salidas. Aprendimos a construir barreras entre lo que hacen los programas y lo que introducen los usuarios.

Con los agentes de IA, esa frontera se ha evaporado.

A diferencia del software determinista que sigue rutas predecibles, los Modelos de Lenguaje Grandes son cajas negras probabilísticas que no distinguen entre instrucciones legítimas del desarrollador y entradas maliciosas. Cuando un atacante envía una instrucción a un asistente de programación de IA, no solo proporciona datos. En esencia, reprograma la aplicación sobre la marcha. La entrada se convierte en el programa mismo.

Esto representa una ruptura fundamental con todo lo que sabemos sobre seguridad de aplicaciones. Los firewalls tradicionales basados ​​en sintaxis, que buscan patrones maliciosos como DROP TABLE o tags, fail completely against natural language attacks. Researchers have demonstrated “semantic substitution” techniques where replacing “API keys” with “apples” in prompts allows attackers to bypass filters entirely. How do you firewall intent when it’s disguised as harmless conversation?

La realidad del clic cero que nadie discute

Esto es lo que la mayoría de los equipos de seguridad no entienden: la inyección de prompts no requiere que el usuario escriba nada. Suelen ser exploits sin necesidad de hacer clic. Un agente de IA que simplemente escanea un repositorio de código para una tarea rutinaria, revisa una solicitud de extracción o lee la documentación de la API puede desencadenar un ataque sin interacción humana.

Consideremos este escenario, basado en Técnicas que los investigadores ya han demostradoUn actor malicioso incrusta instrucciones invisibles en comentarios HTML dentro de la documentación de una popular biblioteca de código abierto. Cualquier asistente de IA que analice este código, ya sea GitHub Copilot, Amazon CodeWhisperer o cualquier asistente de programación empresarial, se convierte en un potencial recolector de credenciales. Una biblioteca comprometida podría significar miles de entornos de desarrollo expuestos.

El peligro no reside en el LLM en sí, sino en la capacidad de decisión que le otorgamos. En el momento en que integramos estos modelos con herramientas y API, permitiéndoles obtener datos, ejecutar código y acceder a secretos, transformamos a estos útiles asistentes en vectores de ataque perfectos. El riesgo no aumenta con la inteligencia del modelo, sino con su conectividad.

Por qué el enfoque actual está condenado al fracaso

La industria está actualmente obsesionada con alinear modelos y construir mejores cortafuegos rápidos. OpenAI añade más barreras de seguridad. Anthropic se centra en la IA constitucional. Todos intentan crear modelos infalibles.

Esta es una batalla perdida.

Si una IA es lo suficientemente inteligente como para ser útil, es lo suficientemente inteligente como para ser engañada. Caemos en lo que yo llamo la "trampa de la desinfección": asumir que un mejor filtrado de entrada nos salvará. Pero los ataques pueden ocultarse como texto invisible en comentarios HTML, ocultarse en la documentación o codificarse de maneras que aún no hemos imaginado. No se puede desinfectar lo que no se comprende contextualmente, y el contexto es precisamente lo que hace que los LLM sean tan eficaces.

La industria debe aceptar una dura realidad: la inyección rápida tendrá éxito. La pregunta es qué ocurrirá cuando así sea.

El cambio arquitectónico que necesitamos

Actualmente nos encontramos en una fase de parcheo, añadiendo filtros de entrada y reglas de validación con urgencia. Pero así como finalmente aprendimos que prevenir la inyección SQL requería consultas parametrizadas, no un mejor escape de cadenas, necesitamos una solución arquitectónica para la seguridad de la IA.

La respuesta está en un principio que parece simple pero que requiere repensar cómo construimos sistemas: los agentes de IA nunca deberían poseer los secretos que utilizan.

No se trata de una mejor gestión de credenciales ni de soluciones de bóveda optimizadas. Se trata de reconocer a los agentes de IA como identidades únicas y verificables, en lugar de usuarios que necesitan contraseñas. Cuando un agente de IA necesita acceder a un recurso protegido, debe:

  1. Autenticar utilizando su identidad verificable (no un secreto almacenado)

  2. Reciba credenciales justo a tiempo válidas solo para esa tarea específica

  3. Haga que esas credenciales caduquen automáticamente en cuestión de segundos o minutos

  4. Nunca guardes ni “veas” secretos que perduran por mucho tiempo

Están surgiendo varios enfoques. Roles de AWS IAM para cuentas de servicio, Identidad de carga de trabajo de Google, Los secretos dinámicos de HashiCorp VaultY soluciones específicas como el Aprovisionamiento de Confianza Cero de Akeyless apuntan a este futuro sin secretos. Los detalles de implementación varían, pero el principio se mantiene: si la IA no tiene secretos que robar, la inyección inmediata se convierte en una amenaza significativamente menor.

El entorno de desarrollo de 2027

Dentro de tres años, el archivo .env estará obsoleto en el desarrollo mejorado con IA. Las claves API de larga duración, almacenadas en variables de entorno, se verán como ahora vemos las contraseñas en texto plano: una vergonzosa reliquia de una época más ingenua.

En cambio, cada agente de IA operará bajo una estricta separación de privilegios. Acceso de solo lectura por defecto. Listas blancas de acciones como estándar. Entornos de ejecución aislados como requisito de cumplimiento. Dejaremos de intentar controlar lo que piensa la IA y nos centraremos por completo en controlar lo que puede hacer.

Esto no es solo una evolución técnica; es un cambio fundamental en los modelos de confianza. Estamos pasando de "confiar, pero verificar" a "nunca confiar, verificar siempre y asumir el riesgo". El principio del mínimo privilegio, predicado desde hace mucho tiempo pero rara vez practicado, se vuelve innegociable cuando tu desarrollador junior es una IA que procesa miles de entradas potencialmente maliciosas a diario.

La elección que enfrentamos

La integración de la IA en el desarrollo de software es inevitable y en gran medida beneficiosa. GitHub informa que los desarrolladores que utilizan Copilot completan tareas un 55% más rápidoLas ganancias de productividad son reales y ninguna organización que quiera seguir siendo competitiva puede ignorarlas.

Pero nos encontramos en una encrucijada. Podemos continuar por el camino actual añadiendo más barreras de seguridad, construyendo mejores filtros y con la esperanza de crear agentes de IA infalibles. O podemos reconocer la naturaleza fundamental de la amenaza y reconstruir nuestra arquitectura de seguridad en consecuencia.

El incidente de Samsung fue una advertencia. La próxima brecha no será accidental ni se limitará a una sola empresa. A medida que los agentes de IA adquieren más capacidades y acceden a más sistemas, el impacto potencial crece exponencialmente.

La pregunta para todo CISO, todo líder de ingeniería y todo desarrollador es simple: cuando la inyección rápida tenga éxito en su entorno (y lo tendrá), ¿qué encontrará el atacante? ¿Descubrirá un tesoro de credenciales de larga duración o encontrará un agente de IA que, a pesar de estar comprometido, no tiene secretos que robar?

La decisión que tomemos ahora determinará si la IA se convierte en el mayor acelerador del desarrollo de software o en la mayor vulnerabilidad que hayamos creado. La tecnología para construir sistemas de IA seguros y sin secretos ya existe. La pregunta es si la implementaremos antes de que los atacantes nos obliguen a hacerlo.

OWASP ya ha identificado la inyección inmediata como el riesgo número uno en su Top 10 para aplicaciones de LLM. El NIST está desarrollando una guía sobre arquitecturas de confianza cero. Los marcos de trabajo existen. La única pregunta es la velocidad de implementación frente a la evolución de los ataques.

Biografía: Refael Angel es el cofundador y director de tecnología de Sin llave, donde desarrolló la tecnología de cifrado Zero-Trust patentada por la compañía. Ingeniero de software experimentado con amplia experiencia en criptografía y seguridad en la nube, Refael trabajó anteriormente como ingeniero de software sénior en el centro de I+D de Intuit en Israel, donde desarrolló sistemas para la gestión de claves de cifrado en entornos de nube pública y diseñó servicios de autenticación de máquinas. Obtuvo su licenciatura en Ciencias de la Computación a los 19 años en el Jerusalem College of Technology.

Refael Angel es el cofundador y director de tecnología de Sin llave, donde desarrolló la tecnología de cifrado Zero-Trust patentada por la compañía. Ingeniero de software experimentado con amplia experiencia en criptografía y seguridad en la nube, Refael trabajó anteriormente como ingeniero de software sénior en el centro de I+D de Intuit en Israel, donde desarrolló sistemas para la gestión de claves de cifrado en entornos de nube pública y diseñó servicios de autenticación de máquinas. Obtuvo su licenciatura en Ciencias de la Computación a los 19 años en el Jerusalem College of Technology.