Servidor genérico rodeado de bloques translúcidos que representan aislamiento

Confianza en IA: solo el 7% confía, así se aíslan agentes

octubre 20, 2026 Alfonso Moreno | Sysadmin Senior 5 Visitas 13 min de lectura

Hace dos meses le pedí a un agente con LLM que me migrara un servicio Python de un VPS viejo a un contenedor nuevo. El agente leyó mi docker-compose, identificó las dependencias y construyó la imagen sin pedirme confirmación. Lo que no vio fue que ese contenedor compartía la red con tres bases de datos que no debía tocar. Por suerte, mi red Docker estaba segmentada y el daño quedó en un reinicio. La historia habría sido muy distinta si el agente hubiera tenido acceso a mi clúster de Proxmox o a mi bucket de backups.

La semana pasada se publicó la encuesta 2026 de Stack Overflow a más de 30.000 desarrolladores en 169 países. El dato que más circuló fue que solo el 7 % de los devs confía en el output de la IA para decisiones importantes. Casi la mitad (48 %) lo usa solo cuando puede verificarlo ellos mismos. Estos números no son una queja de quienes rechazan la IA. Son la radiografía honesta de cómo se está adoptando en producción la generación de código autónomo. Y para los que administramos servidores Linux en producción, el mensaje es directo: la barrera no es la capacidad del modelo, es la falta de un perímetro donde correrlo sin que nos toque lo que no debe.

TL;DR — Lo que vas a tener al final

Tiempo de lectura: 8-10 minutos para entender el estado real de la confianza en IA según 30.000 devs.
Requisito previo: ninguno técnico, pero ayuda haber corrido al menos un agente o script de IA en un servidor Linux.
Resultado concreto: una lista de decisiones prácticas sobre cómo aislar agentes, qué vigilar y cuándo decir que no.
Troubleshooting común: si tu agente ya rompió algo, lo prioritario es segmentar la red y restaurar backup antes de iterar prompts.

Qué midió la encuesta y por qué el 7 % importa

La encuesta 2026 de Stack Overflow se liberó a principios de octubre y, en menos de una semana, el dato del 7 % se filtró a prácticamente todos los resúmenes sectoriales. La pregunta detrás de ese número es directa: ¿confías en el output de la IA para tomar decisiones de trabajo importantes? Solo el 7 % respondió que sí, sin condiciones. El 48 % respondió que confía, pero solo cuando puede verificarlo por su cuenta. El resto no confía, o directamente no usa IA en su flujo de trabajo.

Este no es un dato de marketing ni una opinión aislada. Es la respuesta agregada de 30.000 profesionales que están expuestos a la IA todos los días, en 169 países, en roles que van desde backend hasta devops, sysadmin y data engineering. Cuando el 93 % de la gente que más la usa no la deja tomar decisiones sola, el problema no es la herramienta. Es la ausencia de un contexto donde se pueda operar con seguridad.

El segundo factor que más pesa en la decisión de adoptar o expandir IA en un equipo, según la misma encuesta, es la seguridad y la privacidad. Solo lo supera la precisión. Más de uno de cada cuatro desarrolladores dijo que un incidente de seguridad o privacidad relacionado con IA le costó horas o días de trabajo a su equipo en el último año. Si a esto le sumas que los agentes ahora ejecutan código, leen archivos y hacen llamadas de red, el panorama es claro: la gente no está rechazando la IA, está pidiendo un perímetro más estricto para correrla.

Containers, sandboxes y por qué importa la diferencia

Cuando dockerizó un servicio, la pregunta de aislamiento se respondió hace más de una década. Un contenedor tiene su sistema de archivos, su árbol de procesos y su red, todos definidos en un manifiesto que tú controlas. Pero comparte el kernel del host. Para un servicio cuyo código tú escribiste y revisaste, ese nivel de aislamiento es suficiente. Para un agente que ejecuta código que no escribiste, que no pudiste revisar y que aprende de prompts que tú mismo estás improvisando, no lo es.

Un sandbox va un paso más allá. Limita no solo lo que el proceso ve, sino lo que puede hacer: llamadas al sistema filtradas, syscalls bloqueadas, sin red por defecto, sin acceso al host filesystem sin un canal explícito. El agente corre dentro de una jaula, no de un departamento. Si el modelo se equivoca o si un atacante manipula el prompt, el daño se queda en la jaula.

Docker acaba de lanzar Cloud Sandboxes y publicó la especificación Sandbox Kit, comprometiéndose a enviarla a la CNCF. La propuesta es exactamente esta: tratar a los agentes como workloads de alto riesgo, no como microservicios más. Si administras un homelab o un servidor Linux en producción, esa distinción es la que va a definir si el próximo experimento con un agente te sale gratis o te sale caro.

Cómo auditar tu setup actual antes de correr el próximo agente

Antes de instalar nada, conviene revisar tres cosas concretas en tu entorno. La primera es la segmentación de red. Si tus contenedores comparten bridge con servicios críticos, ya tienes un problema esperando un agente.

