Una base de referencia que prioriza la seguridad para los agentes de IA siempre activos

Cuando un agente de IA se ejecuta de forma continua, deja de comportarse como algo que se invoca de vez en cuando y comienza a comportarse como un sistema del que es responsable de operar, incluso si la mayor parte de esa operación se realiza fuera de la vista y sin atención diaria.

Un sistema de este tipo lee información que no es confiable, almacena credenciales y toma medidas sin esperar a que se revise, lo que significa que el principal riesgo rara vez es una respuesta incorrecta o un resultado extraño, sino que el agente haga exactamente lo que estaba permitido hacer en una situación que sus diseñadores no habían previsto del todo.

La mayoría de las fallas en las implementaciones de los agentes no tienen importancia de forma aislada. Un token otorgado durante la configuración permanece activo durante más tiempo del previsto. Los permisos se amplían para eliminar la fricción y nunca se revisan una vez que las cosas parecen estables. Los registros acumulan material confidencial de forma silenciosa porque el almacenamiento es económico y la revisión se retrasa. Se ejecuta un ciclo de reintentos hasta que alguien nota un aumento en los costos. Nada de esto requiere un actor hostil o una hazaña novedosa. Se deriva naturalmente de los patrones de trabajo normales y de una atención limitada.

Describiremos una línea de base que priorice la seguridad para ejecutar agentes de IA en máquinas virtuales en la nube, incluidas las máquinas virtuales de computación, sin vincular el enfoque a un marco o herramienta específicos. El objetivo no es prevenir todos los errores posibles, sino mantenerlos contenidos, visibles y recuperables cuando se produzcan.

La ubicación del alojamiento rara vez es decisiva

Los debates sobre la seguridad de los agentes suelen centrarse en dónde se ejecuta el agente, como si la elección entre una máquina local y una máquina virtual en la nube determinara si el sistema se comportará de forma segura.

En la práctica, ambos entornos tienen éxito y fracasan de la misma manera. Un sistema local puede tener un alcance estricto y estar bien mantenido, o quedar ampliamente expuesto y descuidado. Una máquina virtual en la nube puede reforzarse cuidadosamente o configurarse de manera que genere problemas discretamente. Lo que importa no es la ubicación, sino el alcance.

La cuestión práctica sigue siendo la misma en ambos casos: cuando el agente se comporta mal, de forma intencionada o no, ¿a qué puede llegar y con qué rapidez puede intervenir?

Diseñar anticipadamente para la contención

Los agentes siempre activos se benefician de que se diseñen teniendo en cuenta las fallas, no porque sean intrínsecamente poco confiables, sino porque los sistemas complejos se mueven con el tiempo de maneras que son difíciles de detectar desde adentro.

El aislamiento es el punto de partida más fiable. Darle al agente una máquina virtual dedicada evita que se asocie accidentalmente con servicios y flujos de trabajo personales no relacionados, y hace que las reconstrucciones sean económicas desde el punto de vista emocional y operativo, una característica infravalorada de los sistemas resilientes.

La ejecución del agente como usuario no root limita aún más las consecuencias de los errores. La mayoría de los flujos de trabajo útiles de los agentes no requieren privilegios elevados y, cuando el acceso raíz se convierte en una dependencia, incluso los errores más pequeños pueden convertirse en esfuerzos de recuperación prolongados.

El control de acceso debe ser intencionalmente poco emocionante. La autenticación basada en claves, la desactivación del inicio de sesión con contraseña y la autenticación multifactorial en la cuenta en la nube reducen el número de formas de acceder a un sistema cuando algo va mal. El acceso a la consola merece el mismo escrutinio que el SSH, porque pasa por alto muchas suposiciones que la gente hace sobre los controles perimetrales.

Estos pasos no evitan el fracaso. Definen hasta qué punto se puede propagar el fracaso.

Start in seconds with the fastest, most affordable VMs.

Launch a vintrual machine in under a minute. Enjoy flexible pricing, powerful hardware, and 24/7 support. Scale as you grow—no long-term commitment needed.

Try VMs now

Los permisos moldean el comportamiento más que las solicitudes

Los despliegues de agentes tienden a fallar debido a permisos excesivos y no a manipulaciones sofisticadas.

Cuando un agente tiene credenciales que permiten leer y escribir ampliamente, incluso un pequeño malentendido o información engañosa puede convertirse en un incidente importante. En ese momento, la contención depende mucho más del modelo de permisos que de la capacidad de razonamiento del agente.

