Capítulo 10 — Projetando Arquiteturas LLM Seguras

Décimo post do passeio capítulo a capítulo pelo LLM Primer VII: Segurança de IA. O capítulo que trata arquitetura como a disciplina primária de segurança — porque a configuração mais segura de um componente probabilístico é aquela cujo raio de destruição é limitado por estrutura, não pela contenção do próprio componente.

Por que este capítulo existe

Os capítulos das Partes I a III nomearam as ameaças e as defesas do lado do modelo. O Capítulo 10 percorre a arquitetura ao redor do modelo — as fronteiras de isolamento, tiers de validação, motores de política, contratos de API e princípios zero-trust que dão ao sistema suas propriedades estruturais. A premissa não muda em relação a eras anteriores da engenharia de segurança: assuma comprometimento, contenha o dano, torne o comprometimento legível. O que é novo é que o componente a conter é um orquestrador guiado por linguagem natural cujas instruções podem chegar por qualquer canal de entrada. Os padrões arquiteturais se transferem de eras anteriores; as especificidades de como eles se aplicam a LLMs é onde este capítulo faz seu trabalho.

Em uma linha: um modelo que foi instruído por um atacante através de uma entrada injetada vai tentar executar essas instruções usando as capacidades que o sistema ao redor expõe — logo, é a arquitetura, não o modelo, que determina o teto de qualquer comprometimento bem-sucedido.

10.1 Isolamento limita o raio de destruição

Uma fronteira de isolamento é uma costura deliberada através da qual um componente de um lado não pode afetar diretamente um componente do outro sem passar por uma interface controlada. A razão de segurança para o isolamento é que o dano de um comprometimento é limitado pelo que o componente comprometido conseguia alcançar por suas interfaces legítimas. Para sistemas LLM, a pergunta de isolamento mais importante é entre o modelo e todo o resto ao qual o sistema tem acesso. Um modelo rodando em um processo com acesso irrestrito ao filesystem, acesso irrestrito à rede e uma ferramenta de execução de shell sem allow-list tem um raio de destruição grande. Um modelo cujo processo roda em um sandbox com um conjunto definido de syscalls, cujo acesso de rede passa por um proxy de saída com allow-listing em nível de domínio, cujas ferramentas são invocadas por meio de capability tokens que o código ao redor emite por requisição, tem um raio muito menor. O padrão se estende a execução de código — ferramentas de sandbox como as que OpenAI e Anthropic usam nos seus ambientes de code interpreter rodam código gerado em VMs efêmeras gVisor ou Firecracker — e à navegação, em que browsers headless rodam em namespaces de rede isolados sem acesso a endpoints internos. Isolamento é decisão de design feita antes de qualquer ataque específico, e é o investimento em segurança mais barato por unidade de redução de raio de destruição que o campo oferece.

10.2 Validação é em camadas, política é declarativa

Um único ponto de validação é um único ponto de falha. Endpoints de LLM em produção geralmente compõem cinco camadas entre a requisição do cliente e a resposta. A autenticação verifica a credencial do principal. A validação da requisição confere a requisição contra o schema da API — tipos, faixas, comprimentos, character sets. A avaliação de política pergunta se o principal autenticado, a requisição validada e o estado atual do sistema permitem essa ação. A chamada do modelo roda com o system prompt, a entrada do usuário validada, a lista de ferramentas escopada pelo que a política permite e as restrições de saída. A filtragem de saída confere a resposta contra conteúdo que não deveria ser retornado — segredos vazados, conteúdo proibido, chamadas de ferramenta inseguras — antes de enviá-la. A lógica de política cresce com o tempo e, se espalhada por código de aplicação, vira a união de muitas condicionais difícil de inspecionar, testar ou evoluir. O campo convergiu em separar política de código. Open Policy Agent (OPA), projeto da CNCF, avalia políticas escritas em Rego. AWS Cedar, lançado em 2023, é uma linguagem de autorização mais focada com propriedades de verificação formal. Os dois estão prontos para produção; a escolha costuma ser alinhamento organizacional. Políticas se tornam artefatos versionados e revisáveis, e a política de segurança efetiva do sistema fica sempre legível num só lugar.

10.3 Zero-trust aplicado a chamadas de modelo

A API é o contrato entre o sistema LLM e seus consumidores. Design seguro de API é a disciplina de moldar o contrato para que seus invariantes sobrevivam ao contato com consumidores adversariais. Schemas de entrada explícitos — tipos estritos, faixas, enumerações em allow-list — custam pouco e limitam a confiança implícita que a API dá ao consumidor. Respostas de erro estruturadas que não vazam estado interno evitam a coleta de inteligência que erros vagos habilitam. Chaves de idempotência, IDs de requisição e versionamento dão ao sistema observabilidade sobre o comportamento do consumidor sem exigir estado extra. O modelo zero-trust, articulado no paper BeyondCorp do Google de 2014 e formalizado na NIST SP 800-207 em 2020, estende o princípio: nenhum consumidor é confiável em virtude da localização de rede. Toda requisição autentica, é autorizada contra política explícita, é avaliada contra dispositivo e contexto e é logada. Aplicado a sistemas LLM, a própria chamada do modelo vira um principal — uma requisição do modelo para uma ferramenta a jusante autentica como o modelo, carrega a identidade do humano em cujo nome o modelo está operando e é autorizada contra política que conhece as duas identidades. Capability tokens com escopo estreito e TTL curto são o que torna isso composicional. O resultado é que um prompt comprometido não consegue escalar para comprometimento pleno do sistema porque as próprias capacidades do modelo são limitadas por tokens que o código ao redor emitiu para uma requisição específica.

Vale a pena guardar: não peça ao modelo para policiar a si mesmo. Toda capacidade que o modelo pode invocar deveria ser mediada por código fora do modelo que verifique a invocação contra política, e a política deveria ser expressa de forma declarativa para que sua evolução seja revisável. A cooperação do modelo não faz parte do perímetro de segurança.

O que o Capítulo 10 prepara

Estrutura sem visibilidade falha de forma invisível. O Capítulo 11 examina a camada de observabilidade que transforma defesas arquiteturais em sistema operável — o que logar quando um LLM está no loop, como estruturar telemetria para servir alerting em tempo real, investigação a posteriori, planejamento de capacidade, compliance e avaliação contínua a partir dos mesmos registros. As convenções semânticas OpenTelemetry GenAI, que começaram a padronizar spans e atributos específicos de LLM em 2024, fornecem a fundação vendor-neutral. Implementações específicas — Langfuse, Helicone, Arize Phoenix, Datadog LLM Observability — sentam em cima com trade-offs diferentes. O Capítulo 12 trata então da dimensão de identidade e acesso — OAuth, mTLS, RBAC versus ABAC, isolamento multi-tenant, rate limits e os controles de governança corporativa que tornam o sistema utilizável em ambientes regulados.

Próximo — Capítulo 11: Observabilidade, Logging e Resposta a Incidentes. O que logar com as convenções OpenTelemetry GenAI, como detectar padrões de abuso e como conduzir uma resposta a incidentes no formato NIST para um sistema cujas falhas são probabilísticas.

Quer o panorama completo? O capítulo do livro inclui políticas OPA trabalhadas para autorização de ferramentas, padrões de emissão de capability token, a adaptação completa de BeyondCorp até NIST 800-207 zero-trust para chamadas de LLM e os quadros In Plain English que este artigo apenas resume. Veja o LLM Primer VII na Amazon →