Capítulo 18 — Arquitetura de segurança
Mapa da aula
Aula 18 publicada. Mapa, exemplo, EX052.
flowchart TD
N0["18.1 Princípios"]
N1["18.2 Fronteiras de confiança"]
N2["18.3 Uma arquitetura de referência para agentes"]
N3["18.4 Registros de decisão de arquitetura"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX052"]
Desenho lógico
flowchart LR
N0["18.1 Princípios"]
N1["18.2 Fronteiras de confiança"]
N2["18.3 Uma arquitetura de referência para agentes"]
N3["18.4 Registros de decisão de arquitetura"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]
[18.1 Princípios]
|
v
[18.2 Fronteiras de confiança]
|
v
[18.3 Uma arquitetura de referência para agentes]
|
v
[18.4 Registros de decisão de arquitetura]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX052]
Objetivos de aprendizagem
Você vai (1) aplicar princípios de arquitetura (menor privilégio, separação de funções, mediação completa, padrões seguros em falha, defesa em profundidade) a sistemas de IA; (2) definir fronteiras de confiança para modelos, dados e ferramentas; (3) projetar uma arquitetura de referência para um agente LLM; e (4) documentar decisões de arquitetura com ameaças e risco residual.
18.1 Princípios
Os princípios clássicos de Saltzer e Schroeder continuam valendo. Menor privilégio: o modelo e suas ferramentas recebem apenas as permissões necessárias. Mediação completa: toda ação é verificada por um ponto de política, todas as vezes. Padrões seguros em falha: negar, a menos que explicitamente permitido. Separação de funções: o componente que propõe uma ação não é o que a aprova. Economia de mecanismo: manter a política pequena o bastante para ser revisada. Esses princípios são anteriores ao aprendizado de máquina, o que é útil: dão aos revisores uma lista de verificação que não depende de como o modelo se comporta. Um modelo pode ser manipulado, mas um ponto de política que verifica cada ação continua valendo seja lá o que o modelo tenha sido persuadido a propor.
18.2 Fronteiras de confiança
Uma fronteira de confiança é onde dados ou controle passam entre partes com níveis de confiança diferentes. Em aplicações com LLM, a fronteira crítica passa dentro do prompt: instruções de sistema (confiáveis), entrada do usuário (parcialmente confiável), conteúdo recuperado ou devolvido por ferramentas (não confiável). Como o modelo não consegue impor essa fronteira de forma confiável, a arquitetura precisa impor as consequências fora do modelo. O modelo vê os três tipos de texto como uma única sequência de tokens. Delimitadores e instruções o ajudam a separá-los, mas um boletim escrito com cuidado ainda pode ser lido como uma instrução. Impor as consequências fora do modelo significa que o serviço de política, as credenciais das ferramentas e a aprovação humana decidem o que de fato acontece, de modo que a confusão do modelo sobre de quem é o texto que ele está lendo não pode, por si só, causar dano.
18.3 Uma arquitetura de referência para agentes
Componentes: (1) um serviço de ingestão que rotula a proveniência; (2) o modelo, que propõe ações; (3) um ponto de decisão de política que verifica cada proposta contra identidade, escopo e regras; (4) adaptadores de ferramentas com credenciais estreitas; (5) aprovação humana para ações de alto impacto; (6) registro em log e monitoramento. Pesquisas sobre consultas estruturadas (Chen et al., arXiv:2402.06363) melhoram a separação que o próprio modelo faz entre instruções e dados, mas não substituem o ponto de política externo. O OWASP LLM06 (agência excessiva) alerta contra funcionalidade, permissões e autonomia excessivas. Cada componente corresponde a um princípio: o ponto de política dá a mediação completa, as credenciais estreitas dão o menor privilégio e a aprovação humana separa propor de aprovar.
18.4 Registros de decisão de arquitetura
Registre cada decisão significativa: contexto, opções consideradas, decisão, consequências, ameaças tratadas e risco residual. Revisores e futuros engenheiros podem então ver por que um controle existe. Sem um registro, um controle que parece inconveniente pode ser removido por alguém que não conhece o ataque que ele previne. Os registros são curtos, geralmente uma página, e guardados junto com o código, para que mudem pela mesma revisão. Quando as condições mudam, como uma nova ferramenta ou uma nova ameaça, o registro é revisitado e um novo o substitui, preservando o histórico. O risco residual é o campo deixado em branco com mais frequência e aquele de que os revisores mais precisam.
18.5 Exemplo resolvido (caso sintético da NRS)
Sam escreveu o ADR-007: "Criação de ordens de serviço pelo Wrench". Opções: (a) o modelo chama a API diretamente; (b) o modelo propõe, a política verifica, o técnico confirma; (c) nenhuma ferramenta, o modelo redige um texto para o técnico copiar. Decisão: (b). Consequências: um clique a mais para os técnicos; instruções injetadas não podem criar ordens sem um humano. Risco residual: técnicos podem aprovar sem ler — mitigado pela exibição do documento de origem de qualquer texto com cara de instrução. A opção (c) era a mais segura, mas abria mão do benefício das ordens estruturadas, enquanto a opção (a) punha um modelo não confiável no controle direto de um sistema privilegiado. O registro mostra por que (b) fica entre as duas.
18.6 Erros e limites
Três erros são comuns: confiar ao modelo a imposição das fronteiras em seu prompt; ferramentas com credenciais amplas "por conveniência"; e decisões sem risco residual registrado. Uma fronteira imposta apenas por instruções no prompt se mantém até que uma entrada esperta a quebre. Credenciais amplas transformam uma única chamada manipulada em acesso a tudo o que a credencial alcança. Decisões registradas sem risco residual dão a impressão de que um problema foi resolvido quando ele foi apenas reduzido. A revisão de arquitetura de Sam pergunta, para cada projeto: onde a fronteira é imposta em código, o que a credencial de cada ferramenta pode fazer e que risco permanece.
Exercícios
- EX052 — Princípios. Aplique três princípios ao pipeline de alertas do TrackEye. Rubrica: 3 = três princípios aplicados concretamente; 2 = dois; 1 = apenas nomeados; 0 = nenhum.
- EX053 — Fronteira. Onde fica a fronteira de confiança dentro do prompt do Wrench, e por que o modelo não consegue impô-la de forma confiável? Rubrica: 3 = entre sistema/usuário e conteúdo recuperado; um único fluxo de tokens, comportamento estatístico; 2 = parcial; 1 = vago; 0 = errado.
- EX054 — ADR. Escreva um ADR curto para acrescentar uma ferramenta de e-mail ao Wrench. Rubrica: 3 = contexto, opções, decisão, consequências, risco residual; 2 = quatro; 1 = dois; 0 = nenhum.
Síntese
A arquitetura é onde a segurança de IA se torna aplicável: fronteiras de confiança, um ponto de política externo, ferramentas com menor privilégio e decisões documentadas transformam a incerteza do modelo em risco limitado.
Continue estudando — capítulo 18 de 50
← Capítulo 17 (rascunho) · Índice de capítulos do curso · Capítulo 19 (rascunho) →