De la inteligencia a la autoridad

La inteligencia artificial está yendo más allá de responder preguntas y generar contenido. Cada vez más, los sistemas de IA pueden interpretar instrucciones, formular planes, seleccionar herramientas y ejecutar tareas sin dirección humana continua.

Esa distinción importa.

Un sistema de IA que recomienda una acción es distinto de uno que está autorizado a llevarla a cabo. La diferencia no radica necesariamente en la inteligencia ni en el grado de sofisticación. Radica en la autoridad.

Los sistemas autónomos no se limitan a los modelos de lenguaje de gran tamaño de frontera. Incluyen sistemas especializados de aprendizaje automático, robótica, vehículos autónomos, agentes de software y combinaciones de tecnologías que toman decisiones o realizan acciones de forma independiente dentro de condiciones operativas definidas.

Sus posibles beneficios son considerables. Pueden contribuir al descubrimiento científico, las operaciones industriales, la atención sanitaria, el desarrollo de software y la ciberseguridad. También pueden producir resultados no deseados, exponer información confidencial o iniciar acciones que excedan lo previsto por quienes los operan.

En Desafíos de seguridad en el diseño de sistemas autónomos, Mohammad Hamad y Sebastian Steinhorst examinan los desafíos de seguridad relacionados con la respuesta autónoma a incidentes, la evaluación de riesgos, el control de acceso, la confiabilidad de los datos y las interacciones entre sistemas autónomos. Su investigación, que en gran medida se ocupa de sistemas ciberfísicos, muestra que los desafíos de proteger las acciones independientes de las máquinas van más allá de los agentes de LLM actuales.

Las consecuencias más amplias de la autonomía merecen un examen serio, incluidos los posibles daños físicos. Sin embargo, las pruebas deben interpretarse con cuidado. Por ejemplo, no se puede atribuir automáticamente a los mismos mecanismos que afectan a los agentes autónomos de ciberseguridad los incidentes relacionados con vehículos automatizados. Importan el grado de autonomía, las condiciones de funcionamiento, la intervención humana y las pruebas de causalidad.

Del mismo modo, las pruebas de que la IA autónoma puede causar daños no demuestran que la gobernanza necesariamente se esté quedando atrás. Tampoco debemos suponer que los sistemas autónomos sean intrínsecamente difíciles de proteger.

La pregunta fundamental no es si la IA puede realizar tareas complejas, sino si los marcos arquitectónicos, de seguridad y organizativos que rigen los sistemas autónomos pueden establecer límites adecuados para la autoridad delegada y aportar pruebas verificables de que esos límites se respetan.

La ciberseguridad ofrece una perspectiva especialmente útil sobre esta cuestión, porque los profesionales de la seguridad llevan décadas cuestionando los supuestos sobre la confianza, los permisos, el acceso y el comportamiento de los sistemas.

El juego del gato y el ratón a la velocidad de las máquinas

Desde hace mucho tiempo, la ciberseguridad se describe como un juego del gato y el ratón.

Los atacantes descubren vulnerabilidades, los defensores incorporan medidas de protección y ambos se adaptan. El ciclo continúa a medida que cambian las tecnologías, las tácticas y los entornos operativos.

La IA autónoma no cambia necesariamente las reglas fundamentales de ese juego. Puede cambiar quién —o qué— participa, con qué rapidez actúa y cuánto trabajo puede realizarse sin intervención humana continua.

Un sistema autónomo de seguridad ofensiva podría identificar servicios expuestos, investigar vulnerabilidades, desarrollar posibles vías de ataque y comprobar si son explotables. Un sistema defensivo podría emplear capacidades similares para investigar amenazas, identificar vulnerabilidades y validar su corrección.

Este potencial de doble uso es fundamental para comprender las implicaciones de seguridad de la IA autónoma.

Project Glasswing de Anthropic es un ejemplo del descubrimiento de vulnerabilidades asistido por IA. En su actualización de investigación de mayo de 2026, Anthropic informó de resultados considerables en el descubrimiento de vulnerabilidades y, al mismo tiempo, destacó los desafíos operativos de verificarlas, divulgarlas y corregirlas.

Esa distinción importa. Descubrir una vulnerabilidad no es lo mismo que confirmar que se puede explotar, corregirla o demostrar que el sistema afectado es seguro.

