Segurança e permissões do GitHub

Exatamente o que o GitHub App do Latchkey pode ler e alterar, como a infraestrutura de runners é isolada e como funciona a exclusão.

Esta página descreve o que o Latchkey pode e não pode acessar, em termos claros, para que sua revisão de segurança tenha uma resposta direta. Ela cobre quatro coisas: o que o GitHub App lê, quando o Latchkey escreve nos seus repositórios, como a infraestrutura de runners é isolada e como funciona a exclusão de dados.

O que o Latchkey lê, e o que nunca toca#

A fronteira é deliberada: tudo à esquerda existe para alimentar um recurso específico, e nada além disso é solicitado. Metadados de execução e de job são a matéria-prima dos painéis de análise; o YAML de workflow é o que a IA lê para propor otimizações, e o único tipo de arquivo que um PR de otimização edita; metadados de repositório orientam a lista de repositórios no modal de Monitoramento; e o seu plano GitHub alimenta o modelo de custo do lado do GitHub na página de Análise de custos.

Quando o Latchkey escreve nos seus repositórios#

Apenas por meio de pull requests, e apenas em duas situações:

• Você clica em aplicar em uma recomendação de otimização: o Latchkey abre um PR (branch latchkey/optimize-...) alterando o arquivo de workflow.
• A auto-recuperação propõe uma correção durável: um PR de recuperação descrevendo a causa-raiz e a mudança.

Ambos os tipos de PR são pull requests comuns para sua equipe revisar, editar ou fechar. O Latchkey nunca faz push diretamente para suas branches e nunca mescla nada, então se você nunca mesclar um PR do Latchkey, nada no seu repositório muda. Pull requests de forks nunca são tocados. O grupo de runners que o app gerencia é encanamento de CI da organização, não conteúdo de repositório.

Isolamento de runners#

Runners gerenciados executam seu código, então seu modelo de isolamento importa mais do que qualquer outra coisa nesta página. Quatro propriedades trabalham juntas:

• Um job por runner. Todo runner gerenciado executa um único job e é destruído depois; nada persiste entre jobs ou entre clientes. O que quer que um job grave, instale ou quebre desaparece com a máquina.
• Rede privada. Runners vivem em subnets privadas sem IP público e sem acesso de entrada: o runner alcança o exterior para fazer seu trabalho, mas nada na internet pode iniciar uma conexão com ele.
• Padrões de instância reforçados, incluindo proteções obrigatórias de metadados de instância e discos criptografados.
• O registro é just-in-time. Runners novos se registram para exatamente um job com credenciais de uso único, então não há credenciais de runner de longa duração para roubar; uma credencial é gasta assim que seu job é concluído.

A auto-recuperação e seus segredos#

O diagnóstico de auto-recuperação roda localmente no runner, contra a saída do passo que seu job já imprime, então nada novo é exposto: segredos mascarados pelo GitHub Actions permanecem mascarados, e o runner, incluindo tudo o que o diagnóstico viu, é destruído após o job. Correções durante a execução só tocam o runner efêmero; correções duráveis sempre chegam apenas como pull requests para revisão, e pull requests de forks nunca são tocados. O modelo completo está em Auto-recuperação.

Chaves de API e o servidor MCP#

Se você conectar um agente de IA por MCP, a chave de API é a credencial a considerar:

• Escopo somente leitura. As chaves podem ler dados de falha de CI; não podem alterar nada no Latchkey ou no GitHub.
• Com escopo de workspace. O workspace é derivado da própria chave, então uma chave só pode ver os dados do seu próprio workspace.
• Exibida uma vez. A chave completa (começa com lk_live_) é exibida apenas na criação; depois disso a interface mostra um placeholder.
• Revogável. Revogue qualquer chave instantaneamente em Settings, API Keys; chaves revogadas permanecem listadas para auditoria.

Qualquer pessoa que possua uma chave pode ler seus dados de falha de CI, incluindo trechos de log, então trate as chaves como senhas: armazene-as na configuração do seu agente, não em um repositório, e rotacione qualquer chave que possa ter vazado.

Tratamento de dados#

• Os dados são criptografados em trânsito (TLS) e em repouso.
• Dados de análise têm escopo do seu workspace e são isolados por organização: cada workspace tem seu próprio plano, equipe, repositórios e dados, e ser membro de um workspace nunca concede visibilidade sobre outro.
• Os diagnósticos de auto-recuperação trabalham sobre logs de passo dentro do runner; os relatórios de recuperação exibidos no seu painel contêm o diagnóstico e a ação tomada.

Excluindo seus dados#

• Desabilitar um repositório: a ingestão para imediatamente; seus dados são arquivados para fora do seu painel. Reabilitar depois inicia um novo backfill. Veja Gerenciando repositórios.
• Cancelar sua assinatura: o acesso é bloqueado, mas seus dados são retidos para que reassinar os restaure.
• Excluir o workspace (Settings, Account; apenas dono): remove permanentemente repositórios, dados de workflow e recursos de runner gerenciado, e cancela a cobrança.
• Excluir sua conta: remove sua conta Latchkey e os workspaces que você possui. Seus repositórios e workflows do GitHub nunca são afetados por nenhuma dessas ações.