A proteção em que confiamos guardava outra porta

Ler o original em inglês

securitygitverificationagent-safety

Imagem de capa: A proteção em que confiamos guardava outra porta

Nós dois íamos trocar trabalho por um repositório privado compartilhado, cada um com seu próprio assistente de IA, e o plano tinha uma linha sobre acesso que parecia sólida. No fim, ela falava de um sistema completamente diferente.

A linha no manual de regras

A ideia era simples. Em vez de repassar cada atualização à mão, os assistentes passariam o trabalho de um lado para o outro por um repositório privado compartilhado. Antes de qualquer um dos lados mexer nele, uma linha no manual de regras compartilhado descrevia como o acesso funcionaria: uma chave com escopo definido e prazo de validade, emitida por um sistema de controle que já existia, válida para este único espaço compartilhado e para mais nada.

Escrevi essa linha com confiança, porque o sistema de chaves citado era real. Ele já existia e já funcionava para outras coisas. O desenho fazia sentido: as chaves expiram, são limitadas a caminhos específicos, e para emitir uma é preciso uma credencial de nível mais alto. Reaproveitar algo já testado parecia a escolha segura.

O que uma checagem rápida encontrou

Antes de qualquer um dos lados depender daquela promessa, demos uma olhada rápida no que o sistema de chaves realmente faz. Ele concede acesso de leitura a um conjunto de arquivos em uma máquina específica, por uma conexão local privada. Não tinha nenhuma ligação com o repositório compartilhado. Pior: a configuração da outra pessoa rodava em outra máquina e não tinha como alcançar essa conexão privada, com chave ou sem chave.

O mecanismo era real. Ele guardava outra porta.

A porta que importava

A resposta estava disponível o tempo todo, de um jeito bem comum: um convite no nível da plataforma que adiciona uma pessoa específica como colaboradora em exatamente um recurso compartilhado, e em nada mais. Essa fronteira faz o trabalho de “só esta pessoa, só este espaço”. Ninguém precisou construí-la. Só precisávamos enxergá-la como a resposta, em vez de ficar com a opção que já estava escrita.

Corrigimos o manual de regras antes que qualquer um dos lados agisse com base na versão errada. A versão corrigida também ganhou uma regra simples para quando o trabalho das duas pessoas avança ao mesmo tempo: primeiro traga as mudanças do outro lado, combine tudo e nunca sobrescreva o que a outra pessoa fez sem olhar antes.

Proteção real, alvo errado

O sistema de chaves era um controle de acesso legítimo, fazendo exatamente o que foi feito para fazer, só que em outro lugar. O erro foi tratar “esta é uma proteção real e funcionando” como se fosse a mesma afirmação que “esta proteção cuida da coisa que temos diante de nós”. São duas frases diferentes que por acaso soam parecidas.

A checagem levou alguns minutos. Lemos o que o sistema de chaves concede e depois perguntamos se a máquina da outra pessoa conseguia alcançá-lo. Não conseguia. Por isso o manual de regras agora manda enviar um simples convite de colaborador, no lugar de uma regra em que nós dois confiaríamos até a primeira vez que um de nós tentasse usá-la.

Receba a próxima história de IA no dia a dia

Histórias em linguagem simples sobre usar IA para facilitar o trabalho do dia a dia. Um e-mail curto quando sair uma nova, sem jargão.