Agentes de IA en producción: permisos, sandboxes y secretos

Agentes de IA en producción: lo que me ha dejado esta semana

Estos días en la TRG26 casi todas las conversaciones que tengo van de lo mismo: cómo se meten agentes de IA en producción sin que te den un susto. Y justo esta semana han coincidido cuatro noticias que, juntas, responden bastante bien a esa pregunta. Una va de permisos, otra de secretos, otra de versiones y la última de dónde se ejecuta el código del agente.

Ninguna es un modelo nuevo ni un benchmark. Por eso me parecen más útiles.

Claude Duet: el agente propone, tú apruebas

Anthropic ha abierto en research preview Claude Duet, una app en la que Claude trabaja como agente proactivo. De momento es con lista de espera y solo para usuarios Pro y Max en EE. UU., así que no lo he probado. Lo que cuento sale de su anuncio.

La idea: cada mañana te manda un resumen de lo importante en tus apps conectadas, las revisa cada pocas horas y trabaja en segundo plano en su propia máquina virtual con navegador, aunque tengas el portátil cerrado. Lo interesante para mí es dónde ponen la raya:

• Lee, redacta y prepara trabajo por su cuenta.
• Antes de enviar un mensaje, pagar, firmar un documento o borrar algo, te enseña exactamente lo que va a hacer y espera tu aprobación.
• Hay cosas que no hace ni con tu aprobación, como operar con valores o mover dinero entre cuentas.
• No ve tus contraseñas ni tokens: gestiona las credenciales con el mismo diseño que usan en Claude Managed Agents, y añaden un clasificador nuevo para evitar que se filtre información sensible.

Esto es justo lo que intento explicar cuando un equipo me pregunta por dónde empezar con agentes. No se trata de darle permiso para todo o para nada: hay que separar lo que se puede deshacer de lo que no. Leer y preparar, libre. Actuar hacia fuera, con aprobación. Y una lista corta de cosas prohibidas siempre. Que lo diga una empresa de este tamaño en su producto estrella ayuda a que nadie lo vea como paranoia.

LiteLLM: el token que acabó en un log

La otra cara la puso LiteLLM, una herramienta muy usada para enrutar llamadas a modelos. El 21 de octubre publicaron una versión 1.107.0 comprometida: estuvo unas dos horas en PyPI y algo más en las etiquetas de Docker (latest, main-latest, main-stable), con malware que roba credenciales y carga herramientas de ejecución remota. Si instalaste sin fijar versión en esa ventana, ellos mismos dicen que des el entorno por comprometido, fijes la 1.106.2 y rotes todas las claves.

Lo que más me ha hecho pensar es cómo empezó. Según su análisis, el atacante tenía tokens de GitHub CLI de tres desarrolladores. Y explican que han visto casos concretos en los que Claude Code mete el token OAuth de GitHub CLI del usuario en el cuerpo de una respuesta. Si esos cuerpos se registran en logs, el token acaba en los logs de LiteLLM. Según creen, el atacante entró por un despliegue interno expuesto a internet, sacó los tokens de ahí y con uno de un propietario de la organización desactivó las protecciones de rama. Ellos mismos aclaran que la investigación sigue abierta y que el vector inicial de entrada todavía no está confirmado.

Ninguna pieza por sí sola era una catástrofe. La combinación sí. Me quedo con dos lecciones muy poco glamurosas:

• Fija versiones de todo lo que toca a tus agentes, también las imágenes de Docker. latest en producción es una apuesta.
• No registres a ciegas lo que dicen los agentes. Sus respuestas pueden llevar secretos aunque nadie se lo haya pedido. Un log con cuerpos completos es un almacén de credenciales esperando a que alguien lo encuentre.

La nueva API de Claude rompe cosas (y está bien)

Más mundano, pero también afecta. Anthropic ha publicado la versión 2026-10-21 de su API, la primera nueva desde 2023. En la API de Messages desaparecen temperature, top_p y top_k: con esta versión, si los envías, error 400 en cualquier modelo. Un bloque document dentro de un mensaje del asistente también da 400, y hay renombres en la Admin API.

Si tienes agentes en producción que todavía pasan temperature por costumbre, revisa qué versión de la API usan antes de actualizar el SDK. Un agente que deja de responder un viernes por un parámetro que ya no existe es de los fallos más tontos y más evitables.

Modal: un sandbox por comando

La última es la que más me ha hecho soñar. En una entrevista en Latent Space, Erik Bernhardsson, CEO de Modal, cuenta que se plantearon cerrar los sandboxes por falta de uso y que hoy son cerca de un tercio de sus ingresos, gracias a los agentes de código, los agentes en segundo plano y el aprendizaje por refuerzo. Llevan casi tres mil millones de sandboxes lanzados.

Su visión me encaja mucho con lo que contaba en el post sobre el harness de los agentes. Dice que hoy muchos usan el sandbox como un portátil de desarrollo metido en la nube, con el harness dentro. Él cree que irá hacia algo más efímero: agentes de larga duración que levantan un sandbox en milisegundos, ejecutan unos comandos, hacen snapshot y lo apagan. Uno por comando, con la posibilidad de hacer fork y reanudar. Y separando el agente y su harness del entorno donde se ejecuta el código. Pone el ejemplo de la integración continua: cada test en su propio sandbox, todos en paralelo.

Desde el punto de vista de la seguridad tiene todo el sentido. Según Erik, la mediana de un sandbox en Modal ronda los ocho segundos. Y esto ya es opinión mía: un entorno que vive tan poco y no guarda nada tiene muy poco que robar.

Dos apuntes más de la charla que me guardo. Que los agentes siguen usando sintaxis antigua de Modal porque es la que vieron al entrenarse, así que ahora deprecan con mucho más cuidado. Y que en Modal la revisión de código es opcional, pero a cambio invierten muchísimo en tests y CI/CD. Esto último no lo copiaría tal cual, aunque el fondo es el mismo que defendía en cómo revisar el código generado por IA: la confianza tiene que venir del sistema, no de que alguien mire cada diff.

Lo que me llevo para mi equipo

Si junto las cuatro noticias, me sale una lista bastante corta:

1. Permisos por tipo de acción. Lo reversible, libre. Lo que sale hacia fuera, con aprobación. Lo grave, prohibido.
2. Secretos fuera del alcance del agente, y fuera de los logs.
3. Versiones fijadas, de dependencias y de la API del modelo.
4. Entornos de ejecución efímeros y aislados, separados del agente.

Nada de esto es nuevo para quien ha llevado sistemas a producción. Lo nuevo es que ahora hay un actor más, el agente, que se equivoca de formas distintas a las nuestras.

Si en tu empresa estáis pasando de probar agentes a ponerlos a trabajar de verdad, y queréis hacerlo con permisos, specs y controles desde el principio, en onext es justo lo que hacemos. Escríbeme desde onext.es y lo hablamos.