Capítulo 28 — Segurança de IA e aprendizado de máquina: implementação I
Mapa da aula
Aula 28 publicada. Mapa, exemplo, EX082.
flowchart TD
N0["28.1 Ponto de aplicação de políticas"]
N1["28.2 Rótulos de proveniência"]
N2["28.3 Validação de saída e varredura de segredos"]
N3["28.4 Testando a implementação"]
N4["28.6b Falha segura no ponto de aplicação"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX082"]
Desenho lógico
flowchart LR
N0["28.1 Ponto de aplicação de políticas"]
N1["28.2 Rótulos de proveniência"]
N2["28.3 Validação de saída e varredura de segredos"]
N3["28.4 Testando a implementação"]
N4["28.6b Falha segura no ponto de aplicação"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX082"]
[28.1 Ponto de aplicação de políticas]
|
v
[28.2 Rótulos de proveniência]
|
v
[28.3 Validação de saída e varredura de segredos]
|
v
[28.4 Testando a implementação]
|
v
[28.6b Falha segura no ponto de aplicação]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX082]
Objetivos de aprendizagem
Você vai (1) implementar um ponto de aplicação de políticas para ações propostas pelo modelo; (2) implementar rótulos de proveniência nos prompts; (3) implementar validação de saída e varredura de segredos; e (4) testar a implementação com testes unitários, de propriedades e adversariais.
28.1 Ponto de aplicação de políticas
O modelo emite uma proposta (nome da ferramenta e argumentos em um esquema). O ponto de aplicação valida o esquema, verifica a ferramenta contra o papel do usuário, verifica os argumentos contra o escopo (depósito, ativo), verifica se os argumentos estão contaminados por conteúdo não confiável e decide: permitir, exigir confirmação ou negar. As decisões são registradas em log com os motivos.
ROLE_TOOLS = {"technician": {"search", "create_work_order"}, "viewer": {"search"}}
def decide(role, tool, args, tainted):
if tool not in ROLE_TOOLS.get(role, set()):
return "deny: tool not allowed for role"
if tool == "create_work_order":
return "confirm: tainted arguments" if tainted else "confirm: high impact"
return "allow"
for case in [("viewer", "create_work_order", {}, False), ("technician", "search", {}, True),
("technician", "create_work_order", {"asset": "AX12"}, True)]:
print(case[:2], "->", decide(*case))
Ele imprime deny, allow e confirm: tainted arguments para os três casos. A ordem das verificações importa: primeiro o papel, de modo que o pedido de um visualizador é recusado antes que qualquer outra coisa seja examinada, depois o impacto e a contaminação. Uma busca de técnico com argumentos contaminados é permitida, porque a busca não altera nada, enquanto toda ordem de serviço precisa de confirmação, e a contaminada diz por quê.
28.2 Rótulos de proveniência
Ao montar um prompt, envolva cada trecho recuperado com sua fonte e seu nível de confiança, e declare nas instruções de sistema que o conteúdo rotulado como não confiável é dado. Isso ajuda o modelo, mas não é uma fronteira de segurança; o ponto de aplicação continua sendo a autoridade. Um invólucro típico diz: '[source: supplier bulletin SB-2291, trust: external] … [end source]'. Os rótulos melhoram o comportamento do modelo em média e dão contexto aos técnicos quando revisam uma proposta, já que a tela de confirmação pode mostrar quais fontes rotuladas a influenciaram. Mas um atacante pode escrever um texto que imita um rótulo ou manda o modelo desconsiderá-lo, e é por isso que o rótulo informa e o ponto de aplicação decide.
28.3 Validação de saída e varredura de segredos
Valide saídas estruturadas com analisadores estritos. Varra as saídas em texto livre em busca de segredos (padrões de chaves de API, nomes de hosts internos) e de dados pessoais antes de exibi-las ou enviá-las. Faça o escape das saídas antes de renderizá-las em páginas web para evitar injeção de scripts (OWASP LLM05). Um analisador estrito rejeita qualquer coisa fora da estrutura esperada, em vez de adivinhar o que se quis dizer. A varredura de segredos usa os mesmos padrões dos repositórios de código e acrescenta nomes internos que nunca deveriam sair da organização. O escape importa porque um modelo pode ser induzido a emitir tags de script ou links, e uma interface de chat que os renderizasse executaria o código de um atacante no navegador de um técnico.
28.4 Testando a implementação
Testes unitários cobrem cada regra; testes de propriedades geram propostas aleatórias e verificam invariantes; testes adversariais reproduzem de ponta a ponta um corpus de documentos injetados e verificam que nenhuma ação proibida é executada. Os três tipos pegam falhas diferentes. Testes unitários mostram que cada regra faz o que diz. Testes de propriedades encontram combinações em que ninguém pensou, como uma string de papel vazia. A reprodução de ponta a ponta verifica o caminho inteiro, incluindo adaptadores e logging, que é onde se escondem os bugs de ordenação. O corpus de reprodução cresce a cada novo padrão de ataque encontrado, e um caso acrescentado nunca é removido, para que fraquezas antigas não voltem em silêncio.
28.5 Exemplo resolvido (caso sintético da NRS)
Sam implementou o ponto de aplicação como um serviço separado, com 140 linhas de código de política e 60 testes. Uma reprodução adversarial de 600 boletins injetados sintéticos produziu 41 propostas de ordens de serviço do modelo; todas as 41 foram encaminhadas para confirmação com a marca de contaminação, e nenhuma foi executada automaticamente. Quarenta e uma propostas em 600 são cerca de 6,8%, bem acima dos 2% que o requisito permite para propostas, então a reprodução também gerou um achado para a equipe de prompts. O ponto de aplicação fez o seu trabalho: as propostas excedentes chegaram à tela de confirmação de um técnico marcadas como contaminadas, e nada foi executado. Os 60 testes fazem parte do build, de modo que qualquer mudança no código de política precisa passar por eles antes da liberação.
28.6 Erros e limites
Três erros são comuns: a aplicação de políticas dentro do prompt do modelo; renderizar a saída do modelo como HTML sem escape; e testes que só cobrem o caminho feliz. Regras declaradas apenas no prompt são sugestões ao modelo, não aplicação. Saída sem escape transforma a janela de chat em uma superfície de ataque para injeção de scripts. Testes do caminho feliz confirmam que as ações permitidas funcionam, mas nunca mostram que as proibidas são recusadas. O teste de falha segura descrito a seguir é um exemplo dos testes negativos de que toda regra do ponto de aplicação precisa, junto com a reprodução de documentos injetados.
28.6b Falha segura no ponto de aplicação
Se o ponto de aplicação de políticas do Wrench não consegue carregar suas regras nem alcançar seu serviço de decisão, ele recusa a ação de ferramenta solicitada e diz ao técnico por quê, em vez de permiti-la. A NRS testa esse caminho em toda versão iniciando o serviço com um arquivo de política ausente. O teste importa porque a falha oposta é silenciosa: um ponto de aplicação que permite ações quando seu arquivo de política está ausente parece saudável em todos os testes funcionais. Na reprodução de 600 boletins de Sam, todas as 41 propostas de ordens de serviço chegaram à tela de confirmação de um técnico; com um serviço de falha aberta e nenhuma política carregada, as mesmas 41 teriam virado ordens de serviço sem que ninguém as verificasse.
Exercícios
- EX082 — Decisão. O que
decide("viewer", "search", {}, True)devolve e por quê? Rubrica: 3 = "allow"; busca permitida para o visualizador; aqui a contaminação só importa para a ferramenta de alto impacto; 2 = só o valor; 1 = errado, mas fundamentado; 0 = nenhum. - EX083 — Limites dos rótulos. Por que rótulos de proveniência no prompt não são uma fronteira de segurança? Rubrica: 3 = o modelo ainda pode seguir texto injetado; a aplicação precisa ser externa; 2 = parcial; 1 = vago; 0 = errado.
- EX084 — Reprodução adversarial. Descreva o teste adversarial de ponta a ponta e seu critério de aprovação. Rubrica: 3 = reproduzir o corpus injetado pelo sistema completo; aprovação = zero execuções não autorizadas, todas as propostas contaminadas confirmadas; 2 = parcial; 1 = vago; 0 = nenhum.
Síntese
A implementação torna a arquitetura real: um ponto de aplicação pequeno e testado, proveniência rotulada, tratamento estrito das saídas e testes de reprodução adversarial.
Continue estudando — capítulo 28 de 50
← Capítulo 27 (rascunho) · Índice de capítulos do curso · Capítulo 29 (rascunho) →