El agente llama al proxy local, que escanea el cuerpo con el motor, aplica la política, registra un evento de auditoría de forma asíncrona, reenvía la petición redactada al upstream y devuelve la respuesta con un header de feedback.
Arquitectura · 10 nodos · 4 flujos
1Agente de código con IA → Proxy de salidapetición a la base URL local
Servicio / cómputo
Almacén de datos
Cliente
Sistema externo
Síncrono
Asíncrono / bucle
Desplázate hacia los lados para ver todo el diagrama
Cómo fluye, paso a paso
Haz clic en un paso para saltar a él. Haz clic en un componente para ver detalles.
Qué hace
Un reverse proxy en Rust que se coloca entre agentes de código con IA (Claude Code, Codex, opencode) y las APIs LLM. Escanea cada petición en menos de un milisegundo y bloquea, redacta o advierte sobre secretos y datos personales, guardando solo hashes con clave en un almacén de auditoría local.
El problema
Los agentes de código con IA envían código, prompts y contexto a APIs externas. Una clave de API, un volcado de .env o una clave PEM en esa carga sale de la máquina y no existe un punto de control estándar para impedirlo.
Qué construí
Workspace de Rust modular con crates separados para motor, proxy, almacén, packs y CLI, con código unsafe prohibido y clippy pedantic en modo deny.
Detección sobre un motor regex de tiempo lineal con un pack de 13 reglas, pruebas de fuzzing contra ReDoS y latencia p99 de escaneo medida bajo 1 ms.
Diseño de auditoría sin fugas: los secretos en crudo nunca se persisten; solo hashes HMAC con clave por instalación, flags y conteos llegan a SQLite.
Fail-closed por defecto, packs de reglas firmados con Ed25519 verificados al arrancar e intercepción MITM opcional restringida a una lista de hosts exactos.
Plano de control con configuración intercambiable en caliente, dashboard protegido con CSP, token de administración obligatorio en binds no loopback y comando allow-once de emergencia con motivo registrado.
Distribución por Homebrew, script de instalación, zip para Windows, Docker y un chart de Helm, con workflows de release y de subida de versión.
Decisiones clave y por qué
01
Reverse proxy vía *_BASE_URL, MITM solo opcional
Apuntar los agentes a una URL base local no requiere confiar en certificados y es la vía menos invasiva; la intercepción TLS existe para clientes difíciles pero está desactivada por defecto y es fail-closed.
02
Regex con motor de tiempo lineal
El escaneo está en la ruta de la petición, así que una latencia predecible y la inmunidad al backtracking catastrófico importan más que funciones de patrón exóticas.
03
Guardar hashes, nunca valores
Una traza de auditoría sirve para triage y deduplicación sin convertirse en otro lugar donde viven los secretos. Los HMAC con clave por instalación evitan la correlación entre instalaciones.
04
Fail closed y encadenable
Si el motor falla, bloquear es más seguro que filtrar. Una opción de encadenamiento permite que Cerberus escanee el texto plano primero y entregue la petición sanitizada a otro proxy, como un compresor de tokens.