A segurança de aplicações de IA Generativa (GenAI) começa pela definição da fronteira de confiança. Uma fronteira de confiança é a linha onde um operador ou conjunto de políticas diferente pode observar, alterar ou bloquear uma solicitação.
Neste curso, protegemos uma aplicação de GenAI que envia prompts, recupera dados privados, chama ferramentas e retorna saídas. O trabalho de segurança difere do realizado em aplicações tradicionais porque as entradas e saídas do modelo não podem ser separadas de forma confiável das instruções.
Também tratamos a saída do modelo como uma entrada não confiável para qualquer sistema subsequente que a processe ou aja com base nela. Essa premissa isolada previne muitas falhas evitáveis relacionadas à exfiltração de dados e ao uso indevido de ferramentas.
Uma aplicação de GenAI apresenta as mesmas superfícies de ataque básicas que qualquer carga de trabalho web. Ela ainda requer gestão de identidade, segmentação de rede, criptografia, registro de logs e resposta a incidentes.
Uma aplicação de GenAI introduz pontos de exposição adicionais por meio de prompts, contexto de recuperação, argumentos de ferramentas e saídas do modelo. Esses canais podem transportar dados sensíveis, mesmo que o provedor se comprometa a não utilizar as entradas para treinamento.
A primeira etapa na modelagem de ameaças é identificar o ativo e a fronteira que o protege. Em GenAI, os ativos de alto valor mais comuns são textos proprietários, credenciais e capacidades de ferramentas.
A responsabilidade na nuvem varia de acordo com a forma como o modelo é consumido. Um modo de consumo é a decisão operacional que define quem executa o modelo e quem pode acessar seu ambiente de execução.
Podemos agrupar os modos comuns em: chamada de API de modelo hospedado, personalização de modelo gerenciado, desenvolvimento em plataforma de IA gerenciada e auto-hospedagem dos pesos do modelo. Cada passo em direção à auto-hospedagem aumenta o escopo do que devemos proteger diretamente.
Um provedor pode operar o serviço do modelo e, ainda assim, permanecer fora da fronteira de confiança da aplicação. A equipe da aplicação continua responsável pelo tratamento de prompts, filtragem de recuperação, autorização de ferramentas e processamento das saídas.
Agora, podemos examinar como a responsabilidade muda entre esses diferentes modos.
Baseamos o restante do curso em um pequeno conjunto de limites. Cada limite torna-se um ponto para aplicar um controle e, posteriormente, verificar evidências.
Limite de identidade: refere-se a qual entidade (principal) pode chamar uma API e com quais permissões. Esse limite inclui credenciais de carga de trabalho, escopo da sessão e verificações de autorização a cada chamada de ferramenta.
Limite de rede: refere-se a onde o tráfego pode fluir em nível de pacote. Esse limite inclui conectividade privada, restrições de saída (egress) e se um serviço é acessível a partir da internet pública.
Limite de dados: refere-se a quais sistemas de armazenamento e logs podem persistir prompts, contexto recuperado e saídas. Esse limite inclui retenção, controle de acesso e se campos sensíveis são ocultados (redigidos) antes do registro em log.
Limite de artefatos do modelo: refere-se a como arquivos de modelo, adaptadores e contêineres entram nos processos de build e tempo de execução (runtime). Esse limite inclui procedência, integridade e exposição de dependências durante o carregamento e a implantação.
Limite de ferramentas: refere-se a quais ações o modelo pode disparar por meio de conectores, funções ou agentes. Esse limite inclui autorização por ação e limites sobre quais argumentos podem ser enviados a uma ferramenta.
Limite de saída externa (egress): refere-se a quais dados podem ser enviados para terceiros, plugins ou para a internet aberta. Esse limite é crítico porque a exfiltração requer um caminho de saída.
Agora podemos visualizar como prompts, recuperação de dados, ferramentas, logs e tráfego de saída cruzam esses limites.