Las credenciales independientes por agente reducen el acoplamiento. Los alcances estrechos reducen el alcance no deseado. El acceso de solo lectura reduce el costo de los errores. Los límites de tasas, las cuotas y los límites de gasto proporcionan límites externos cuando falla la lógica interna. En conjunto, estos controles convierten un comportamiento impredecible en algo a lo que se puede sobrevivir.

Las acciones con un impacto irreversible merecen un cuidado especial. Si un agente puede combinar códigos, eliminar datos, enviar mensajes o activar pagos, la introducción de la confirmación humana ralentiza las cosas en el lugar correcto, ya que el coste de la demora es mucho menor que el coste de la limpieza.

Trata los secretos como frágiles por defecto

Los secretos rara vez se escapan a través de brechas dramáticas. Se ocultan en los registros, los mensajes de error, las capturas de pantalla y los atajos por conveniencia que se acumulan con el tiempo.

Mantener los secretos fuera del control de la fuente, los documentos compartidos y la salida estándar reduce la exposición de forma inmediata. Un administrador de secretos dedicado simplifica el control de acceso y la rotación, a la vez que fomenta mejores hábitos. Cuando el almacenamiento local es inevitable, se debe tratar como un compromiso que requiere disciplina, con permisos estrictos, una separación clara del espacio de trabajo del agente, una rotación regular y medidas de protección explícitas contra la impresión o el registro.

El objetivo no es la limpieza teórica. Su objetivo es reducir el número de lugares donde pueden acabar los secretos y facilitar la detección de la exposición accidental.

El tráfico saliente define la ruta de escape

Los controles entrantes son familiares y, por lo general, se abordan pronto. El tráfico saliente recibe menos atención, aunque determina la forma en que los datos salen del sistema.

Durante los primeros experimentos, el acceso saliente sin restricciones es común y, a menudo, razonable. Tan pronto como un agente gestione datos confidenciales, las rutas de salida merecen ser revisadas. Saber qué destinos necesita el agente, observar dónde se conecta realmente y enrutar el tráfico a través de la infraestructura que usted controla hacen que los comportamientos inesperados sean más fáciles de detectar e interrumpir.

La contención no requiere aislarse de la red. Requiere que las rutas inesperadas destaquen.

Iniciar sesión con intención

Los registros son esenciales para la rendición de cuentas y el diagnóstico, pero la tala indiscriminada crea sus propios riesgos.

El registro centrado en los eventos logra un mejor equilibrio. El seguimiento de los eventos de inicio y finalización, el uso de herramientas y las llamadas de servicio externas proporciona visibilidad operativa sin crear un archivo de contenido confidencial. Las instrucciones completas, las transcripciones y el contenido de los documentos parecen útiles durante el desarrollo, pero a menudo se convierten en obligaciones más adelante, mucho después de que su propósito original haya desaparecido.

Algunos modos de error son específicos del comportamiento de los agentes y no de la carga de la infraestructura. Los reintentos repetidos, los picos repentinos de solicitudes salientes o el uso sostenido de los recursos sin una causa clara suelen indicar la existencia de bucles o errores de configuración, más que de demanda.

Decidir cómo se detiene el sistema

La claridad operativa es lo más importante antes de la implementación, cuando el sistema sigue pareciendo sencillo.

Saber cómo detener el proceso del agente, apagar la máquina virtual desde el plano de control y rotar las credenciales reduce rápidamente la toma de decisiones en situaciones de estrés. Escribir estos pasos con antelación convierte un incidente futuro en una lista de verificación en lugar de en una improvisación.

El aislamiento y los mínimos privilegios dan sus frutos aquí. Cuando algo sale mal, la capacidad de responder inmediatamente a qué puede acceder el agente, qué puede hacer y qué debe revocar determina la rapidez con la que el sistema vuelve a ser comprensible.

Un mínimo defendible

Para los equipos que se mueven rápidamente, un pequeño conjunto de controles es muy útil.

- Una máquina virtual dedicada y un usuario de servicio no raíz limitan el radio de explosión.
- El acceso administrativo seguro y las cuentas en la nube protegidas reducen los puntos de entrada.
- Las credenciales independientes y con menos privilegios con límites limitan los daños.
- El registro limpio y el manejo disciplinado de los secretos reducen la exposición silenciosa.
- Un plan claro de parar y rotar hace que la recuperación sea práctica.

Todo lo demás es refinamiento. A menudo es valioso, a veces es necesario, pero sigue siendo refinamiento.

Un agente siempre activo es un software potente que funciona junto a sus credenciales. Tratarlo como un sistema operativo desde el principio lo convierte en algo en lo que puede confiar y no en algo por lo que preocuparse discretamente.

‍