Un mayor número de hallazgos puede mejorar la visibilidad y, a la vez, aumentar las exigencias para las personas y los procesos responsables de resolverlos.

El resultado en materia de seguridad depende de lo que ocurra después.

Si los atacantes y los defensores pueden automatizar partes de su trabajo, la pregunta pertinente no es simplemente qué bando dispone del modelo más capaz. Se trata de determinar si los defensores pueden convertir los descubrimientos en correcciones eficaces y verificar los resultados de forma independiente.

Las pruebas de penetración tradicionales no quedan obsoletas porque la IA pueda realizar tareas ofensivas. Su alcance debe ampliarse para incluir sistemas que interpretan instrucciones, utilizan herramientas, combinan permisos y persiguen objetivos a lo largo de varios pasos.

El objetivo sigue siendo conocido: encontrar vulnerabilidades, determinar su importancia, corregirlas y demostrar que las medidas de protección funcionan.

Costuras arquitectónicas: donde se encuentran los límites de seguridad

Uno de los riesgos más sutiles de los sistemas autónomos surge cuando componentes autorizados por separado interactúan de formas que producen resultados imprevistos.

Llamo a estos puntos de interacción «costuras arquitectónicas».

Veamos un ejemplo convencional. Una organización restringe el acceso a un archivo mediante permisos NTFS. Por separado, un servicio de intercambio en la nube permite que un usuario autorizado comparta esa información con terceros.

Cada sistema puede funcionar según sus propias reglas. Sin embargo, la interacción entre ambos puede dar lugar a un intercambio de información que traspase los límites de seguridad que la organización pretendía establecer.

Se trata de un ejemplo de políticas potencialmente contrapuestas, no de una afirmación de que algún producto para compartir archivos sea vulnerable.

Es posible que el problema no sea un defecto de cada control por separado, sino una falla al aplicar la política de seguridad prevista a lo largo de todo el flujo de trabajo.

La IA autónoma puede encontrarse con situaciones similares al conectar modelos, aplicaciones, identidades, herramientas, repositorios y servicios externos.

Un agente puede tener permiso para leer un documento, crear un repositorio y cargar archivos. Eso no significa necesariamente que esté autorizado a combinar esas operaciones de una manera que exponga información confidencial.

La investigación ofrece una razón práctica para examinar estas interacciones.

En AgentDojo, los investigadores evaluaron ataques de inyección de instrucciones contra agentes de IA que utilizan herramientas, en 97 tareas realistas y 629 casos de prueba de seguridad. Sus hallazgos demostraron que las instrucciones maliciosas introducidas mediante resultados de herramientas no confiables podían comprometer algunas propiedades de seguridad, aunque ni los ataques ni los agentes tuvieron éxito de manera uniforme.

La investigación no establece con qué frecuencia tienen éxito estos ataques en entornos de producción. Sí demuestra por qué evaluar únicamente las respuestas del modelo no basta para comprender el comportamiento de un sistema conectado a herramientas.

Un riesgo relacionado se describe a veces como blanqueo de permisos: una acción parece legítima porque se ejecuta a través de una herramienta o un intermediario autorizado, aunque el comportamiento combinado traspase los límites de autoridad previstos.

A medida que colaboran varios agentes, estas relaciones requieren reglas explícitas que rijan la participación, el intercambio de información y las acciones permitidas.

También es necesario asignar responsabilidades en toda la arquitectura.

Los proveedores de modelos, los operadores de plataformas, los desarrolladores de agentes y las organizaciones que los implementan pueden controlar distintas partes del sistema. Un modelo de responsabilidad compartida útil identifica quién controla cada límite, quién puede autorizar excepciones, quién supervisa la ejecución y quién responde cuando algo sale mal.

La autonomía no elimina la responsabilidad. Hace más importante saber dónde recae.

Rigor ofensivo: poner a prueba lo que creemos saber

Esto nos lleva a un concepto que denomino rigor ofensivo.

El rigor ofensivo es un enfoque disciplinado de las pruebas adversariales, la indagación crítica y la validación basada en evidencia que pone en tela de juicio los supuestos de seguridad. Evalúa cómo se comportan los sistemas en condiciones realistas, en lugar de confiar únicamente en diseños arquitectónicos, controles documentados o protecciones percibidas.

