De OpenClaw a Agentor: Construyendo AI Agents Seguros en Rust

Nos contrataron para auditar la seguridad de un framework open-source de AI agents. El cliente quería garantías de que su infraestructura de agentes -- que manejaba datos sensibles a través de múltiples proveedores de LLM -- cumplía con los estándares necesarios para un despliegue enterprise. Lo que empezó como un engagement de seguridad rutinario se convirtió en el catalizador para construir algo completamente nuevo. El framework tenía buenas intenciones, era popular en GitHub y estaba activamente mantenido. Pero cuanto más profundizábamos, más claro se volvía: los problemas no eran bugs para corregir. Eran decisiones de arquitectura incrustadas en los cimientos.

Lo que encontramos: Los límites de los frameworks de agentes basados en Python

El framework que auditamos seguía un patrón común en el ecosistema de agentes basados en Python. Los agentes ejecutaban herramientas generando subprocesos o llamando funciones directamente dentro del mismo proceso Python. No había sandboxing: una herramienta con un bug o una inyección de prompt maliciosa podía acceder al filesystem, hacer requests de red o leer variables de entorno que contenían API keys. En una de nuestras pruebas, demostramos que un prompt cuidadosamente construido podía hacer que un agente exfiltrara credenciales almacenadas en memoria por otro agente corriendo en el mismo proceso.

La sobrecarga del runtime agravaba los problemas de seguridad. El Global Interpreter Lock de Python significaba que la orquestación multi-agente era fundamentalmente single-threaded. Los tiempos de arranque en frío iban de 2 a 5 segundos dependiendo del árbol de dependencias. El consumo de memoria para un solo agente con un set modesto de herramientas rondaba los 200-400MB: manejable para una demo, prohibitivo cuando corrés docenas de agentes en producción. Y cada reinicio del agente recargaba toda la cadena de dependencias porque Python no tiene concepto de compilación ahead-of-time para este tipo de carga.

Las implicaciones de cumplimiento normativo fueron la preocupación final. El tipado dinámico significaba que los datos que fluían por el pipeline del agente no tenían garantías en tiempo de compilación sobre su forma o contenido. Información personal identificable podía pasar por middleware de logging sin ser detectada porque no había enforcement a nivel de tipos. Lograr cumplimiento GDPR requería envolver cada punto de acceso a datos en checks de runtime: checks que eran fáciles de olvidar, imposibles de aplicar sistemáticamente e invisibles para el análisis estático. Para una organización certificada ISO 27001 como la nuestra, recomendar este framework para uso en producción no era una opción.

La decisión: Construir desde cero en Rust

Nuestro primer instinto fue contribuir parches upstream. Redactamos una propuesta para una capa de sandbox, aislamiento de memoria entre agentes y un sistema de paso de mensajes tipado. Pero cuanto más definíamos el alcance de los cambios, más claro se volvía que no estábamos proponiendo mejoras: estábamos proponiendo una reescritura. La arquitectura de plugins del framework asumía acceso directo a memoria entre componentes. El modelo de ejecución de herramientas estaba construido alrededor del sistema de imports de Python. Agregar aislamiento después del hecho rompería cada extensión existente y derrotaría el propósito del ecosistema.

Elegimos Rust por razones que iban más allá de seguir una tendencia. Nuestro equipo había pasado dos años escribiendo smart contracts para la blockchain de Stellar usando Soroban: contratos en Rust que compilan a WASM y se ejecutan en un entorno sandboxed. Entendíamos el modelo de ownership de Rust, su ecosistema async y, críticamente, su capacidad de compilar a WebAssembly. Cada propiedad que necesitábamos para un framework seguro de agentes -- seguridad de memoria sin garbage collection, abstracciones de costo cero, limpieza determinística de recursos y un target de compilación WASM -- Rust las proveía nativamente.

La decisión no fue tomada a la ligera. Rust tiene una curva de aprendizaje más pronunciada que Python, el ecosistema para tooling de IA es más joven y la velocidad de desarrollo en las primeras semanas fue más lenta. Pero estábamos construyendo infraestructura que iba a correr en producción por años, manejando datos sensibles en industrias reguladas. La inversión inicial en correctitud iba a rendir dividendos cada día que el sistema corriera sin un incidente de seguridad.

Arquitectura de Agentor: 13 crates, una misión

