Construcción de agentes de IA seguros con kagent en Kubernetes

Los desarrolladores ya pueden ejecutar kagent, un proyecto del Sandbox de la CNCF, en portátiles locales para crear agentes de IA que operan como recursos de Kubernetes. Publicado el 12 de octubre de 2026 por Antonio Berben y Felipe Vicens, esta guía demuestra cómo crear un constructor de agentes que genere otros agentes de forma segura. El proceso se basa en salvaguardas estrictas en lugar de confiar implícitamente en el modelo de lenguaje grande.

Qué ocurrió

El artículo detalla un laboratorio paso a paso para configurar un constructor de agentes utilizando kagent. En lugar de tratar los agentes como procesos independientes, kagent los define como recursos personalizados en Kubernetes. Este enfoque permite que un agente existente genere manifiestos YAML para nuevos agentes, creando efectivamente un constructor autoservicio. La configuración utiliza herramientas de código abierto, incluyendo Docker, kind, kubectl, helm, jq y Ollama, para mantener los costos mínimos y evitar dependencias de la nube.

Una parte crítica de la configuración implica configurar el servidor de herramientas de manera segura. Por defecto, los charts de kagent podrían otorgar privilegios de cluster-admin, lo cual es peligroso incluso para pruebas locales. La guía instruye a los usuarios a restringir los permisos para que el agente constructor solo pueda crear tipos específicos de recursos. Esto asegura que los agentes generados operen dentro de un alcance definido, previniendo el acceso no autorizado a componentes sensibles del clúster como secrets o deployments.

La demostración recorre la instalación de la infraestructura necesaria, la selección de un modelo local capaz y la interacción con el constructor a través de una interfaz de usuario o API. El objetivo es mostrar que construir agentes no es magia, sino una tarea de ingeniería estructurada. Se enfatiza que, aunque la configuración inicial es sencilla, el verdadero desafío radica en gestionar la gobernanza y la seguridad a medida que estos agentes escalan más allá de un entorno de portátil único.

Cómo funciona

El sistema depende de tres capas distintas de seguridad que no dependen únicamente del prompt. Primero, una lista de permitidos restringe qué herramientas puede ver el modelo. De las veintidós herramientas disponibles, el constructor solo accede a tres. Segundo, un mecanismo de intervención humana requiere la aprobación del usuario antes de cualquier ejecución de herramienta que modifique el estado. Cuando el agente propone un cambio, la ejecución se pausa, permitiendo al usuario revisar el manifiesto exacto antes de aplicarlo. Tercero, el Control de Acceso Basado en Roles (RBAC) a nivel de Kubernetes garantiza que, incluso si un manifiesto es aprobado, el servidor de API rechace cualquier acción fuera de los permisos de la cuenta de servicio.

El agente constructor opera recibiendo una solicitud en lenguaje natural, como crear un agente para equipos de soporte. Luego genera un manifiesto de Kubernetes para un nuevo recurso Agent. Este manifiesto incluye un prompt de sistema, configuración del modelo y un conjunto restringido de herramientas de solo lectura. El constructor no ejecuta la creación directamente; en su lugar, emite el YAML para revisión. Una vez aprobado, el controlador de kagent aplica el manifiesto, iniciando un nuevo pod que habla el protocolo Agent-to-Agent (A2A).

Esta arquitectura trata los prompts como solicitudes, no como garantías. La aplicación real proviene de la infraestructura. Por ejemplo, si el modelo alucina un nombre de herramienta o intenta crear un deployment en lugar de un agente, la lista de permitidos o las políticas RBAC bloquean la acción. Esta separación de responsabilidades asegura que los errores en la salida del modelo no conduzcan a violaciones de seguridad ni a modificaciones involuntarias del clúster.

Detalles clave

• El modelo local recomendado es qwen3-coder:30b-a3b, ya que los modelos más pequeños a menudo fallan al generar manifiestos válidos de Kubernetes.
• El constructor utiliza una lista de permitidos de tres herramientas de las veintidós disponibles en el servidor para limitar sus capacidades.
• Se requiere aprobación humana para cualquier llamada a herramienta que cambie el estado, proporcionando un punto de control antes de la ejecución.
• Las políticas RBAC restringen la cuenta de servicio del constructor a crear solo recursos Agent, bloqueando el acceso a secrets o deployments.
• La configuración utiliza kind para el clúster de Kubernetes y Ollama para la inferencia de modelos locales para minimizar costos.
• La UI se ejecuta en localhost mediante kubectl port-forward, asegurando que no esté expuesta a internet público durante las pruebas.

Por qué importa

Para ingenieros de software y líderes técnicos, este enfoque desplaza el foco de la ingeniería de prompts al diseño de infraestructura. Confiar exclusivamente en los prompts para la seguridad es insuficiente porque los modelos pueden malinterpretar instrucciones o alucinar nombres de herramientas. Al integrar la seguridad en la capa de Kubernetes, los equipos pueden construir agentes robustos frente a errores del modelo. Este método proporciona un rastro de auditoría claro y límites imponibles, esenciales para entornos de producción.

El artículo también destaca la brecha entre la experimentación local y la gobernanza empresarial. En un portátil, todas las acciones parecen provenir del mismo usuario, dificultando el rastreo de costos o propiedad. En un entorno corporativo, múltiples agentes y frameworks pueden coexistir, cada uno con diferentes posturas de seguridad. Esta complejidad aboga por una capa de gobernanza centralizada que haga de proxy para el tráfico, maneje la autenticación y proporcione observabilidad en todas las interacciones de los agentes.

Comprender estos mecanismos ayuda a los desarrolladores a ir más allá de simples demos hacia la construcción de sistemas confiables. Demuestra que los agentes de IA pueden integrarse en flujos de trabajo DevOps existentes utilizando herramientas familiares como YAML y kubectl. Esto reduce la barrera de entrada para equipos ya invertidos en Kubernetes, permitiéndoles aprovechar la IA sin adoptar paradigmas operativos completamente nuevos.

Qué puedes hacer

• Instala Docker, kind, kubectl, helm, jq y Ollama para preparar tu entorno local para el laboratorio.
• Descarga el modelo qwen3-coder:30b-a3b usando Ollama para asegurar una generación fiable de manifiestos.
• Crea un clúster kind llamado kagent-builder e instala kagent con políticas RBAC restringidas.
• Usa kubectl port-forward para acceder a la UI en localhost y probar el constructor de agentes.