Las prácticas en las que se basa ya están consolidadas. Desde hace mucho tiempo, las pruebas de penetración, el modelado de amenazas, los ejercicios de equipo rojo y la validación de seguridad ponen a prueba los supuestos defensivos.

El rigor ofensivo articula esas prácticas en torno a una pregunta central:

¿Qué evidencia demuestra que se respetan los límites de seguridad previstos?

Una organización puede contar con políticas que restrinjan la información confidencial, un modelo configurado para rechazar solicitudes prohibidas y un agente con permisos limitados.

Son medidas de protección importantes. Sin embargo, su existencia no demuestra por sí sola que todo el sistema se comporte de forma segura ante condiciones adversariales.

Un modelo podría rechazar una instrucción maliciosa mientras una herramienta autorizada sigue permitiendo una acción no prevista. Una política podría parecer correcta, pero las interacciones entre sistemas podrían crear una vía inesperada para eludirla.

A veces llamo a esto «ilusión de las barreras de seguridad»: confundir la presencia de barreras con la prueba de que el sistema no puede traspasar el límite que estas debían hacer respetar.

Las barreras de seguridad son útiles. Aun así, es necesario demostrar su eficacia.

Consideremos un agente autónomo autorizado para investigar una posible intrusión. Puede recuperar registros, examinar la actividad de los usuarios y recomendar medidas de contención.

Durante una prueba de seguridad autorizada, un evaluador adversarial introduce instrucciones engañosas en la información que se espera que el agente procese.

La prueba no debería limitarse a determinar si el agente siguió esas instrucciones.

También debería examinar si el agente intentó realizar una acción no autorizada, si los controles independientes impidieron que se ejecutara, si quedó constancia del intento y si el sistema se recuperó adecuadamente.

El rigor ofensivo conecta cinco actividades:

1. Establecer el supuesto: identificar la propiedad de seguridad que se espera que la arquitectura garantice.
2. Poner a prueba el supuesto: probar vías de ataque realistas, entradas manipuladas y combinaciones de capacidades legítimas.
3. Recopilar pruebas: determinar qué intentó hacer el sistema, qué llegó a ejecutarse y qué controles actuaron.
4. Corregir la debilidad: abordar el modelo, el flujo de trabajo, los permisos, la arquitectura o el proceso operativo que causó el fallo.
5. Verificar la corrección: volver a probar la vía de ataque pertinente y confirmar que se garantiza la propiedad de seguridad prevista.

Esta es la diferencia entre probar la respuesta de un modelo y probar la seguridad del sistema completo.

También es necesario examinar qué sucede después de obtener un punto de apoyo inicial. Un atacante puede intentar recopilar credenciales, escalar privilegios, establecer persistencia o desplazarse lateralmente aprovechando capacidades que ya están disponibles en un entorno.

Que una herramienta sea legítima no significa que todos sus usos lo sean.

El propósito del rigor ofensivo no es dar por sentado que los sistemas autónomos son inseguros, sino determinar mediante pruebas dónde se mantienen sus límites de seguridad.

Autonomía condicional: separar la inteligencia de la autoridad

Una respuesta arquitectónica consiste en distinguir lo que un sistema de IA puede hacer de aquello que está autorizado a hacer.

Describo este enfoque como autonomía condicional.

La autonomía condicional reconoce que el grado adecuado de independencia depende de la tarea, el entorno operativo, las posibles consecuencias, la incertidumbre y las pruebas disponibles que justifiquen una acción.

Un agente que resume información pública no necesariamente requiere el mismo nivel de supervisión que otro autorizado a desactivar cuentas, modificar reglas de cortafuegos o cambiar la infraestructura de producción.

Este último quizá requiera reglas de actuación explícitas, permisos aplicados de forma independiente, una autorización más estricta y aprobación humana para las acciones con consecuencias importantes.

Estos límites no deberían ampliarse simplemente porque un agente decida que un acceso más amplio ayudaría a alcanzar su objetivo.

Un agente puede replantearse cómo realizar una tarea autorizada sin adquirir autoridad adicional.

