Tres permisos en un portátil: los tres cerrojos que protegen a los asistentes

El año 2025 perteneció a los asistentes de inteligencia artificial, y la ola rompió con más fuerza sobre los portátiles de los programadores. Una orden en lenguaje común abre archivos, mueve registros y envía peticiones a servicios externos, mientras cada tarea hace circular peticiones hacia un modelo y devuelve trabajo terminado. La fuerza nace de ese alcance, y el miedo también: el mismo asistente mira sus archivos privados, lee textos venidos de internet y puede empujar datos hacia fuera. La anécdota del ponente golpea fuerte; un creador que elogiaba su producto con alegría escribió dos días después que el mismo asistente había borrado su base de producción. Leo ese episodio menos como un accidente y más como una advertencia de diseño.

SimonWillison describe la situación con tres permisos: el asistente alcanza datos privados, queda abierto a contenidos dudosos y puede hablar con el mundo exterior. Un solo permiso se gestiona; una herramienta que solo lee archivos o que solo sale a internet no alarma a nadie. Dos permisos juntos cambian el cuadro, y con los tres la pregunta ya no es si llegará un incidente, sino cuándo. SimonWillison muestra además lo silencioso que puede ser el robo: una cifra pedida al modelo termina codificada y escondida en una etiqueta de imagen inocente, antes de viajar hacia fuera. El robo de datos no necesita ninguna alerta parpadeante en pantalla.

La primera trampa que explota ese trío se llama inyección de órdenes. El asistente trabaja leyendo registros de errores, tiques de soporte y salidas de compilación, y un atacante puede esconder mandatos dentro de esos textos. El asistente toma la línea plantada por una misión encargada y la ejecuta. Su primo, el envenenamiento de contexto, avanza más tapado: material falso se siembra temprano en documentos, notas y conjuntos de datos, y el asistente lo toma por cierto cuando llega el día. El tercer peligro es el crecimiento silencioso de los privilegios. Cada persona recibe normalmente un acceso mínimo, pero al asistente se le abren todas las puertas para que entregue su trabajo; una sola línea engañosa le da entonces poder bastante para borrar una tabla o lanzar una petición hacia fuera.

Estos peligros viven en el ordenador de casa, no en la teoría. Las herramientas de asistencia personal nombradas en el escenario funcionan, según el consejo de instalación, en una caja pequeña separada del ordenador diario; nadie las quiere ver en el portátil principal. Un informe de Kaspersky confirma la cautela: un estudio de febrero de 2026 describe robos de claves privadas y de vales de acceso además de fallos de ejecución remota en una pila de asistencia así. Peor aún, esas herramientas exigen un amplio acceso a archivos, terminales y cuentas para marchar a plena potencia. Cuanto más se ensancha el alcance, más cada texto visto por el asistente puede volverse una orden. El consejo de la caja separada suena a seguro barato más que a paranoia.

El primer cerrojo saca al asistente del portátil hacia un espacio de trabajo remoto ya preparado. En el diseño descrito por Coder, un programador abre una dirección y el trabajo gira en una caja sellada validada por el equipo de seguridad. Esa caja solo contiene el programa instalado, las credenciales depositadas y los datos colocados; el asistente no puede extenderse hacia los archivos personales, por construcción. El informe de espacios de trabajo de Coder precisa que esas cajas nacen de recetas de infraestructura y pueden quedar en los servidores de la empresa. El beneficio lateral es grande: dependencias, versiones y rutas llegan listas, de modo que el asistente arranca al instante y nunca tiene ocasión de traer descargas dudosas desde una fuente contaminada.

En las empresas el cuadro se enreda más, porque el obstáculo es organizativo antes que técnico. Una nueva iniciativa de asistencia debe ganar primero el aval del responsable de seguridad, y luego el apoyo del equipo que mueve la operación. Cuando el aval no llega, la gente avanza igual con sus suscripciones personales. El sector llama a eso uso fantasma, y el ponente pone nombre propio a la versión en enjambre. Decenas de asistentes invisibles tocan datos antes de que nadie lo note. Una encuesta de Okta realizada en enero entre 150 responsables de tecnología y seguridad cuenta que el 81 por ciento de los jefes de seguridad teme una vigilancia escasa de los sistemas de inteligencia artificial. El temor ocupa la mayoría, no el margen.

Los responsables se inquietan con razón, porque la responsabilidad por los actos del asistente cae sobre ellos. Los equipos plantean tres preguntas: qué hacen exactamente estos asistentes, puedo ver cada petición al modelo en una sola pantalla, y quién me avisa cuando algo se tuerce. Incluso con las pantallas de observación colocadas, llega el cansancio de las alertas; cuando cada pequeño suceso dispara un aviso, la amenaza real se ahoga en el ruido. Los despliegues también deben quedar idénticos, repetibles y fiables para todos. OWASP traza el marco general de esas expectativas: su lista 2026 de aplicaciones con asistentes, armada con más de un centenar de especialistas, enumera una por una rúbricas como la ejecución remota sorpresa. Las empresas ya se defienden con la lista en vez de a ciegas.

En otro frente pesan las dudas de los propios programadores. Algunos de los nombres con más oficio aún desconfían de lo que produce el asistente; temen productos hinchados, cargas de mantenimiento crecientes y fallos de seguridad escondidos. Unos dicen que repasar los borradores del asistente lleva más tiempo que escribir desde cero. La responsabilidad añade un nudo: cuando un asistente propone decenas de cambios en modo libre, quién responde por el que sale mal. Esas preguntas tienen peso, y la respuesta está en barandillas antes que en vetos. Aíslen al asistente y registren su tráfico, y tanto el ingeniero como el directivo respiran; la confianza nace del control.

El segundo cerrojo coloca una pasarela de inspección entre el modelo y el asistente. Normalmente el asistente envía sus peticiones directo al proveedor del modelo; en el diseño con pasarela, cada petición visita primero la pasarela de la empresa, donde cada llamada entra en un registro ligado a un nombre de usuario. La pasarela puede retirar fragmentos sensibles, como datos de tarjeta colados por descuido en una orden, antes de que alcancen al proveedor. El informe de gobernanza de Coder explica que la pasarela autentica cada petición, guarda las claves del proveedor dentro del plano de control y mantiene los accesos tras una lista cerrada. Qué asistente pidió qué a qué modelo, y cuántos vales quemó, se reúne en un solo libro; la factura y la auditoría pasan por la misma puerta.

El tercer cerrojo es un cortafuegos que retiene las órdenes que lanza el asistente. Incluso en una caja sellada, el asistente puede intentar una orden dañina; los borrados de repositorios o las caídas de tablas chocan con ese muro y nunca se ejecutan. El muro vigila los registros de procesos, bloquea los dominios y las órdenes no aprobadas, y escribe cada bloqueo en archivos centrales. Leídos juntos, los tres cerrojos aclaran el cuadro: uno estrecha el acceso a los datos, otro gestiona la palabra hacia fuera, el último aprieta los privilegios. La frase de cierre de la charla apunta en la misma dirección; avanzar despacio, pensar la arquitectura y aprender lo que la infraestructura quiere de verdad no tiene nada de vergonzoso. Mi única línea añadida: estos tres cerrojos no son un lujo sino la lista mínima de todo equipo que mueva asistentes.