Agentor está estructurado como un workspace de Rust con 13 crates, cada uno con una responsabilidad única y límites bien definidos. No es un monolito partido en carpetas: cada crate compila independientemente, tiene su propia suite de tests y expone una API pública a través del sistema de módulos de Rust. Las dependencias entre crates son explícitas y aplicadas por el compilador. Si un crate no necesita acceso al filesystem, simplemente no depende de std::fs, y ninguna astucia en runtime puede cambiar eso.

• agentor-core -- Gestión del ciclo de vida del agente, ruteo de mensajes y las definiciones de traits que cada otro crate implementa. Es la columna vertebral: define qué es un agente, cómo se comunican los agentes y cómo el sistema orquesta flujos multi-agente.
• agentor-runtime -- El runtime async basado en Tokio que gestiona la ejecución de agentes, límites de recursos y shutdown graceful. Maneja backpressure, priorización de tareas y asegura que ningún agente pueda privar a otros de CPU o memoria.
• agentor-providers -- Capa de abstracción de proveedores LLM con soporte para OpenAI, Anthropic y modelos locales a través de un trait unificado. Cambiar de proveedor requiere cambiar un valor de configuración, no reescribir código.
• agentor-tools -- Framework de definición y ejecución de herramientas con type checking en tiempo de compilación. Cada herramienta declara sus inputs, outputs y permisos requeridos como tipos de Rust.
• agentor-mcp -- Implementación completa del Model Context Protocol, permitiendo a los agentes de Agentor interoperar con cualquier sistema compatible con MCP.
• agentor-sandbox -- La capa de aislamiento WASM. Cada ejecución de herramienta ocurre dentro de una instancia WASM sandboxed con grants de capacidades explícitos.
• agentor-cli -- Interfaz de línea de comandos para crear, ejecutar y gestionar proyectos de agentes. Scaffoldea nuevos proyectos, corre servidores de desarrollo local y gestiona despliegues.
• agentor-codegen -- Pipeline de generación de código con transformaciones AST-aware, coordinación multi-archivo y verificación de compilación integrada.
• agentor-config -- Gestión de configuración con defaults sensibles al entorno, manejo de secretos y validación.
• agentor-telemetry -- Logging estructurado, tracing distribuido y recolección de métricas con compatibilidad OpenTelemetry.
• agentor-auth -- Autenticación y autorización para comunicación agente-a-agente y agente-a-servicio.
• agentor-storage -- Gestión de estado persistente con backends pluggables (SQLite, PostgreSQL, in-memory).
• agentor-testing -- Utilidades de test, providers mock y snapshot testing para comportamientos de agentes.

WASM Sandbox: Seguridad por diseño

La capa de sandbox es la decisión arquitectónica que diferencia a Agentor de toda alternativa basada en Python. Cuando un agente invoca una herramienta -- ya sea leer un archivo, hacer un request HTTP o ejecutar código generado -- esa herramienta corre dentro de una instancia WASM aislada. La instancia no tiene acceso al filesystem del host, no tiene capacidades de red y no comparte memoria con otras herramientas o con el proceso host. El acceso a cualquier recurso debe ser explícitamente otorgado a través de un sistema de capabilities definido en tiempo de despliegue.

Cada instancia WASM corre con límites de memoria configurables y timeouts de ejecución. Si una herramienta intenta asignar más memoria de la permitida, la instancia es terminada: no el agente, no el runtime, solo esa invocación individual de la herramienta. Si una herramienta excede su timeout de ejecución, es eliminada limpiamente con output diagnóstico completo. Esto es fundamentalmente diferente del approach de Python de generar subprocesos y esperar que se comporten bien. En Agentor no hay esperanza: las restricciones son aplicadas por el runtime WASM a nivel de instrucción.

El impacto práctico es significativo. En el framework que auditamos, un ataque de inyección de prompt que causara que una herramienta ejecutara código arbitrario podía comprometer todo el sistema. En Agentor, el mismo ataque queda contenido en una instancia WASM sandboxed sin capabilities: puede computar, pero no puede comunicarse, persistir ni acceder a nada fuera de su sandbox. El radio de impacto de cualquier incidente de seguridad se reduce de 'compromiso total del sistema' a 'una invocación de herramienta devolvió un error.'

Optimizado para generación de código

Este es el núcleo de por qué Agentor existe y lo que lo hace diferente de frameworks que tratan la generación de código como solo otra herramienta más. Agentor fue construido desde cero para ser el runtime de generación de código impulsada por IA: no generación de texto que resulta producir código, sino un pipeline estructurado que entiende el código como un artefacto de primera clase con sintaxis, semántica y dependencias.

