Sobre o projeto

irreversible-command-gate (icg) é um pequeno guardião em Rust destinado a residir no hook de harness de um agente de codificação de IA e capturar o pequeno número de ações que não podem ser desfeitas — excluir um segredo, fazer force-push sobre o histórico, imprimir uma credencial na transcrição, purgar um volume Docker — enquanto todas as outras chamadas de ferramenta passam intactas. Ele se conecta ao hook PreToolUse de um harness: um documento JSON na entrada, um envelope de decisão na saída. A documentação do projeto o descreve como um respaldo para um agente honesto, porém falível, em vez de uma fronteira de segurança contra um agente hostil. Como funciona. Uma chamada de ferramenta é despachada para pacotes de regras por palavra-chave da ferramenta. Padrões seguros são testados primeiro e interrompem o processo; entre os padrões guardados, a primeira correspondência vence. Essa ordenação é o que mantém o trabalho comum de apenas leitura silencioso, pois uma regra só dispara se a entrada não for reivindicada por nenhum padrão seguro. O mecanismo é determinístico e não realiza E/S de rede. Ele falha aberto por design: um diretório de pacotes vazio, uma ferramenta não reconhecida ou uma verificação travada permitem o comando, sob o raciocínio de que uma violação perdida é recuperável, enquanto uma frota de agentes travada não é. O README relata um custo de verificação mediano de aproximadamente 10 ms em um cache quente e observa que existe uma política graduada de falha fechada para uso assim que um release se provar estável. Quatro vereditos, um por canal de redirecionamento que uma regra pode declarar, e apenas o deny realmente interrompe o comando: allow (nenhuma regra correspondeu, ou um padrão seguro correspondeu primeiro), warning (allow mais contexto adicional quando a regra não consegue decidir com confiabilidade suficiente para bloquear), rewrite (allow mais entrada atualizada, para que o harness tente novamente com uma forma segura da mesma intenção) e deny (o motivo traz a alternativa de curso de ação). O que é entregue. Os pacotes publicados incluem openbao (kv destroy, metadata delete, exclusão de mount e policy, operator rekey, literais de segredos em argv, leituras de segredos para stdout), git (preenchimento de credenciais nuas, force push reescrito para um push simples, commits sem um pathspec, pushing sobre um remote head obsoleto), secrets (tokens GitHub e PATs, chaves AWS, tokens Slack, chaves Anthropic, blocos de chave privada PEM, correspondidos em comandos e no conteúdo de arquivos), docker (system prune --all, volume rm, image rm --force), image-tag, storage-class, além de beads, misc, tmux e argocd-topology, que codificam convenções locais da frota. A documentação marca cada pacote como geral ou específico da frota e nomeia cada id de regra. O andaime de pacotes é fornecido através de um comando new-pack que escreve um pacote e seu teste de regressão juntos, e um release gate constrói um corpus de regressão de deny para reportar regras que pararam de cobrir o que cobriam anteriormente. Instalação e uso. O binário pode ser compilado a partir do código-fonte apenas com um toolchain Rust, ou obtido como um asset de release. Um script de instalação coloca o binário e os pacotes sob propriedade do root e registra o hook; ele prova deliberadamente a aplicação enviando um comando sabidamente destrutivo através do hook e recusando-se a reportar sucesso a menos que o comando retorne como denied, pois uma instalação incompleta se comportaria exatamente como uma funcional. Opções de dry-run e desinstalação estão disponíveis. O comando check voltado para o humano sempre sai com zero, portanto, sua saída, e não seu status, é o que deve ser analisado. Limitações declaradas. O README é explícito que o icg não defende contra prompt injection ou um repositório malicioso, não sabe quem está chamando (sem identidade, TTY ou verificação de privilégio), não alcança sessões de agentes hospedadas na nuvem como ChatGPT web, tarefas de nuvem do Codex ou claude.ai, e não cobre mutações de kubectl, arquivos de workflow ou objetos Kubernetes Job e CronJob, que são deixados para a aplicação de políticas separada no nível da organização. Uma variável de ambiente pode desativar o guardião; ele é auditado em vez de restringido, portanto, um agente pode configurá-la tão facilmente quanto um usuário. A transição do trust-pointer no fluxo de atualização não foi exercitada de ponta a ponta e é descrita como não comprovada. Status. O README afirma que o mecanismo, os pacotes, ambos os front-ends (hook e wrapper de PATH), a maquinaria de integridade de release e 526 testes aprovados em 52 arquivos estão funcionando, em um crate de cerca de 25.800 linhas de Rust com 17 dependências e sem requisito de toolchain C. Nomeia v0.1.4 como o release atual e descreve v0.1.3 como o release de onde atualizar, pois fechou um bypass de guarda no qual um apóstrofo no corpo de um heredoc fazia o lexer perder o restante do comando. O repositório é um espelho de leitura apenas, licenciado sob MIT, de uma instância git auto-hospedada.