Puesta en marcha de "Bring Your Own Agent" en Red Hat AI, la edición de OpenClaw

El mundo de los agentes de inteligencia artificial es caótico. Los equipos utilizan LangChain, LlamaIndex, CrewAI, AutoGen o diseñan soluciones personalizadas desde cero. Bien. Así es como debe ser durante la fase creativa. Pero una vez que un agente sale del portátil de un desarrollador y empieza a comunicarse con datos de producción, a llamar a interfaces de programación de aplicaciones (API) externas o a ejecutarse en una infraestructura compartida, la libertad sin medidas de seguridad deja de ser una ventaja y se convierte en una responsabilidad.

Hemos visto al sector pasar por varias fases: API de modelos (como finalizaciones de chat), API de agentes (como asistentes y, más adelante, la API de respuestas de OpenAI), la era de los frameworks y ahora la era de los arneses y los agentes de codificación. La capa superior sigue cambiando. Se está volviendo fungible. Lo que no cambia es la brecha entre "funciona en mi computadora portátil" y "se ejecuta en producción, de forma segura, a escala y con registros de auditoría".

Nuestra estrategia de AgentOps se basa en un principio fundamental: Bring Your Own Agent (BYOA). La plataforma es independiente del framework. Lo importante es que el agente tenga identidad, se ejecute con privilegios mínimos, sea observable, pase las comprobaciones de seguridad y pueda ser auditado posteriomente. La plataforma ofrece seguridad, control, observabilidad y gestión del ciclo de vida. El agente sigue siendo tuyo.

Qué ofrece Red Hat AI

En esta serie, se presenta una vista previa del funcionamiento de BYOA en la práctica, y se abordan los recursos disponibles actualmente y los que estamos desarrollando.

Tomamos OpenClaw, un asistente personal de inteligencia artificial que dirige las interacciones de los agentes a través de canales (WhatsApp, Telegram, Slack, Discord y más) mediante un WebSocket Gateway central, y lo ponemos en funcionamiento en Red Hat AI. No lo envolvemos en un framework propietario, lo envolvemos en una infraestructura de plataforma. OpenClaw es solo un ejemplo: este enfoque funciona para cualquier tiempo de ejecución del agente.

De forma predeterminada, OpenClaw no aísla mucho. No aplica el control de acceso basado en roles (RBAC), el rastreo de llamadas a herramientas ni el acceso a servicios externos. Red Hat AI agrega cada una de esas capas con las funciones propias de Red Hat OpenShift y Red Hat OpenShift AI, sin tocar el código del agente. El resto de esta publicación detalla cada una de esas capas.

Reutilización de tecnología nativa de la nube para agentes

No estamos creando una infraestructura de agentes desde cero. Estamos reutilizando las herramientas y los patrones de implementación que ya tiene OpenShift y ampliándolos para cargas de trabajo con agentes con Red Hat AI.

Los agentes necesitan aislamiento: Los contenedores de espacio aislado de OpenShift (basados en el proyecto Kata Containers y un producto en capas de disponibilidad general) y la próxima integración del agente y el entorno de pruebas (sandbox) ofrecen una ejecución aislada del kernel por sesión de agente. Los datos del host y de otros agentes están protegidos contra agentes comprometidos.

Los agentes necesitan identidad: Tokens de cuentas de servicio con alcance, con SPIFFE/SPIRE para la identidad criptográfica de la carga de trabajo. Sin claves codificadas. En su lugar, la plataforma verificará al agente e insertará tokens de cuenta de servicio de corta duración y con alcance en la plataforma. Esto está previsto con la integración de Kagenti para el ciclo de vida del agente como parte de Red Hat AI. 

Los agentes necesitan multitenencia: Aislamiento del espacio de nombres, NetworkPolicy, ResourceQuota, con verificación de que los límites se mantienen en pruebas adversas.

Los agentes necesitan medidas de seguridad de políticas en varias capas: Políticas de OPA/Gatekeeper y Kyverno en Kubernetes. La puerta de enlace delProtocolo de Contexto de Modelos (MCP) para la autorización a nivel de herramienta. Guardrails Orchestrator y NeMo Guardrails en el límite de inferencia del modelo (más información en la siguiente sección).

Hacer que los agentes sean más seguros y estén listos para producción

Para muchos equipos empresariales, la seguridad se está convirtiendo en el principal obstáculo para llevar los agentes y los modelos a producción. No el rendimiento. No el costo. La confianza. Las empresas necesitan tener la certeza de que su inteligencia artificial sigue cumpliendo las normativas y protege su marca de riesgos legales y de reputación, sobre todo una vez que la consumen usuarios externos.

Red Hat AI ofrece un enfoque de portfolio para la seguridad que abarca todo el ciclo de vida, incluyendo la detección, las pruebas y la mitigación de riesgos antes de que lleguen a producción, y protege contra las amenazas que surgen en tiempo de ejecución.

Antes de que un agente entre en funcionamiento: Garak (previsto como parte de Red Hat AI) proporciona un análisis de vulnerabilidades adversarias para detectar fugas, inyección de prompts y otros vectores de ataque a nivel de modelo. La integración está prevista a través del operador TrustyAI, y se puede consumir a través de EvalHub (un plano de control de evaluación) y Kubeflow Pipelines, lo que permite realizar escaneos adversarios en CI/CD antes de la promoción.

En tiempo de ejecución (medidas de seguridad en el límite de la inferencia): El Guardrails Orchestrator de TrustyAI (disponible con carácter general a partir de OpenShift AI 3.0) examina las entradas y salidas del modelo. NeMo Guardrails (vista previa técnica) añade medidas de seguridad conversacionales programables. Ambos operan en el límite de la inferencia, interceptando llamadas individuales de modelos de lenguaje de gran tamaño (LLM) para aplicar la seguridad antes de que una respuesta llegue al agente. Una vista planificada del riesgo del modelo en el catálogo de modelos mostrará estas señales de seguridad junto con los metadatos del modelo, para que los equipos puedan tener en cuenta el riesgo del caso de uso antes de elegir un modelo.