El pipeline comienza con desarrollo dirigido por especificaciones. Antes de que un agente genere una sola línea de código, produce una especificación estructurada: los archivos a crear o modificar, las interfaces que deben implementar, las dependencias que requieren y los tests que validarán la correctitud. Esta especificación no es una sugerencia: es un contrato que el pipeline de generación aplica. Si el código generado no coincide con la spec, el pipeline lo rechaza antes de que llegue al filesystem.

La coordinación de output multi-archivo es donde la mayoría de las herramientas de generación de código se caen. Generar una función individual es sencillo. Generar un módulo con cinco archivos que se importan entre sí, implementan interfaces compartidas y deben compilar juntos es un orden de magnitud más difícil. El crate codegen de Agentor mantiene un grafo de dependencias de todos los archivos en un batch de generación, asegura que los imports se resuelvan correctamente entre archivos y valida que el output completo compile como una unidad antes de escribir nada a disco.

Las transformaciones AST-aware reemplazan el reemplazo de texto ingenuo que usan la mayoría de los frameworks. Cuando Agentor modifica código existente, parsea el fuente en un árbol de sintaxis abstracta, aplica transformaciones a nivel semántico y regenera el fuente. Esto significa que agregar un método a una clase no rompe el formato, insertar un import no duplica uno existente y renombrar una función actualiza todos los sitios de llamada. La diferencia entre reemplazo de texto y transformación AST es la diferencia entre una herramienta de buscar y reemplazar y un compilador: uno de ellos entiende el código.

El pipeline de testing integrado cierra el ciclo. Cada ciclo de generación sigue la misma secuencia: generar, compilar, testear, iterar. Si el código generado no compila, Agentor captura los errores del compilador, los alimenta de vuelta al LLM con el contexto relevante y solicita una versión corregida, automáticamente, sin intervención humana. Si el código compila pero los tests fallan, el output de los tests sigue el mismo loop de feedback. Este ciclo de generar-compilar-testear-iterar típicamente converge en 2-3 iteraciones, y cada iteración se beneficia de la arquitectura zero-copy de Rust que minimiza la sobrecarga de pasar codebases grandes entre etapas del pipeline.

Protocolo MCP: Interoperabilidad universal de IA

El Model Context Protocol se está convirtiendo en el estándar de interoperabilidad para sistemas de IA, y Agentor lo implementa como ciudadano de primera clase a través del crate agentor-mcp. Cualquier agente de Agentor puede exponer sus capacidades como herramientas MCP, consumir herramientas de servidores MCP externos y participar en flujos de trabajo multi-sistema sin código de integración custom. Esto significa que un agente de generación de código de Agentor puede usar herramientas provistas por un plugin de IDE, un sistema CI/CD o un servicio de despliegue en la nube, todo a través del mismo protocolo, con las mismas garantías de seguridad aplicadas por la capa de sandbox.

El soporte de MCP también significa que las organizaciones pueden adoptar Agentor incrementalmente. Flujos de trabajo de IA existentes construidos sobre otros frameworks pueden llamar a agentes de Agentor a través de MCP sin reemplazar su infraestructura actual. A medida que los equipos ganan confianza en las características de seguridad y rendimiento, pueden migrar cargas de trabajo adicionales a su propio ritmo. No se requiere una migración big-bang: Agentor fue diseñado para coexistir.

Cumplimiento sin compromisos

Como empresa certificada ISO 27001, construimos Agentor con el cumplimiento normativo como restricción de diseño, no como un agregado posterior. Cada decisión arquitectónica fue evaluada contra los requerimientos de los marcos regulatorios dentro de los cuales operan nuestros clientes.

• GDPR -- El flujo de datos a través del pipeline del agente es rastreado a nivel de tipos. Los campos de PII están marcados con el sistema de tipos de Rust, y cualquier intento de loguear, serializar o transmitir PII sin redacción explícita es detectado en tiempo de compilación. El sandbox asegura que las herramientas no puedan acceder a datos para los que no se les otorgó permiso explícito.
• ISO 27001 -- Controles de acceso, logging de auditoría y contención de incidentes no son módulos opcionales: están integrados en el runtime. Cada acción del agente se loguea con integridad criptográfica, cada invocación de herramienta se registra con sus grants de capabilities, y los eventos de seguridad disparan contención automática a través de la capa de sandbox.
• DPGA (Digital Public Goods Alliance) -- Agentor está diseñado para cumplir con los estándares open-source para bienes públicos digitales, con gobernanza transparente, documentación accesible y despliegue independiente de plataforma a través de WASM.

