Plugin opencode-policy Adiciona 309 Regras para Proteger Agentes de IA contra Injeções e Vazamentos

Um novo plugin opencode-policy fornece uma camada de proteção antes do modelo e das ferramentas. Inclui 309 regras: 27 contra prompt injection e 282 para chamadas de ferramentas perigosas, incluindo tentativas de ler arquivos .env, extrair variáveis de ambiente, codificar dados via base64 e executar comandos shell suspeitos. A ideia é simples: bloquear o risco antecipadamente antes que o agente execute qualquer coisa.

Processado por IA de Habr AI; editado por Hamidun News
Plugin opencode-policy Adiciona 309 Regras para Proteger Agentes de IA contra Injeções e Vazamentos
Fonte: Habr AI. Colagem: Hamidun News.
Ouvir artigo

Para o ambiente opencode, foi proposto um nível protetor separado que intercepta solicitações perigosas antes que cheguem ao modelo ou sejam passadas para ferramentas de shell e arquivo. O plugin opencode-policy usa regras determinísticas, não apenas prompts do sistema, e cobre cenários típicos de ataque em agentes de IA: injeção de prompt, leitura de arquivos não autorizados, tentativas de extrair variáveis de ambiente, preparação de exfiltração de dados e execução de comandos suspeitos. A versão base inclui 309 regras que podem ser estendidas para sua infraestrutura.

A ideia surgiu da experiência com competições de agentes de IA, onde os participantes recebiam deliberadamente instruções maliciosas. Em tais tarefas, agentes poderiam ser solicitados a esquecer regras anteriores, mostrar o prompt do sistema, ler .env, ~/.

ssh ou /proc/self/environ, decodificar payloads e executar algo em nome do usuário. É por isso que o autor do plugin colocou a proteção fora do próprio modelo: se um comando perigoso já chegou à execução da ferramenta, é tarde demais para reagir. O filtro é posicionado mais cedo e verifica tanto mensagens do usuário quanto argumentos de ferramentas.

A integração no opencode é construída em dois hooks. O primeiro transforma mensagens antes de enviar ao modelo e procura sinais de injeção de prompt em campos de texto, incluindo text, prompt, command e source.value.

O segundo é ativado antes da execução da ferramenta e analisa não apenas o caminho do arquivo, mas também o nome da ferramenta, comando shell, texto da solicitação e outros argumentos. Se uma regra corresponder, a solicitação não vai adiante: para o modelo é substituída por uma recusa segura, e a execução da ferramenta simplesmente para com um erro de política. Essa abordagem torna o comportamento previsível e conveniente para auditoria.

Atualmente o plugin tem 282 regras para chamadas de ferramentas e 27 regras contra injeção de prompt. Elas são armazenadas em JSON e funcionam como um conjunto de políticas regex. Assinaturas típicas caem sob bloqueio, como "ignore previous instructions," tags falsas [developer] e [system], comandos printenv e echo $TOKEN, referências a /run/secrets e /proc/self/environ, bem como tentativas de codificar dados via base64, xxd ou openssl enc.

Cada acionamento é registrado em um log JSONL com timestamp, tipo de evento e identificador de regra. Isso ajuda a investigar incidentes, encontrar falsos positivos e adicionar rapidamente novos padrões com base em ataques reais. O lado prático também parece maximamente pragmático.

O plugin é instalado com um único comando npm install opencode-policy e conectado via config opencode, após o qual mensagens e chamadas de ferramentas são automaticamente executadas através da camada de regras antes da execução. O autor enfatiza particularmente que o conjunto de políticas é aberto e pode ser estendido para sua infraestrutura específica, e a abordagem em si é compatível com modelos locais se funcionarem através do opencode. Isso torna a solução útil não apenas para assistentes em nuvem, mas também para loops de agentes internos dentro de empresas.

É particularmente importante que o autor conscientemente confie em mecanismos simples e transparentes em vez de mais uma camada de LLM sobre LLM. Para algumas ameaças, semântica complexa realmente não é necessária: nomes de arquivos secretos, comandos de saída de ambiente e templates de solicitação jailbreak são bastante específicos. A abordagem regex é mais simples de revisar, atualizar e vincular a casos específicos, e após um incidente, uma nova regra pode ser adicionada literalmente ponto a ponto.

Este design conservador é especialmente útil onde reprodutibilidade e testes determinísticos são necessários, não avaliação probabilística de risco. Tal filtro por si só não substitui sandbox, restrições de privilégio, whitelists de ferramentas e isolamento de rede. Mas para sistemas de agentes trabalhando com código, shell, CI/CD, repositórios internos e secrets, fecha uma camada importante de defesa inicial.

O valor principal aqui está na previsibilidade: regras são legíveis por humanos, fáceis de revisar e testar, e a proteção não depende de qual modelo está sob o capô. Diante do crescimento de agentes de IA autônomos, isso parece não como uma opção adicional, mas como uma higiene básica para produção.

História
ZK
Zhemal Khamidun — CPO da Alpina Digital, gerente de produto do AlpinaGPT. Cria produtos de IA desde 2019. O Hamidun News é um projeto pessoal que virou um agregador em produção com mais de 6.000 leitores.
✦ Hands-On AI Engineering · Hamidun Academy

Build & Ship Production AI Agents Without Boilerplate Code

Start your free 72-hour trial at Hamidun Academy (academy.hamidun.com) — interactive lessons on Claude Code & Cursor, live Tech Radar, and production agent templates.

Start 72h Free Trial →Vibe-Coding Intensive
O que você acha?
Carregando comentários…