# Ver qué contenedores están en la red por defecto
docker network inspect bridge --format '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{"n"}}{{end}}'
# Listar redes definidas por el usuario
docker network ls --filter type=custom

Lo que quieres ver es que existan redes dedicadas para tus bases de datos, para tus servicios internos, y una red aislada para los agentes. Si todo convive en bridge, mover lo sensible a una red custom es la primera mejora que te ahorra un dolor de cabeza.

La segunda es el acceso al host filesystem. Los agentes suelen pedir montar / o el home del usuario “para tener contexto”. Eso les da acceso a tu .ssh, tus credenciales, tu historial de bash. Si un agente necesita leer un proyecto, monta solo ese directorio, en modo lectura, y nada más.

# MAL: dar acceso completo al home
docker run -v /home/tu-usuario:/home -it agente-ia
# BIEN: solo el proyecto, solo lectura
docker run -v /home/tu-usuario/proyectos/mi-app:/app:ro -it agente-ia

La tercera es el principio de menor privilegio en las credenciales. El agente no necesita tu clave de AWS con permisos de root. Si el servicio que va a tocar requiere credenciales, genera una clave específica para esa tarea, con los permisos mínimos, y rotala cuando termines.

# Revisar qué credenciales están montadas en contenedores corriendo
docker ps --format '{{.Names}}' | while read name; do
  echo "=== $name ==="
  docker inspect "$name" --format '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"n"}}{{end}}'
done | grep -E '.aws|.ssh|.kube|.config/gcloud'

Si aparece algo, ese contenedor es un vector de ataque. Mueve esas credenciales a un vault con acceso temporal, o reescribe el workflow para que el agente pida los secretos en cada ejecución en vez de tenerlos persistidos.

Sandboxes en Linux sin Docker: bubblewrap y firejail

No necesitas Cloud Sandboxes para empezar a aislar. En Linux ya tenemos dos herramientas maduras que llevan años haciendo exactamente esto: bubblewrap y firejail. Si tu agente corre como un binario local, puedes envolverlo en una jaula con permisos mínimos en tres líneas.

# Instalar bubblewrap
sudo apt install bubblewrap   # Debian/Ubuntu
sudo dnf install bubblewrap   # Fedora
# Ejecutar un agente dentro de un sandbox
bwrap --ro-bind /usr /usr 
      --ro-bind /lib /lib 
      --ro-bind /lib64 /lib64 
      --tmpfs /home 
      --tmpfs /tmp 
      --unshare-all 
      --die-with-parent 
      /usr/bin/python3 /opt/agente/script.py

El agente ve /usr y /lib en modo solo lectura (para poder cargar binarios), pero su /home y /tmp son temporales. No tiene red, no puede ver tus archivos, no comparte namespace con tu sesión. Si hace algo mal, el daño se va con el proceso cuando termina. firejail hace algo equivalente con perfiles prearmados: firejail --noprofile --net=none --private agente-ia te deja en una jaula similar sin escribir un manifiesto.

La diferencia con Docker es que no tienes la portabilidad ni la orquestación, pero para correr un agente en una laptop o en un servidor de pruebas, suele ser más que suficiente. Y como bonus, ambos son proyectos open source auditables, sin un proveedor intermediario.

Qué hacer si tu agente ya rompió algo

El incidente más común no es dramático. Es silencioso: el agente ejecuta un rm -rf con una ruta mal armada, mueve un archivo de configuración, o reinicia un servicio en el momento equivocado. Si el daño ya está hecho, la prioridad es contener, no entender.

# 1. Frenar el agente y sus procesos hijos
pkill -f "agente-ia" 2>/dev/null
# 2. Ver qué archivos cambió en los últimos 30 minutos
find / -newer /tmp/checkpoint_marker -type f 2>/dev/null | head -50
# 3. Restaurar el último backup conocido
sudo systemctl stop servicio-afectado
sudo rsync -a /var/backups/servicio/ /var/lib/servicio/
# 4. Auditar el log del agente para entender qué lo causó
less /var/log/agente-ia/$(date +%Y-%m-%d).log

El orden importa: primero se frena al agente, después se evalúa el daño, después se restaura. Si intentas entender el incidente con el agente todavía corriendo, el daño puede seguir creciendo mientras lees el log. Una vez contenido, ya puedes revisar el prompt, ajustar el alcance, y volver a intentarlo con la jaula más cerrada.

Por qué la respuesta correcta a veces es no usar un agente

No todos los trabajos ameritan un agente. Si lo que vas a hacer es crítico, irreversible, o toca producción, el costo de un error supera el beneficio de automatizar. La encuesta lo dice en otros términos: el 48 % usa IA solo cuando puede verificarlo. Para ciertas tareas, verificar lleva más tiempo que hacerlo a mano. En esos casos, la decisión correcta es no delegar.

Un buen filtro mental: si el cambio es destructivo (rm, drop table, terraform destroy), si toca datos que no puedes regenerar (backups, configuraciones únicas, secretos), o si el output va a un sistema al que no puedes volver atrás fácilmente, hazlo tú. Reserva los agentes para tareas reversibles, repetitivas, y bien delimitadas: refactors, generación de tests, documentación, migraciones de bajo riesgo.