El contraste con el framework que auditamos es marcado. Lograr cumplimiento GDPR en ese sistema basado en Python requería agregar middleware en runtime en cada límite de datos, sin enforcement del compilador y sin garantía de completitud. En Agentor, el cumplimiento es estructural: si el código compila, las reglas de manejo de datos se aplican.

Rendimiento: Rust vs Python

Somos cuidadosos con los benchmarks porque pueden ser engañosos. Estos números provienen de nuestra suite de tests interna corriendo el mismo flujo de trabajo de agente -- una tarea de generación de código que lee una especificación, genera tres archivos, los compila, ejecuta tests e itera una vez -- en el mismo hardware.

• Tiempo de arranque en frío -- Agentor: 38ms. El framework Python: 3.2 segundos. Esto importa cuando corrés agentes on-demand en entornos serverless donde cada arranque en frío es un usuario esperando.
• Huella de memoria -- Agente Agentor con set completo de herramientas: 42MB. Agente Python equivalente: 380MB. Una reducción de 9x que se traduce directamente en ahorro de costos de infraestructura cuando corrés a escala.
• Agentes concurrentes -- Agentor en una máquina de 4 cores: más de 200 agentes corriendo simultáneamente con escalado lineal de throughput. El framework Python: 12-15 agentes antes de que el GIL se convierta en el cuello de botella.
• Suite de tests -- 483 tests, cero bloques unsafe, cero usos de unwrap() en código de producción. Cada camino de error se maneja explícitamente.
• Overhead del sandbox WASM -- Agregar aislamiento sandbox a una invocación de herramienta cuesta aproximadamente 1.2ms por invocación. La garantía de seguridad de aislamiento completo por menos de dos milisegundos de latencia es un trade-off que aceptamos sin dudarlo.

El número más significativo no es ningún benchmark individual: es el tiempo total de reloj para un ciclo completo de generación de código. Agentor completa el loop de generar-compilar-testear-iterar en aproximadamente el 40% del tiempo que toma el framework Python, principalmente porque la sobrecarga entre etapas del pipeline se mide en microsegundos en lugar de cientos de milisegundos. Cuando corrés miles de estos ciclos por día, esa diferencia se acumula en horas de tiempo ahorrado y costos de API de LLM significativamente menores debido a menos tokens desperdiciados.

Lo que viene

Agentor está en desarrollo activo, y nuestro roadmap refleja las prioridades que escuchamos de los early adopters y nuestro propio uso interno.

• Integración con language server -- Integración profunda con VS Code y otros IDEs a través del Language Server Protocol, permitiendo que los agentes de generación de código de Agentor operen como asistentes de codificación inteligentes con contexto completo del proyecto.
• Orquestación distribuida de agentes -- Ejecución multi-nodo de agentes con distribución automática de trabajo, tolerancia a fallos y replicación de estado para despliegues de escala enterprise.
• Editor visual de pipelines -- Una herramienta basada en el navegador para diseñar flujos de agentes visualmente, con composición drag-and-drop de herramientas, proveedores y patrones de orquestación.
• Soporte extendido de lenguajes -- Las transformaciones AST-aware actualmente soportan Rust, TypeScript y Python. Estamos agregando Go, Java y C# para cubrir los lenguajes enterprise más comunes.
• Release open-source -- Estamos preparando Agentor para su publicación pública bajo una licencia open-source permisiva. Los crates core, documentación y proyectos de ejemplo estarán disponibles en GitHub.

Lo que empezó como una auditoría de seguridad se convirtió en la base de cómo construimos sistemas impulsados por IA en Xcapit. Agentor no es solo un framework que vendemos a clientes: es el framework que usamos internamente para nuestro propio desarrollo de AI agents, nuestros flujos de generación de código y nuestros despliegues críticos de cumplimiento. Cada mejora que hacemos está battle-tested en nuestro propio entorno de producción antes de llegar a cualquier otra persona.

La lección de este camino es una que seguimos reaprendiendo en ingeniería de software: cuando la base está mal, ninguna cantidad de parches la va a arreglar. A veces la decisión responsable es empezar de nuevo con las restricciones correctas, el lenguaje correcto y la arquitectura correcta. Agentor es nuestra respuesta a la pregunta que no pudimos resolver con parches: ¿cómo construís AI agents que sean lo suficientemente seguros, rápidos y confiables para los sistemas que más importan?