Oito Bits por Repositório: o Orçamento de Revelação do GitHub Next para Agentes entre Repositórios

Um repositório confidencial dá a um agente que trabalha entre repositórios 8 bits por execução. Um repositório selado dá zero. Esse é o desenho que o GitHub Next descreve em Limit what agents learn about private repos with enclaves, um recurso que a própria página marca como experimental. Ele trata o vazamento entre repositórios como um problema de contabilidade. O limite vale sem que o agente precise reconhecer um ataque, porque toda resposta precisa caber em um esquema e em um orçamento.

Cobrimos o GitLost, o caminho que o post diz que os enclaves bloqueiam, em A Guarda do GitHub Perdeu para Uma Palavra. Este texto trata da classe de controle que responde a ele.

A tabela de orçamento

Cada repositório tem um nível de sensibilidade. O nível define quantos bits um agente pode aprender daquele repositório em uma única execução:

Nível	Orçamento por execução
Confiável (trusted)	Sem medição
Público	Sem medição
Interno	64 bits
Confidencial	8 bits
Selado	0 bits

Esses números são parâmetros de projeto, e o post não os apresenta como medições. São pequenos, e o exemplo do próprio post mostra o quanto: dos 8 bits confidenciais, só 3 acabam pagando a resposta em si.

Um broker confiável fica entre o agente e o repositório privado e aplica o orçamento. O agente faz uma pergunta. O broker devolve resposta apenas se ela couber em um esquema finito, uma lista fixa de valores possíveis declarada com antecedência. O esquema finito torna a resposta contável, e uma resposta contável torna o orçamento possível.

Como uma pergunta recebe preço

O post desenvolve um exemplo. Uma pergunta tem três valores possíveis de compatibilidade e dois valores possíveis de migração. Isso dá 6 respostas possíveis, que precisam de 3 bits para serem codificadas. Toda resposta paga ainda duas cobranças fixas: um bit reservado para sucesso ou erro e quatro bits para tempo. Três mais um mais quatro dá 8, exatamente o orçamento confidencial.

As cobranças fixas merecem a maior atenção. Saber se uma chamada falhou carrega informação. Saber quanto tempo ela levou também. Os autores cobram pelas duas coisas, então um código de erro ou uma resposta lenta é debitado como qualquer outra resposta.

Mais duas regras fecham os atalhos óbvios:

• A cobrança é reservada antes da execução. O broker cobra pelo esquema logo de início, antes que qualquer consulta toque o repositório.
• O livro-razão é compartilhado entre enclaves de script e enclaves de agente, e uma mudança de esquema não recarrega o orçamento. Trocar o formato da pergunta deixa o medidor onde estava.

A pré-cobrança pesa mais do que parece. Um filtro que inspeciona a saída depois do fato já está com o segredo na mão quando decide. Um broker que reserva a cobrança antes da execução fixa o máximo revelável antes que qualquer resposta exista.

O que o orçamento elimina

O post descreve o efeito sem rodeios: “This blocks the unrestricted private-file-to-public-comment path demonstrated by GitLost without requiring either agent to recognize the attack.” Em tradução livre, o desenho bloqueia o caminho irrestrito de arquivo privado para comentário público demonstrado pelo GitLost, sem exigir que qualquer um dos agentes reconheça o ataque.

Essa frase tira o julgamento de dentro do modelo. Quem mantém o repositório define o nível, o broker conta, e a conta decide. Se uma instrução injetada manda o agente copiar um arquivo privado para um comentário público, o agente pode tentar. O que volta do broker é uma resposta tirada de um esquema pequeno o bastante para caber no orçamento, e um arquivo privado não cabe em 8 bits.

Pare de Endurecer o Sandbox. Tire a Credencial de Dentro do Agente. faz um movimento parecido com segredos: um broker no caminho, para que a segurança deixe de depender do comportamento do agente. Os enclaves aplicam esse movimento à informação. Também estendem o padrão de contenção do que um agente pode tocar para o que um agente pode aprender.

