O repositório não é confiável: controles para agentes na fronteira workspace–runtime

Um agente de código recebe duas coisas ao abrir um projeto: material para compreender e material que pode tentar influenciar seu comportamento. Arquivos, instruções locais, configurações, dependências, links e resultados de ferramentas pertencem ao mesmo workspace, mas não têm a mesma autoridade.

Este Evidence Brief parte de um lote de nove advisories publicado pelo projeto CodeWhale em 16 de julho de 2026 e incorporado ao GitHub Advisory Database em 4 de setembro. O objetivo não é ensinar a explorar as falhas nem avaliar o produto por um único lote. É derivar um contrato técnico para a fronteira entre conteúdo não confiável, política do operador e efeitos produzidos pelo runtime.

Estado: Evidence Brief aprovado para publicação em 07/09/2026 às 09h BRT. Este texto não afirma que os controles propostos estão implantados ou operando na Trustyu Forge.

Escopo factual do caso

A página de advisories do CodeWhale contém nove registros publicados pelo mantenedor em 16/07/2026 que tratam, entre outras fronteiras, de configuração de projeto, aprovação de execução, argumentos de ferramentas, links simbólicos, ambiente do processo e acesso de rede. Os registros correspondentes apareceram no GitHub Advisory Database em 04/09/2026.

O denominador correto é nove advisories naquele lote. Eles não são nove incidentes, nove explorações ativas ou nove organizações afetadas. A página do projeto também lista quatro registros anteriores, de maio; o lote não representa todo o histórico.

As severidades divergem entre as superfícies. No banco global do GitHub, um registro está classificado como crítico e oito como altos. No repositório, o lote aparece como um crítico, sete altos e um moderado. A diferença deve permanecer atribuída a cada ficha; ela não altera o padrão arquitetural compartilhado.

Para os pacotes atuais codewhale-tui e codewhale, as fichas globais registram como afetadas as versões a partir de 0.8.41 e anteriores a 0.8.64, indicando 0.8.64 como primeira versão corrigida. Alguns advisories também registram o pacote anterior deepseek-tui, com faixas próprias e correção em 0.8.41. A ação operacional depende do pacote e da versão efetivamente instalados.

Não foi localizada, até o corte, evidência pública de exploração ativa, quantidade de instalações afetadas, incidente confirmado ou impacto financeiro. O próprio projeto publicou os advisories e referências de correção. GitHub, NVD e a página do mantenedor refletem o mesmo conjunto de disclosures e não devem ser contados como corroborações independentes.

Modelo de confiança

O desenho mínimo separa quatro domínios:

política do operador ───────────────┐
                                    ↓
repositório não confiável → mediador de capacidade → sandbox/runtime → efeitos
           │                        │                      │              │
           └──── evidência ─────────┴──── receipts ────────┴── auditoria ─┘

1. Política do operador: identidade, capacidades, egress, dados permitidos e ações que exigem aprovação. É autoridade superior ao workspace.
2. Repositório não confiável: código, configuração, documentação, instruções e dependências são entradas. Podem pedir menos autoridade; não podem conceder mais.
3. Mediador de capacidade: valida intenção e consequência no ponto da ação, resolve o alvo real e aplica política de forma central.
4. Sandbox/runtime: contém processo, filesystem, rede, recursos e tempo. Falha fechada e produz evidência independente do texto do modelo.

O erro de composição aparece quando uma camada trata entrada como autoridade. Um arquivo do projeto pode informar que testes usam determinado comando. Não deveria habilitar shell. Um caminho pode parecer interno ao workspace. Não deveria decidir sozinho o destino real de leitura ou escrita.

Invariante 1 — configuração é monotônica

Configuração monotônica significa que uma camada de menor confiança só consegue manter ou reduzir a autoridade recebida.

capabilities_effective = intersect(
  organization_policy,
  user_policy,
  session_policy,
  repository_restrictions
)

repository_restrictions participa como restrição, nunca como concessão. Um projeto pode declarar “sem rede” ou “somente leitura”. Não pode trocar shell=false por shell=true, substituir uma lista de instruções controlada pelo usuário ou adicionar destinos de egress.

O commit associado ao lote aplica esse princípio a uma fronteira do CodeWhale: overlays do projeto podem apertar o acesso a shell, mas não habilitá-lo nem substituir listas de instruções do usuário. O commit é evidência da correção descrita; não prova auditoria completa do runtime.

Testes negativos