Cuándo un sandbox deja de ser suficiente

Un sandbox aísla al agente del host, pero no aísla al agente de internet. Si tu agente puede hacer llamadas HTTP salientes, puede exfiltrar datos, puede subir código a un repo equivocado, puede terminar una conexión TLS hacia donde no debe. La mitigación es egress filtering: una lista explícita de dominios a los que el agente tiene permiso de hablar.

# Con nftables, bloquear todo el egress del agente y permitir solo lo necesario
sudo nft add table inet agent_filter
sudo nft add chain inet agent_filter output { type filter hook output priority 0 ; policy drop ; }
sudo nft add rule inet agent_filter output ip daddr 1.1.1.1 accept  # DNS
sudo nft add rule inet agent_filter output ip daddr api.openai.com accept
sudo nft add rule inet agent_filter output ip daddr github.com accept
# Aplicar la tabla solo al namespace de red del agente
sudo nft add rule inet agent_filter output meta skuid 1001 accept  # UID del agente

Esto no es paranoia. Es la diferencia entre un agente que puede romper tu servidor y un agente que puede romper tu servidor y además publicar el backup en un bucket público. La encuesta señala que la privacidad y la seguridad son el segundo factor más importante para adoptar IA, y la fuga de datos por egress no controlado es exactamente la clase de incidente que ese factor está intentando evitar.

Resumen: las cinco reglas para correr agentes en tu servidor

La confianza en la IA no se gana con mejores modelos, se gana con mejor perímetro. La encuesta de Stack Overflow 2026 lo demuestra con números: la mayoría de los devs la usa, pero con condiciones. Si administras servidores Linux, el plan mínimo es este.

Primero, segmenta tu red. Contenedores, bases de datos y agentes en redes distintas. Segundo, monta solo lo necesario. Nada de volúmenes con el home completo. Tercero, credenciales con scope mínimo y rotación. Cuarto, sandbox para los agentes que ejecutan código. Bubblewrap, firejail o Cloud Sandboxes, según tu escala. Quinto, egress filtering. Una lista explícita de a dónde puede hablar el agente, denegando todo lo demás.

Con estas cinco reglas, puedes empezar a usar agentes en producción con el mismo nivel de riesgo que cualquier otro servicio crítico. No es cero riesgo, pero es un riesgo que puedes medir y contener. Y eso, según los datos, es exactamente lo que el 93 % de los devs está pidiendo.

Preguntas frecuentes

¿Qué es exactamente un sandbox y en qué se diferencia de un contenedor?

Un contenedor aísla el sistema de archivos, los procesos y la red, pero comparte el kernel del host. Un sandbox limita además las llamadas al sistema (syscalls), bloquea el acceso a recursos por defecto y suele ejecutarse con un usuario sin privilegios. Para código que escribiste, alcanza con un contenedor. Para un agente que ejecuta código generado dinámicamente, el sandbox ofrece una capa extra que reduce el blast radius si el modelo se equivoca.

¿Necesito Docker Cloud Sandboxes o me sirve bubblewrap en mi laptop?

Si corres un agente de forma puntual en una laptop o en un homelab, bubblewrap o firejail son suficientes y más simples. Cloud Sandboxes apunta a equipos que necesitan portabilidad entre local y nube, orquestación, y telemetría centralizada. La decisión es de escala: para uno o dos agentes, la solución nativa de Linux es más liviana. Para un equipo con muchos agentes en paralelo, la propuesta de Docker escala mejor.

¿Cómo verifico que un agente no esté filtrando datos sin que yo lo note?

Activa un egress filter estricto con nftables o iptables, y revisa los logs de red del contenedor o namespace del agente periódicamente. Una métrica útil es contar las conexiones salientes por destino: si aparecen dominios que no autorizaste, es señal de exfiltración o de un prompt mal armado. También puedes correr el agente con un proxy tipo mitmproxy y auditar todas las llamadas HTTP y TLS manualmente.

¿Por qué la encuesta dice que la seguridad es el segundo factor y no el primero?

El primer factor es la precisión: si el modelo falla demasiado, no sirve para nada. Pero una vez que la precisión es aceptable, lo que define si un equipo expande el uso de IA es si puede hacerlo sin incidentes. La encuesta refleja que los devs ya están conformes con la calidad del output; lo que frena la adopción masiva es la falta de garantías operativas, que es exactamente lo que el sandbox y el aislamiento intentan resolver.

¿Vale la pena correr un agente en producción si todavía no tengo segmentación de red?

No. Sin segmentación, un agente que se equivoca puede afectar otros servicios del mismo host, y la auditoría posterior se vuelve imposible. Antes de delegar cualquier tarea a un agente en un servidor de producción, segmenta al menos la red y los volúmenes, y corre la primera tanda en un entorno de staging o descartable. Una vez que la jaula está probada, puedes promover el agente a producción con el mismo nivel de confianza que le das a cualquier servicio crítico.