El Top 10 de OWASP para aplicaciones de LLM aborda esta cuestión en la categoría LLM06:2025: agencia excesiva. OWASP señala que la funcionalidad, los permisos y la autonomía excesivos son fuentes de riesgo, y recomienda limitar las capacidades y aplicar la autorización de forma independiente.

La autonomía condicional aplica estos principios en función del riesgo operativo.

El acceso a la información debe limitarse a lo que requiere la tarea. Los permisos de las herramientas deben restringirse a las operaciones aprobadas. Los presupuestos de acciones, los límites de frecuencia, los requisitos de aprobación y las condiciones de detención pueden limitar la ejecución.

Estas salvaguardas son especialmente importantes en las pruebas ofensivas autónomas.

Un agente de pruebas puede descubrir legítimamente credenciales o información confidencial mientras persigue un objetivo autorizado. Sin embargo, que encuentre una credencial no significa que el modelo necesite recibirla en texto sin cifrar.

Un mecanismo de seguridad puede mantener las credenciales confidenciales aisladas del modelo y mediar en su uso mediante una autorización aplicada de forma independiente. Por ejemplo, un intermediario de credenciales podría proporcionar un secreto directamente a un servicio aprobado sin exponerlo innecesariamente al modelo.

Esto se ajusta a los principios establecidos de mínimo privilegio y separación de funciones.

También plantea una pregunta interesante sobre la arquitectura Bring Your Own Model (BYOM) o la arquitectura de LLM propio (BYO-LLM).

Si mañana se sustituye el modelo subyacente, ¿qué garantías de seguridad se mantienen intactas?

La autorización de tareas, el aislamiento de credenciales, las restricciones de alcance, el registro y la aplicación de políticas pueden residir en el mecanismo que rodea al modelo, en lugar de depender por completo de su comportamiento.

Eso no significa que dicho mecanismo sea seguro automáticamente ni que los modelos sean intercambiables. Distintos modelos pueden interpretar las instrucciones de manera diferente, invocar las herramientas de otra forma y presentar modos de fallo distintos.

Una evaluación significativa debe probar tanto los controles que se pretende que permanezcan invariantes como los comportamientos que cambian al cambiar el modelo.

Quizá algunas de las propiedades de seguridad más duraderas sean las que pueden seguir aplicándose de manera independiente mientras evoluciona el componente de inteligencia.

Cuando la IA actúa sobre la IA: el problema de la verificación

Consideremos un flujo de trabajo hipotético de operaciones de seguridad:

Investiga este incidente, recopila las pruebas, identifica las identidades afectadas, propone medidas de contención, ejecuta las acciones aprobadas y verifica el resultado.

Un agente de investigación analiza la telemetría. Otro recomienda medidas de contención. Un agente de ejecución autorizado realiza los cambios. Un agente de verificación evalúa el resultado.

Esto ilustra una respuesta autónoma a incidentes de ciclo cerrado, no un fallo documentado en toda la industria.

Supongamos que el primer agente identifica erróneamente una identidad como comprometida. Un segundo agente acepta esa conclusión y deshabilita la cuenta. Un tercero confirma que la cuenta se deshabilitó e informa que la operación se realizó correctamente.

La operación seleccionada se completó.

Pero ¿era correcta la determinación inicial? ¿Estaba autorizada la acción? ¿La contención hizo frente a la amenaza real? ¿Provocó interrupciones innecesarias?

La verificación no puede limitarse a confirmar que un agente completó la acción que había seleccionado.

Tampoco basta con asignar la verificación a otro agente de IA para que el resultado sea independiente.

Distintos agentes pueden basarse en la misma telemetría inexacta, información comprometida o suposiciones erróneas. Que estén de acuerdo no demuestra de manera independiente cuáles son los hechos subyacentes.

Cuanto más graves sean las consecuencias de una acción autónoma, mayor será la necesidad de una verificación independiente del sistema que toma la decisión.

Esa independencia puede implicar pruebas obtenidas de fuentes separadas, comprobaciones deterministas de políticas, entornos de ejecución restringidos, revisión humana o una combinación de salvaguardas.

Los controles adecuados deben ser proporcionales a las consecuencias de un error.

