irreversible-command-gate

irreversible-command-gate (icg) es un pequeño guardián en Rust diseñado para situarse en el hook del arnés de un agente de codificación de IA y capturar el puñado de acciones que no se pueden deshacer —eliminar un secreto, hacer un force-push sobre el historial, imprimir una credencial en la transcripción, purgar un volumen de Docker— mientras que todas las demás llamadas a herramientas pasan intactas. Se conecta al hook PreToolUse de un arnés: entra un documento JSON y sale un sobre de decisión. La documentación del proyecto lo describe como un respaldo para un agente honesto pero falible, en lugar de una barrera de seguridad contra uno hostil. Cómo funciona. Una llamada a una herramienta se despacha a los paquetes de reglas mediante una palabra clave de la herramienta. Primero se prueban los patrones seguros y estos cortocircuitan; entre los patrones custodiados, gana la primera coincidencia. Ese orden es lo que mantiene silencioso el trabajo ordinario de solo lectura, ya que una regla solo se activa si ninguna entrada fue reclamada por un patrón seguro. El motor es determinista y no realiza E/S de red. Por diseño, falla en modo abierto: un directorio de paquetes vacío, una herramienta no reconocida o una comprobación fallida permiten el comando, bajo el razonamiento de que una violación omitida es recuperable, mientras que una flota de agentes bloqueada no lo es. El README reporta un coste de comprobación medio de aproximadamente 10 ms con una caché caliente, y señala que existe una política gradual de fallo cerrado para usarse una vez que una versión haya demostrado su eficacia. Cuatro veredictos, uno por cada canal de redireccionamiento que una regla puede declarar, y solo deny detiene realmente el comando: allow (ninguna regla coincidió, o un patrón seguro coincidió primero), warning (allow más contexto adicional cuando la regla no puede decidir con suficiente fiabilidad para bloquear), rewrite (allow más entrada actualizada, para que el arnés reintente con una forma segura de la misma intención) y deny (el motivo indica la alternativa a seguir). Lo que incluye. Los paquetes publicados incluyen openbao (kv destroy, metadata delete, eliminación de montajes y políticas, operator rekey, literales de secretos en argv, lecturas de secretos a stdout), git (relleno de credenciales bare, force push reescrito a un push simple, commits sin un pathspec, pushing sobre un remote head obsoleto), secrets (tokens de GitHub y PATs, claves de AWS, tokens de Slack, claves de Anthropic, bloques de claves privadas PEM, detectados en comandos y en contenido de archivos), docker (system prune --all, volume rm, image rm --force), image-tag, storage-class, además de beads, misc, tmux y argocd-topology, que codifican convenciones locales de la flota. La documentación marca cada paquete como general o específico de la flota y nombra cada id de regla. El andamiaje de paquetes se proporciona a través de un comando new-pack que escribe un paquete y su prueba de regresión juntos, y una puerta de lanzamiento construye un corpus de regresión de denegación para informar sobre las reglas que dejaron de cubrir lo que solían cubrir. Instalación y uso. El binario puede compilarse desde el código fuente solo con una cadena de herramientas de Rust, o descargarse como un activo de lanzamiento. Un script de instalación coloca el binario y los paquetes propiedad del root y registra el hook; demuestra deliberadamente la aplicación enviando un comando destructivo conocido a través del hook y negándose a informar el éxito a menos que el comando regrese denegado, ya que una instalación a medio terminar se comportaría exactamente igual que una funcionando. Hay opciones de dry-run y desinstalación disponibles. El comando de comprobación orientado al humano siempre sale con cero, por lo que su salida, y no su estado, es lo que debe analizarse. Limitaciones declaradas. El README es explícito en que icg no defiende contra la inyección de prompts ni contra un repositorio malicioso, no sabe quién está llamando (sin comprobación de identidad, TTY o privilegios), no llega a sesiones de agentes alojadas en la nube como ChatGPT web, tareas de Codex cloud o claude.ai, y no cubre mutaciones de kubectl, archivos de flujo de trabajo u objetos Kubernetes Job y CronJob, que se dejan a la aplicación a nivel de organización. Una variable de entorno puede desactivar el guardián; este es auditado en lugar de restringido, por lo que un agente puede configurarlo tan fácilmente como un usuario. La transición del puntero de confianza del flujo de actualización no se ha ejercitado de extremo a extremo y se describe como no probada. Estado. El README establece que el motor, los paquetes, ambos front-ends (hook y envoltorio de PATH), la maquinaria de integridad de lanzamiento y 526 pruebas superadas en 52 archivos están funcionando, en un crate de unas 25,800 líneas de Rust con 17 dependencias y sin requerimiento de cadena de herramientas de C. Nombra la v0.1.4 como la versión actual y describe la v0.1.3 como la versión desde la cual actualizar, ya que cerró un bypass del guardián en el que un apóstrofe en el cuerpo de un heredoc causaba que el lexer perdiera el resto del comando. El repositorio es un espejo de solo lectura con licencia MIT de una instancia de git autoalojada.