Observabilidad, rastreo y evaluación

Los agentes son estocásticos. No puedes depurarlos ni confiar en ellos en producción sin rastros de ejecución.

Red Hat AI proporciona la base para la observabilidad de los agentes, comenzando con el soporte de primera mano para MLflow, que actualmente se encuentra en vista previa para desarrolladores y está previsto que esté disponible con carácter general en una próxima versión. 

MLflow Tracing captura prompts, pasos de razonamiento, invocaciones de herramientas, solicitudes de API de LLM y costos de tokens. Todos los rastreos son compatibles con OpenTelemetry, por lo que se puede integrar cualquier receptor compatible con OTEL. Más allá del rastreo, las capacidades de MLflow para la puntuación y la evaluación se pueden utilizar para evaluar la calidad del agente a lo largo del tiempo, y está previsto que estos flujos de trabajo se invoquen a través de Eval Hub, un plano de control de evaluación que forma parte de OpenShift AI.  

Gobernanza de las llamadas a herramientas a escala

Los agentes llaman a herramientas. La pregunta es cómo gobernar esas llamadas.

El MCP Gateway (construido con el equipo de redes de OpenShift, basado en Envoy), actualmente en versión de prueba para desarrolladores, se sitúa frente a todos sus servidores MCP como un único punto final seguro. Añade filtrado de herramientas basado en la identidad para que los agentes solo vean las herramientas autorizadas, intercambio de tokens OAuth2 para acceso con alcance por backend y gestión de credenciales para que las llamadas a herramientas confidenciales pasen por la autorización adecuada. La plataforma impone el acceso. La aplicación gestiona las credenciales, por lo que no hay fugas entre servidores.

La autorización se aplica a través de AuthPolicy de Kuadrant, que integra Authorino para la validación de JSON Web Token (JWT) y la evaluación de reglas de Open Policy Agent (OPA) en el nivel de Gateway API.

Para OpenClaw, esto significa que el agente establece una variable de entorno MCP_URL y obtiene acceso a un catálogo de herramientas agregado. Las herramientas a las que realmente puede llamar están determinadas por sus notificaciones de token, no por el prompt. Los ataques de inyección de prompts que intentan engañar al agente para que llame a herramientas no autorizadas se detienen en la capa de infraestructura, porque la puerta de enlace ignora por completo el contenido del prompt. Valida las notificaciones de token.

Elección de superficies de API para agentes de producción

Muchos equipos empezaron con el chat, pasaron a las finalizaciones de chat y las API de OpenAI, luego a los frameworks, y ahora a los arneses de agentes. Las API que utilizan los agentes se están consolidando. Una de las principales API para las cargas de trabajo de agentes es la Responses API, y OpenAI ahora ha abierto esa dirección a través de la especificación OpenResponses.

Red Hat AI proporciona una implementación totalmente compatible con la especificación OpenResponses. Esto crea una ruta para que los equipos ejecuten cargas de trabajo de agentes en una infraestructura autohospedada o de modelo híbrido, en lugar de enrutar cada prompt, llamada a herramienta y artefacto de razonamiento a través de servicios de terceros.

Los tiempos de ejecución compatibles con OpenResponses para entornos autogestionados e híbridos siguen siendo limitados. Red Hat AI proporciona una de las implementaciones más maduras de la especificación que aborda esa carencia, lo que la convierte en una ruta práctica para los usuarios de OpenClaw que desean preservar el comportamiento del agente orientado a la API de respuestas de OpenAI mientras trasladan la ejecución a la infraestructura que controlan.

Para los equipos que desean una ruta autohospedada sin una capa de orquestación de la API de respuestas, vLLM, que forma parte de Red Hat AI, proporciona un punto final /v1/chat/completions compatible con OpenAI que OpenClaw puede consumir directamente.

Ciclo de vida del agente con Kagenti

Muchos equipos se atascan al mover un agente del portátil a producción. Kagenti, previsto como parte de OpenShift AI, cierra esa brecha. El kagenti-operator descubre automáticamente los agentes a través de CRD de AgentCard basados en A2A e inyecta identidad (SPIFFE/SPIRE), rastreo y gobernanza de herramientas (MCP Gateway) sin cambios en el código del agente a través de una construcción AgentRuntime. La plataforma gestiona todo el ciclo de vida, desde el descubrimiento hasta la gobernanza del tiempo de ejecución. El catálogo de agentes y el registro están en el plan para la interfaz de usuario de OpenShift AI, junto con un catálogo MCP para los servidores de herramientas.

Esta serie

Esta serie de blogs le guía a través de estas capas en detalle con OpenClaw como un ejemplo de tiempo de ejecución del agente. Cada publicación es autónoma. Léelas en orden o salte a la que coincida con su problema actual.

La única constante en cada publicación es el principio BYOA. Nunca te pediremos que reescribas tu agente. Aportamos rigor empresarial al agente, no al revés.

Para obtener más información sobre la stack de productos de Red Hat AI para diseñar, evaluar y reforzar la seguridad de las aplicaciones de inteligencia artificial, consulta la documentación oficial del producto y los siguientes proyectos upstream que son fundamentales para la historia de Red Hat AI AgentOps:

• vLLM
• MCP Gateway
• Open Responses/Llama Stack
• Authorino
• Garak
• TrustyAI Service Operator
• NeMo Guardrails
• Kagenti
• Kagenti Operator