Capítulo 45 — Revisão de projeto independente
Mapa da aula
Aula 45 publicada. Mapa, exemplo, EX133.
flowchart TD
N0["45.1 Independência"]
N1["45.2 Método de revisão"]
N2["45.3 Achados"]
N3["45.4 Recebendo uma revisão"]
N4["45.4b Critérios de gravidade"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX133"]
Desenho lógico
flowchart LR
N0["45.1 Independência"]
N1["45.2 Método de revisão"]
N2["45.3 Achados"]
N3["45.4 Recebendo uma revisão"]
N4["45.4b Critérios de gravidade"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX133"]
[45.1 Independência]
|
v
[45.2 Método de revisão]
|
v
[45.3 Achados]
|
v
[45.4 Recebendo uma revisão]
|
v
[45.4b Critérios de gravidade]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX133]
Objetivos de aprendizagem
Você vai (1) conduzir uma revisão independente de segurança do projeto do sistema de IA de outra equipe; (2) usar checklists estruturados e perguntas guiadas por ameaças; (3) escrever achados com gravidade, evidência e recomendações; e (4) responder profissionalmente a uma revisão do seu próprio projeto.
45.1 Independência
Os revisores não podem ter projetado o sistema. Eles precisam do pacote de projeto, de acesso aos projetistas para tirar dúvidas e de tempo suficiente. A independência revela premissas que os projetistas não conseguem ver. Um projetista lê o projeto sabendo o que se pretendia e preenche lacunas sem perceber. Um revisor lê apenas o que está escrito. Essa diferença encontra premissas como "a recuperação é filtrada em algum lugar" que os projetistas nunca registraram. O acesso aos projetistas também importa, mas perguntas e respostas são registradas, para que a explicação acabe no projeto, e não nas notas do revisor.
45.2 Método de revisão
Combine um checklist com uma exploração guiada por ameaças. Itens do checklist: fronteiras de confiança desenhadas; aplicação de políticas fora do modelo; ferramentas com privilégio mínimo; identidade delegada; proveniência e contaminação; tratamento das saídas; verificação da cadeia de suprimentos; proteção de dados; monitoramento e runbooks; portões de avaliação com conjuntos reservados; projeto da supervisão humana; modos de falha e estados seguros. Guiada por ameaças: percorra os itens do OWASP LLM 2025 e as técnicas pertinentes do MITRE ATLAS contra o projeto e pergunte, para cada um, "o que impede isto, e e se isso falhar?" O checklist garante a cobertura, e o percurso pelas ameaças encontra problemas específicos do projeto.
45.3 Achados
Cada achado: título; gravidade (com critérios); descrição; evidência (diagrama, seção do documento); impacto; recomendação; e status. Separe os achados das observações e das notas positivas. Seja específico o bastante para que os projetistas possam agir. Um achado como "a recuperação pode ser insegura" não dá aos projetistas nada sobre o que agir. "A recuperação usa uma conta de serviço com acesso a todos os depósitos; a filtragem acontece apenas no prompt; um usuário poderia pedir documentos de outro depósito" declara a evidência e o impacto, e a correção vem naturalmente. As notas positivas também importam, porque mostram quais práticas manter quando o projeto mudar.
45.4 Recebendo uma revisão
Agradeça aos revisores, esclareça os mal-entendidos nos documentos de projeto (se um revisor entendeu errado, outros também vão entender), aceite ou conteste os achados com evidências e acompanhe cada achado até o encerramento. Contestar um achado é legítimo quando há evidência que o sustente, por exemplo um teste mostrando que o caminho de ataque do revisor está bloqueado. Acompanhar cada achado até o encerramento, inclusive os contestados, impede que a revisão seja esquecida depois da reunião. Uma tabela de resposta curta, com cada achado, a decisão e a evidência, costuma bastar, e ela vai para o dossiê.
45.4b Critérios de gravidade
Combine os critérios de gravidade antes da revisão. Por exemplo: crítica — um atacante externo pode causar impacto na segurança física ou divulgação em larga escala sem interação do usuário; alta — o impacto exige uma condição plausível; média — impacto limitado ou que exige condições incomuns; baixa — endurecimento. Critérios compartilhados evitam discussões sobre rótulos e permitem comparar achados de revisões diferentes. Aplicado à revisão do Crew Chat feita por Sam, o achado da recuperação é alto, e não crítico: um técnico de um depósito precisa de apenas uma condição plausível, uma pergunta bem formulada, para revelar os documentos de outro depósito, mas o atacante já precisa ser um usuário interno. A falta de escape na saída é média, porque explorá-la exige texto controlado pelo atacante em uma resposta renderizada.
45.5 Exemplo resolvido (caso sintético da NRS)
Sam revisou o projeto "Crew Chat" de outra equipe (um assistente para as equipes de via). Achado alto: a recuperação do assistente usava uma conta de serviço com acesso aos documentos de todos os depósitos, filtrando os resultados apenas no prompt ("responda apenas sobre o seu depósito"). Recomendação: permissões de recuperação por usuário aplicadas na consulta ao banco vetorial. Médio: nenhum escape de saída para uma visualização web. Positivo: excelente rotulagem de proveniência. A equipe corrigiu o achado alto antes do marco seguinte. Filtrar no prompt é um pedido ao modelo, não controle de acesso; uma pergunta bem formulada poderia recuperar e revelar documentos de outro depósito.
45.6 Erros e limites
Três erros são comuns: revisões feitas pelos próprios projetistas; achados vagos, sem evidência; e ignorar revisões inconvenientes. A autorrevisão raramente encontra as premissas que causaram um problema, porque foi a mesma pessoa que as fez. Achados sem evidência são difíceis de pôr em prática e fáceis de descartar. Ignorar uma revisão inconveniente desperdiça o esforço investido nela e deixa o risco no lugar, muitas vezes para ser redescoberto depois, em um incidente. A equipe de Sam manteve cada achado em um rastreador que a banca podia ler. Os itens encerrados continuaram visíveis.
Exercícios
- EX133 — Checklist. Liste oito itens de checklist para a revisão do projeto de um agente LLM. Rubrica: 3 = oito pertinentes; 2 = seis; 1 = três; 0 = nenhum.
- EX134 — Achado. Escreva o achado alto do Crew Chat no formato completo. Rubrica: 3 = todos os campos; 2 = a maioria; 1 = vago; 0 = nenhum.
- EX135 — Filtragem pelo prompt. Por que "responda apenas sobre o seu depósito" no prompt é insuficiente? Rubrica: 3 = o modelo pode ser manipulado; os dados já estão no contexto; a aplicação precisa estar na recuperação; 2 = parcial; 1 = vago; 0 = errado.
Síntese
A revisão independente, com checklists estruturados mais perguntas guiadas por ameaças, produz achados específicos e com evidência, acompanhados até o encerramento.
Continue estudando — capítulo 45 de 50
← Capítulo 44 (rascunho) · Índice de capítulos do curso · Capítulo 46 (rascunho) →