Memnox: cerrar atajos en un cortafuegos para agentes de IA

El proyecto

En una frase: Memnox es un guardaespaldas para los asistentes de IA de programación: antes de que el asistente ejecute un comando en tu ordenador, Memnox decide si está permitido, si necesita tu aprobación o si se bloquea.

Asistentes de IA como Claude Code, Cursor o Codex ya no se limitan a sugerir código — ejecutan comandos, instalan paquetes, suben cambios a GitHub y editan archivos por su cuenta. Casi siempre es genial. Pero un solo comando equivocado puede borrar trabajo, filtrar una contraseña o enviar código roto a producción. Hoy la protección suele ser «confiar en la IA» o «pulsar aprobar cien veces al día».

Memnox se coloca en medio. Escribes reglas sencillas («nunca forzar un push a main», «pregúntame antes de borrar archivos», «nunca enviar mis claves de API a ningún sitio») y las aplica a cada acción de cada asistente, guarda un registro de lo que pasó y crea un punto de restauración antes de cualquier acción destructiva para poder volver atrás.

Qué lo hace innovador

• Reglas, no suposiciones. Algunas herramientas de seguridad preguntan a otra IA si una acción parece peligrosa. Memnox sigue reglas fijas: la misma acción recibe siempre la misma respuesta.
• Las mismas reglas para todos los asistentes. Uses la herramienta de IA que uses, se aplican las mismas protecciones.
• Varias capas de protección. Si una acción se escapa de una comprobación, otra la atrapa.
• Un botón de «deshacer». Antes de cualquier acción destructiva guarda un punto de restauración, y cada decisión queda en un registro que puedes leer.

En resumen: mi contribución y lo que aprendí

Mi parte: se aceptaron 11 de mis 13 mejoras. Cada una cerraba una forma de saltarse las reglas: un comando escrito en dos líneas podía escapar a una regla de «nunca hagas esto», varias acciones enviadas juntas podían saltarse por completo las comprobaciones, y las contraseñas podían acabar escritas en claro en el historial de sesiones. También hice que más comandos peligrosos guarden antes un punto de restauración.

Lo que me llevo: en una herramienta de seguridad, los casos raros son el trabajo — el salto de línea en el que nadie piensa es justo lo que prueba un atacante. Y un problema de seguridad merece comunicarse primero en privado a los mantenedores, aunque la corrección sea mínima.

---

El resto del artículo entra en los detalles técnicos, para desarrolladores.

Por dentro

Un monorepo TypeScript (Apache-2.0) con más de 8 000 tests: hooks de agentes, proxy MCP, interceptores en el PATH, proxy de red local, registro de auditoría y puntos de restauración basados en git.

En detalle: lo que aporté

Mi contribución en cifras: 13 pull requests, 11 fusionadas.

Cuando el trabajo de un proyecto es la seguridad, cada bug es una forma de saltárselo.

Un salto de línea que se colaba bajo las reglas de denegación

Los comodines de las políticas se compilaban como .* sin la bandera s — y en JavaScript, . no coincide con \n. Un comando de shell de varias líneas podía escapar a una regla de denegación. La corrección es una sola bandera de regex. La traté como una vulnerabilidad: PR en borrador, descripción pública mínima y el análisis completo enviado en privado, como pide la política de seguridad.

Los lotes JSON-RPC se saltaban el cortafuegos MCP

#89: cada mensaje entrante se leía como un único objeto JSON-RPC. Un lote es un array, no tiene method, y simplemente se reenviaba — un tools/call dentro de un lote llegaba al servidor sin veredicto y sin entrada en el registro. Ahora los lotes se dividen, cada llamada se juzga en orden (para que las peticiones de aprobación lleguen en el orden de envío), las permitidas siguen juntas y las denegadas vuelven como rechazos. La revisión mostró que los lotes anidados [[…]] seguían pasando; una comprobación de tipo responde ahora -32600 Invalid Request.

Peticiones tomadas por resultados

Cliente y servidor numeran sus ids de forma independiente, pero las respuestas se emparejaban solo por id. Una petición del servidor con id 1 podía cerrar la llamada abierta id 1 del cliente e incluso borrar la lista de herramientas. Ahora una respuesta es un mensaje sin method y con result o error:

const isResponse = (m: JsonRpcMessage) =>
  m.method === undefined && (m.result !== undefined || m.error !== undefined);

Secretos y cierres inesperados

• --password="correct horse battery staple" solo se ocultaba hasta el primer espacio.
• Las transcripciones de sesión guardaban la salida del agente en claro. Ahora pasan por un flujo que enmascara — línea a línea, porque los cortes entre chunks parten los tokens, y con una máscara por flujo (compartir una sola dejaba escapar un trozo de contraseña, como mostró la revisión).
• Cualquier proceso local podía tumbar el proxy de red con %zz en una cabecera o con una dirección IPv6.
• shred, truncate o git stash drop se ejecutaban sin punto de restauración; clientes de base de datos como mariadb, pgcli y redis-cli FLUSHALL no se reconocían como destructivos.

Lecciones técnicas

• En una herramienta de seguridad, los casos límite son el producto. Un salto de línea, un array anidado, una colisión de ids: cada uno permitía saltarse las reglas. Ahora leo cada formato de entrada preguntándome «¿qué hace el parser con la versión rara?».
• Conocer los comportamientos por defecto del lenguaje. Que . no coincida con \n está documentado, es antiguo y fácil de olvidar. Los bugs más peligrosos se esconden en lo que todo el mundo «sabe».
• Leer el protocolo, no solo el código. JSON-RPC permite lotes; los ids son propios de cada lado. La especificación me dijo dónde mirar.
• Comunicar de forma responsable, incluso para una línea. Un parche pequeño puede describir una forma de saltarse la seguridad. Decir menos en público y más en privado no cuesta nada.
• Decir lo que tu PR no hace. Cada una de mis PR terminaba con una sección de «límites». Responde a las primeras preguntas del revisor antes de que las haga — y me obliga a ser honesto sobre lo que un test demuestra de verdad.