• um projeto pede capacidade ausente e o resultado efetivo continua negado;
• uma configuração troca lista controlada por lista local e o carregamento falha fechado;
• a mesma política é testada por CLI, interface e automação sem rota alternativa;
• o receipt registra política solicitada, política efetiva e motivo da diferença.

Invariante 2 — aprovação acompanha a consequência

Uma ação não deve ser aprovada apenas pelo nome da ferramenta ou por sua primeira chamada. Se uma sessão existente pode receber nova entrada, se um processo pode executar código ou se uma ferramenta equivalente produz o mesmo efeito, todas essas rotas precisam atravessar o mesmo mediador.

O lote inclui registros sobre interação com shell e avaliação de código sem a confirmação esperada: GHSA-g29h-pfmp-qp9r e GHSA-wrj3-vj8c-784f.

O contrato de aprovação deveria vincular:

• identidade do solicitante e do aprovador;
• classe de efeito, não apenas nome da ferramenta;
• alvo resolvido e escopo;
• argumentos normalizados;
• janela de validade;
• digest da política e do pedido;
• resultado executado ou bloqueado.

Uma aprovação não deve valer para “qualquer comando futuro” numa sessão. Reutilização só é segura quando a política descreve explicitamente a classe de efeito e o limite que permanece válido.

Invariante 3 — confinamento usa o alvo real

O lote inclui advisories sobre argumentos de ferramentas Git e resolução de links no workspace: GHSA-c6mw-8xh8-gpq6, GHSA-7j5w-7r7x-9v27 e GHSA-w7wx-5q49-r59w.

Validar a string antes de executar não basta. O mediador precisa trabalhar com argumentos tipados, resolver o destino real sob uma raiz permitida e rejeitar mudanças entre validação e uso.

Um contrato defensivo inclui:

1. API tipada por operação, sem concatenar texto em comando genérico;
2. allowlist de flags e parâmetros por ferramenta;
3. descritor de arquivo ou mecanismo equivalente ligado ao alvo já resolvido;
4. recusa de links ou montagens que escapem da raiz autorizada;
5. distinção explícita entre leitura, escrita, criação, substituição e execução;
6. log do alvo lógico e do alvo efetivo, sem registrar conteúdo sensível.

Testes negativos

• argumentos desconhecidos ou ambíguos são recusados;
• um link que resolve fora da raiz não pode ser lido nem enviado ao modelo;
• o alvo não pode ser trocado entre verificação e operação;
• operações somente leitura não possuem rota de escrita colateral;
• arquivos fora do escopo permanecem inacessíveis mesmo quando o processo possui acesso no host.

Invariante 4 — o ambiente começa vazio

GHSA-h539-c7r8-3xq4 registra exposição do ambiente pai ao contexto do modelo em uma rota de execução. A defesa mais robusta é construir o ambiente do processo filho a partir de uma allowlist mínima.

child_env = {
  runtime_path,
  locale,
  task_scoped_token,
  explicit_non_secret_parameters
}

O token, quando indispensável, deve ser efêmero, limitado por audiência, operação, tenant e tempo. Um segredo não se torna seguro porque foi removido do prompt; se o processo ou uma ferramenta consegue imprimi-lo, ele ainda pode alcançar o contexto.

Testes negativos

• variáveis não allowlisted não aparecem no processo filho nem nos resultados de ferramenta;
• logs e receipts registram nomes de capacidades, não valores secretos;
• um token de tarefa não autoriza recurso, tenant ou operação fora do escopo;
• a ausência de credencial produz falha explícita, sem fallback para a identidade do operador.

Invariante 5 — egress é aplicado na conexão

GHSA-6v2g-fpxh-pmmh descreve uma condição de tempo relacionada a validação de DNS em proteção contra SSRF. O padrão geral é não depender apenas de uma checagem prévia da URL.

Uma camada de egress deve:

• resolver nomes em componente controlado;
• bloquear destinos locais, privados, metadata e faixas não permitidas;
• revalidar redirecionamentos e o destino efetivo;
• limitar protocolos, portas, volume, tempo e quantidade de respostas;
• preferir allowlist de serviços ou proxy dedicado em tarefas de maior risco;
• registrar decisão de política e destino sanitizado.

O objetivo não é ensinar uma sequência ofensiva. É garantir que a política sobreviva às diferenças entre nome solicitado, resolução e conexão realizada.

Invariante 6 — instrução não vira autoridade

