Modele as ameaças de um fluxo de desenvolvimento com IA

Escolha um cenário limitado

Comece com um fluxo de trabalho que as pessoas consigam entender. Por exemplo, um agente lê uma issue, edita um repositório, executa testes e abre um pull request. Inclua os sistemas que tornam essas ações possíveis.

Liste os ativos importantes: código-fonte, informações de clientes, credenciais, artefatos de release e disponibilidade do serviço. Identifique seus responsáveis. Depois, identifique as pessoas e os sistemas que podem ler ou alterar cada ativo.

A OWASP recomenda modelar o sistema, identificar ameaças, escolher respostas e validar o resultado. Use o método desde o início e atualize-o conforme o sistema mudar. Orientações de modelagem de ameaças.

Desenhe os limites de confiança

Para o fluxo fictício de issue a PR, desenhe estas conexões:

Issue → agente → repositório → executor de testes → armazenamento de artefatos → deployment

Acrescente o provedor do modelo e o armazenamento de segredos. Marque onde o conteúdo vem de uma fonte menos confiável. Marque onde uma identidade ganha uma nova capacidade, como passar da leitura de uma issue à escrita de arquivos no repositório.

O diagrama da aplicação, sozinho, não mostra todo o risco do desenvolvimento. Um banco de dados de produção pode ser privado enquanto um job de CI expõe uma credencial. Inclua ambientes temporários e acesso do suporte quando afetarem o cenário.

Escreva um caminho concreto de falha

Evite registros como “a IA pode ser insegura”. Escreva quem age, qual é a ação, o ativo afetado e a consequência. Inclua as condições necessárias para que o cenário ocorra.

Esses são exemplos, não uma lista completa de ameaças. Seus dados, ferramentas e ambiente de operação determinam os cenários relevantes.

Escolha uma resposta com um responsável

Priorize consequências e exposições plausíveis. Evite apresentar uma pontuação numérica como uma precisão que você não tem. Registre a incerteza e as evidências que poderiam mudar a prioridade.

Uma resposta pode remover a capacidade arriscada, reduzir seu escopo, acrescentar um controle ou aceitar um risco residual definido. A aceitação precisa de um responsável autorizado e de um motivo. Não deve ser uma conclusão do agente sem revisão.

Transforme a resposta escolhida em trabalho com uma condição observável de aceitação. “Melhorar a segurança do agente” é difícil de verificar. “O job de teste não pode ler o segredo de produção” define um limite verificável.

Revise após alterações relevantes

Um novo conector, caminho de acesso ao modelo, ambiente ou permissão pode mudar o modelo de ameaças. Inclua essas mudanças nas condições de revisão. Use também incidentes e avaliações que falharam para atualizar premissas.

Experimente o exercício de revisão de riscos para alterar os dados, a autoridade, o público e as condições de recuperação de um cenário. O resultado sugere perguntas. Não substitui um modelo de ameaças específico do sistema nem autoriza o trabalho.