Para um time de governança, a propriedade útil está no lugar onde a necessidade de saber passa a morar. Antes era uma frase em um documento de política. Aqui vira um número preso a um repositório, definido por quem é dono dele e aplicado por um broker fora do modelo.

Os limites, nas palavras do próprio post

Os autores dizem com clareza o que o orçamento deixa de fazer. Quem pensa em adotar a ideia deveria ler estas linhas antes da tabela de níveis.

“These are per-run budgets.” Os orçamentos valem por execução. Sozinho, um limite por execução nada diz sobre o total que um agente aprende ao longo de muitas execuções. Quantas vezes um fluxo pode rodar contra um repositório confidencial é uma decisão separada, e alguém precisa tomá-la.

“Agent enclaves necessarily send repository-derived content to the configured model provider.” Os enclaves de agente enviam conteúdo derivado do repositório ao provedor de modelo configurado. O orçamento limita o que o agente solicitante aprende. O conteúdo ainda chega ao provedor por trás do enclave de agente, então contratos e termos de dados com esse provedor continuam fazendo parte do conjunto de controles.

“A disclosure budget is not a guarantee of harmless disclosure. Even one bit can answer a sensitive question.” Um orçamento de revelação não garante revelação inofensiva, e um único bit pode responder a uma pergunta sensível. Imagine uma pergunta de sim ou não, como saber se o nome de um certo cliente aparece em um repositório. Um bit responde. Quem escreve o esquema decide quais perguntas podem ser feitas, e um esquema descuidado pode gastar um orçamento minúsculo em uma resposta danosa.

O post resume a garantia em uma linha: “The guarantee is a bound on communication, not a judgment that every possible question or answer is safe.” A garantia é um limite sobre a comunicação. Se o conteúdo é seguro de revelar continua sendo uma decisão humana.

Onde o custo cai

Orçamentos tão pequenos remodelam o trabalho entre repositórios. Pense em um fluxo hipotético cujas perguntas têm todas o preço do exemplo, 8 bits cada. Um repositório interno, com 64 bits, permitiria cerca de oito perguntas dessas por execução. Um repositório confidencial permitiria uma. As perguntas precisam virar verificações estreitas e enumeráveis, e a navegação aberta por um repositório confidencial fica fora do que o modelo permite.

A atribuição de nível vira uma decisão de governança com dono nomeado. Alguém diz quais repositórios são confidenciais e quais são selados. Alguém revisa os esquemas, porque um esquema passa a ser a definição do que pode ser perguntado. As duas tarefas cabem melhor com as pessoas que são donas dos dados.

O rótulo experimental indica que o padrão é o que vale adotar hoje. Broker, esquema finito, pré-cobrança e livro-razão compartilhado podem ser construídos em uma plataforma interna de agentes, independentemente de quando ou se esta implementação chegar ao uso geral.

Faça isto agora

Liste os agentes que já trabalham entre repositórios e cada repositório privado que cada um consegue ler. Marque cada repositório com um nível: sem medição, interno, confidencial ou selado. Qualquer agente que lê um repositório confidencial e também escreve em uma superfície pública é o caminho do GitLost que o post diz que os enclaves bloqueiam. Para esses agentes, coloque no caminho um broker que só responde a partir de um esquema declarado, cobra por erro e tempo além do conteúdo, cobra antes da execução e mantém um livro-razão que mudanças de esquema não zeram. Depois registre quantas execuções por dia cada um desses fluxos recebe, porque um orçamento por execução deixa esse número com você.

---

Fontes

• GitHub Next. “Limit what agents learn about private repos with enclaves.” 2026.

A Victorino ajuda times de engenharia a desenhar brokers e orçamentos de revelação para agentes que trabalham entre repositórios privados: contato@victorino.com.br | www.victorino.com.br