Las acciones reversibles y de bajo impacto pueden ser aptas para la verificación automatizada. Las acciones de gran impacto o difíciles de revertir pueden requerir una autorización más rigurosa, una confirmación independiente y la aprobación explícita de una persona.

Cuatro preguntas ayudan a distinguir las propiedades de seguridad pertinentes:

• ¿Interpretó correctamente el sistema la tarea prevista?
• ¿La acción estaba dentro de la autoridad que se le había delegado?
• ¿La ejecución se mantuvo dentro de los límites permitidos?
• ¿El resultado obtenido cumplió el objetivo de seguridad previsto?

Estas preguntas están relacionadas, pero no son intercambiables.

Un agente puede realizar una acción autorizada que produzca un resultado no deseado. También puede obtener un resultado aparentemente beneficioso mediante una acción no autorizada.

Ninguno de estos casos debe considerarse automáticamente un éxito en materia de seguridad.

A medida que los sistemas autónomos adquieren más capacidades, el desafío no consiste simplemente en permitirles completar flujos de trabajo complejos. Consiste en reunir pruebas suficientes de que sus acciones siguen estando autorizadas, son apropiadas y correctas.

Esto incluye saber cuándo detenerse, escalar el asunto, revertir una acción o aceptar un riesgo acotado y comprendido de forma explícita.

La confianza debe basarse en pruebas

Las implicaciones de la IA autónoma para la seguridad no son exclusivamente negativas.

Los sistemas autónomos pueden ayudar a los equipos de defensa a detectar debilidades, investigar amenazas y realizar tareas de validación que, de otro modo, exigirían un esfuerzo humano considerable.

Los mejores modelos, unos controles externos más sólidos y unas prácticas operativas más maduras pueden reducir algunos de los riesgos asociados a la autoridad delegada.

Por tanto, sería prematuro concluir que la IA autónoma es intrínsecamente insegura o que la gobernanza no puede seguir el ritmo de su desarrollo.

También hay un contraargumento de peso a la idea de que la IA autónoma requiere principios de seguridad fundamentalmente nuevos.

Muchos de los problemas subyacentes —privilegios excesivos, entradas que no son de confianza, autorizaciones débiles, aplicación incoherente de políticas y verificación insuficiente— llevan décadas estudiándose.

Los controles establecidos pueden ofrecer soluciones viables si se implementan y prueban correctamente.

La autonomía puede cambiar la velocidad, la escala y la complejidad de su aplicación. No los invalida automáticamente.

Las pruebas apuntan a una pregunta más útil: ¿en qué condiciones se puede confiar en que los sistemas autónomos ejerzan la autoridad delegada y cómo demostramos que se cumplen esas condiciones?

La respuesta no dependerá únicamente de las capacidades del modelo.

Requiere límites arquitectónicos, responsabilidades claramente asignadas, una autorización aplicada de forma independiente, una supervisión adecuada y pruebas de que las salvaguardas funcionan en condiciones realistas.

También requiere una visión coherente, pero en constante evolución, de la seguridad y el riesgo.

Nuestros principios fundamentales de seguridad no tienen que cambiar cada vez que aparece un nuevo modelo. Sin embargo, debemos cuestionar continuamente nuestras suposiciones sobre cómo se aplican esos principios a medida que evolucionan las capacidades, los entornos operativos y la autoridad delegada.

Este es el propósito de Offensive Rigor.

No se trata de demostrar que los sistemas de IA fallarán, sino de descubrir dónde pueden fallar, establecer las consecuencias y validar los controles destinados a prevenir esos fallos o contenerlos.

Quizá la ventaja más duradera no consista simplemente en elegir un modelo más capaz, sino en construir una arquitectura que permita cambiar de modelo sin comprometer los límites de la confianza, la autoridad y la verificación.

El juego del gato y el ratón continúa. Cada vez más, ambos bandos podrían contar con participantes autónomos.

Lo importante es garantizar que nuestra capacidad para encontrar debilidades, corregirlas y demostrar los resultados no se pierda en la carrera por automatizar todo lo demás.

La confianza debe basarse en pruebas.

Nota del autor: Las opiniones e interpretaciones expresadas en este artículo son propias y no reflejan necesariamente las posturas oficiales, las políticas ni las capacidades de los productos de mi empleador.