GHSA-62f5-cp2p-vq95 e GHSA-gx45-xrj5-g6c4 tratam de configuração do projeto influenciando instruções ou acesso a shell. O harness precisa preservar proveniência e precedência:

O runtime deve marcar a origem de cada instrução e recusar colisões que tentem promover conteúdo de menor confiança. O harness durável mantém histórico, política de orquestração e isolamento de execução como fronteiras explícitas, sem transformar modelo ou canal em fronteira de segurança. [HARNESS31-C2]

Evidence Packet mínimo por ação

{
  "task_id": "opaque-id",
  "policy_digest": "sha256:...",
  "repository_digest": "sha256:...",
  "requested_capability": "typed-capability",
  "effective_scope": "bounded-scope",
  "approval_ref": null,
  "runtime_identity": "ephemeral-principal",
  "result": "allowed|blocked|failed|inconclusive",
  "artifact_refs": ["immutable-receipt"]
}

O receipt não deve conter segredo, dado pessoal desnecessário ou conteúdo integral do repositório. Ele precisa permitir que outra pessoa reconstrua qual política foi aplicada a qual versão e qual efeito foi autorizado.

Gate antes de liberar um agente de código

1. A origem do repositório está classificada?
2. A política efetiva é monotônica e demonstrável?
3. Shell, filesystem, rede e integrações usam uma identidade efêmera e mínima?
4. Toda ação com consequência equivalente passa pelo mesmo mediador?
5. Caminhos e argumentos são resolvidos e tipados antes do efeito?
6. O ambiente do processo nasce de allowlist?
7. Egress é aplicado no destino efetivo e em cada redirecionamento?
8. Testes negativos exercitam bypasses de configuração, aprovação, caminho, ambiente e rede?
9. Falha, bloqueio, inconclusão e sucesso são estados distintos?
10. Um Evidence Packet liga política, entrada, ação, resultado e autoridade?

Passar nesse gate demonstra apenas o recorte testado. Não prova segurança total, prontidão de produção ou operação contínua.

Limitações e risco de interpretação

• O conjunto descreve um produto e versões específicas; a arquitetura proposta é uma generalização profissional, não conclusão dos advisories.
• As fontes derivadas repetem o mesmo disclosure e não medem prevalência ou exploração.
• Severidades divergem entre superfícies e podem mudar após nova revisão.
• Atualizar para a versão corrigida é uma ação específica; adotar todos os controles acima exige threat model e teste no ambiente da organização.
• Este brief evita provas de conceito, comandos, alvos sensíveis e caminhos ofensivos.
• Nenhum controle aqui é declarado como já implantado, ensaiado ou operando na Trustyu Forge.

Fontes diretas

1. CodeWhale — advisories do projeto.
2. GHSA-6v2g-fpxh-pmmh / CVE-2026-75856.
3. GHSA-g29h-pfmp-qp9r / CVE-2026-75857.
4. GHSA-wrj3-vj8c-784f / CVE-2026-75858.
5. GHSA-62f5-cp2p-vq95 / CVE-2026-75859.
6. GHSA-gx45-xrj5-g6c4 / CVE-2026-75911.
7. GHSA-c6mw-8xh8-gpq6 / CVE-2026-75912.
8. GHSA-7j5w-7r7x-9v27 / CVE-2026-75913.
9. GHSA-w7wx-5q49-r59w / CVE-2026-75914.
10. GHSA-h539-c7r8-3xq4 / CVE-2026-75915.
11. Commit 4356335 — projeto restringe overlays locais.
12. NVD — CVE-2026-75859. Registro derivado do disclosure, não confirmação independente de exploração.

Nota editorial e de responsabilidade

Este texto combina fatos atribuídos a advisories públicos com análise e proposta técnica do autor. Pontos de vista pessoais e profissionais não são fatos comprovados; dados, denominadores, limites e conflitos são indicados quando disponíveis. Não constitui acusação de negligência nem afirma que houve incidente, exploração ou dano. O conteúdo é informativo e não substitui avaliação técnica, jurídica ou de segurança. Tech Human e Trustyu atuam comercialmente em temas relacionados. Pesquisa, estrutura e redação tiveram assistência de IA; revisão factual, aprovação autoral e aprovação de publicação foram confirmadas por Fernando Parreiras em 06/09/2026, sem revisão humana independente adicional.

Corte da pesquisa: 06/09/2026. Estado editorial: publicação especial autorizada para 07/09/2026 às 09h BRT.