Capítulo 12 — Controle de Acesso e Identidade

Décimo segundo post do passeio capítulo a capítulo pelo LLM Primer VII: Segurança de IA. O capítulo que responde à pergunta composicional — quem pode invocar qual capacidade de uma aplicação integrada a LLM, e como a imposição é estruturada entre os componentes do sistema.

Por que este capítulo existe

As disciplinas tradicionais de controle de acesso se aplicam a sistemas LLM: autenticar o principal, autorizar as requisições contra a política, isolar tenants, limitar consumo por principal, expor camadas de governança corporativa. Os mecanismos são os que o campo usa há décadas — OAuth 2.0, mTLS, RBAC, ABAC, token buckets, SAML, SCIM. O que é novo é que a própria chamada do modelo pode virar principal — um agente agindo em nome de um usuário carrega sua própria identidade e suas próprias permissões — e que configuração de comportamento do modelo por tenant é feature de produto de primeira classe para plataformas LLM multi-tenant.

12.1 Autenticação e autorização se transferem, com adições

A autenticação verifica a credencial. API keys são o mecanismo mais simples — uma string de alta entropia entregue ao principal no provisionamento, hasheada no banco de credenciais, apresentada num header em cada requisição. São fáceis de implementar e usar, e fáceis de vazar por logs, saídas de CI e repositórios commitados. Bearer tokens do OAuth 2.0 melhoram a situação com tokens de vida curta e restrição de escopo; o rascunho OAuth 2.1 consolida as melhores práticas de segurança da última década. mTLS acrescenta autenticação mútua para chamadas máquina a máquina, particularmente útil para serviços LLM internos. A autorização pergunta o que o principal autenticado tem permissão para fazer. RBAC — papéis, permissões, atribuições — funciona quando a população se divide em grupos estáveis. ABAC — controle de acesso baseado em atributos — avalia predicados sobre atributos de principal, recurso e contexto e cobre os casos que o RBAC não cobre: permissões que dependem do dono do recurso, do horário ou local da requisição ou de relações no sistema. Os dois não são mutuamente exclusivos; sistemas em produção frequentemente os empilham, com RBAC para acesso de granulação grossa e ABAC para as condições específicas. Motores de política do Capítulo 10 — OPA, Cedar — são como ABAC se torna manutenível em escala.

12.2 Isolamento multi-tenant é questão de defesa em profundidade

Um sistema multi-tenant atende múltiplos clientes a partir de um único deployment. O requisito de isolamento é que nenhum tenant possa ver dados, requisições ou interações de modelo de outro tenant sob qualquer modo de falha. Três abordagens arquiteturais ficam num espectro. Isolamento em nível de banco — banco separado por tenant — é o mais forte mas o mais caro de operar. Isolamento em nível de schema — schema PostgreSQL separado ou banco MySQL por tenant em infraestrutura compartilhada — é meio-termo. Isolamento em nível de linha — schema compartilhado, tenant ID em cada linha, row-level security imposto pelo banco — é o mais barato mas exige código de aplicação disciplinado. Para sistemas LLM o isolamento se estende ao corpus de recuperação (namespaces de vector database por tenant), à lógica de construção de prompt (sem concatenação cross-tenant), ao armazenamento de log (sem leituras cross-tenant) e ao próprio modelo quando ele é fine-tunado com dados específicos do tenant. Rate limits e quotas adicionam o eixo de consumo de recursos. Token bucket permite bursts curtos até uma capacidade definida; sliding window impõe uma taxa mais uniforme a custo computacional maior; leaky bucket suaviza a taxa a jusante. Para sistemas LLM a dimensão de rate limit se expande: requisições por segundo, tokens por minuto, custo por dia, invocações de ferramenta por hora, embeddings por segundo. Cada dimensão tem sua própria justificativa econômica e de segurança, e tiers corporativos geralmente discriminam ao longo de várias.

12.3 Governança corporativa é a camada que torna o sistema utilizável

Clientes corporativos têm requisitos de governança além de autenticação e rate limiting. Precisam saber quais empregados usam o sistema, com quais dados, para quais propósitos. Precisam de audit logs suficientes para compliance interna e auditoria externa. Precisam de controles sobre quais modelos são permitidos, quais ferramentas estão disponíveis, quais categorias de conteúdo são permitidas. Precisam de compromissos de manejo de dados — uso em treinamento, criptografia, residência, retenção, deleção. As features que se tornaram padrão refletem esses requisitos. Single sign-on via SAML ou OpenID Connect faz do provedor de identidade corporativo a fonte de verdade sobre quem pode usar o sistema. Provisionamento SCIM propaga mudanças de usuário automaticamente. Exportação de audit log envia a telemetria do sistema LLM ao SIEM corporativo. Compromissos de residência de dados garantem que os dados de um tenant não deixem uma jurisdição especificada. Chaves de criptografia gerenciadas pelo cliente permitem à empresa girar ou revogar independentemente do provedor. Opções de deployment privado movem o serviço LLM para a própria conta cloud da empresa. Cada uma dessas features é uma superfície de governança que precisa ser operada, não só implementada; a camada de governança corporativa é o que transforma uma plataforma LLM multi-tenant em algo que uma indústria regulada pode adotar.

O que o Capítulo 12 prepara

A Parte IV desenvolveu as dimensões em nível de sistema da segurança LLM: fronteiras arquiteturais (Capítulo 10), observabilidade e resposta a incidentes (Capítulo 11) e controles de identidade e acesso (Capítulo 12). O tratamento foi centrado em mecanismo, e dá uma postura técnica defensável. O Capítulo 13 abre a Parte V movendo-se do núcleo técnico para o perímetro regulatório. O AI Act da UE, em vigor pleno desde agosto de 2026 para a maioria das categorias de alto risco, é o instrumento único mais consequente, mas a postura federal dos EUA (evoluindo após a transição EO 14110 para EO 14179), as leis estaduais (Colorado, Califórnia, Cidade de Nova York e outras), o GDPR aplicado à IA e os frameworks emergentes em Singapura, Japão, Coreia, Índia e outros lugares fazem coletivamente a superfície de compliance ser plural em vez de unificada. O capítulo examina o que essas regulações exigem em termos práticos e como os controles dos Capítulos 3, 10, 11 e 12 mapeiam nesses requisitos.

Próximo — Capítulo 13: Panorama Regulatório. A aplicabilidade em fases do AI Act da UE, GDPR contra sistemas de IA, auditabilidade, model cards e os frameworks de classificação de risco que estruturam a arquitetura regulatória.