Ganhos:
- Capacidade de reconhecer superfícies de ataque específicas de IA (injeção imediata, envenenamento de dados, vazamento de dados confidenciais, extração de membros) e projetar defesas em camadas
- Capacidade de aplicar a privacidade como princípio de design: minimização de dados, mascaramento, controle de acesso e período de retenção
- Capacidade de realizar trabalhos de segurança exclusivamente para fins defensivos, divulgar vulnerabilidades de forma responsável e evitar uso não autorizado
Um sistema de aprendizado de máquina carrega todos os riscos de segurança do software tradicional e adiciona novas superfícies de ataque exclusivas. O modelo pode ser enganado por uma entrada, os dados de treinamento podem ser envenenados e informações confidenciais podem vazar para a saída. Nesta unidade, consideramos os sistemas de IA a partir de uma perspectiva de defesa: reconhecendo ataques, fortalecendo o sistema, protegendo a privacidade. Estas informações não são para acesso não autorizado ou ataque, mas para manter seus próprios sistemas seguros.
Superfícies de ataque específicas de IA
Além da segurança clássica (autenticação, autorização, criptografia), os sistemas de ML são vulneráveis a:
- Injeção imediata: a instrução oculta na entrada do LLM perde o modelo. O risco de segurança LLM mais comum e prático.
- Envenenamento de dados: um invasor introduz um backdoor ou preconceito oculto no modelo, inserindo amostras incorretas nos dados de treinamento.
- Inferência e inversão de modelo: um invasor reconstrói dados de treinamento ou comportamento do modelo enviando várias consultas ao modelo.
- Inferência de adesão: inferir se os dados de uma determinada pessoa são usados na educação — uma violação de privacidade.
- Vazamento de dados confidenciais: o modelo revela informações confidenciais (nome, identidade, segredo) nos dados de treinamento na saída.
Existem defesas para cada um destes riscos; A chave é considerar o risco na fase de design.
Injeção imediata: a ameaça mais imediata
Existem dois tipos de injeção imediata:
- Direto: O usuário insere pessoalmente um texto como “ignorar instruções anteriores”.
- Indireto: A instrução incorreta está oculta em um contexto externo (página web, documento, e-mail) que o modelo processa. Particularmente perigoso para agentes e RAG porque o modelo lida com conteúdo externo de forma confiável.
Camadas de defesa:
- Parsing: Separate system instruction and user/external data with clear delimiters; marque o conteúdo externo como "dados, não comandos".
- Potências mínimas: Limite a quantidade de dano que o modelo pode causar mesmo se for capturado (potências do veículo na unidade 5).
- Controle de saída: verifique o que o modelo produz antes de usá-lo — especialmente se isso se traduzir em uma ação.
- Aprovação humana: vincule ações de alto risco à aprovação.
Cuidado: Você não pode resolver completamente a injeção imediata com uma única defesa; É necessária uma defesa em camadas (defesa em profundidade). Suposição crítica: "O modelo pode ser enganado em algum momento; então, qual seria a pior coisa que aconteceria se ele fosse enganado e como posso limitar isso?"
Abordagem fraca/abordagem forte
Fraco: "Eu digitei 'ignorar instruções incorretas' no prompt do sistema e estamos seguros."
Forte: "Envolvemos conteúdo externo com tags <data> e dissemos 'ignorar instruções internas'. Também limitamos as ferramentas do modelo à autorização mínima, vinculamos ações irreversíveis à aprovação humana, registramos todas as chamadas de ferramentas e submetemos a saída a verificações de regras antes do uso. Contamos com camadas, não com uma única defesa."
A diferença: a abordagem forte sabe que uma instrução de uma linha não será suficiente e constrói camadas que limitam os danos.
Privacidade: os dados são protegidos desde o início
A privacidade não é um recurso adicionado posteriormente, é um princípio de design (privacidade desde o design). Aplicações básicas:
- Minimização de dados: Não colete e armazene mais dados pessoais do que o necessário. Dados que não são coletados não podem ser vazados.
- Anonimização e mascaramento: Mascare ou remova identificadores pessoais (nome, ID, e-mail) antes de fornecê-los à modelo.
- Controle de acesso: Limite e registre quem acessa os dados e modelo (controle de acesso RAG na unidade 4).
- Período de retenção: determine por política por quanto tempo você retém os dados; Exclua o expirado.
A privacidade diferencial (uma técnica que evita que os dados de um único indivíduo afetem significativamente a saída, adicionando ruído controlado durante o treinamento) e a aprendizagem federada (uma abordagem que treina em dispositivos sem mover os dados para o centro) são técnicas avançadas de privacidade; devem ser considerados ao trabalhar com dados confidenciais.
Dica: Antes de processar qualquer dado, pergunte: “Se esses dados pessoais vazarem, quem sofrerá quais danos?” Se o dano for grave, não colete os dados ou processe-os mascarando-os. Os dados mais seguros são aqueles que nunca foram coletados.
Dados de treinamento e modelo de segurança da cadeia de suprimentos
Tanto quanto o seu modelo, os componentes que você utiliza também são uma questão de segurança:
- Confiança na fonte de dados: os dados de treinamento são confiáveis ou podem estar envenenados? Audite conjuntos de dados públicos.
- Modelos e bibliotecas de terceiros: um modelo pré-treinado ou uma dependência que você baixou pode ser malicioso. Verifique sua origem, assinatura e vulnerabilidades conhecidas.
- Cadeia de suprimentos: cada ferramenta e pacote em seu pipeline de ML é um elo de confiança; Você está tão seguro quanto o elo mais fraco.
Divulgação responsável e limites éticos
Quando você encontra uma vulnerabilidade — em seu próprio sistema ou no sistema de um fornecedor — o caminho correto é a divulgação responsável: relatar a vulnerabilidade de forma privada à parte relevante e dar-lhe tempo para corrigi-la, não explorá-la ou divulgá-la. Usar inteligência artificial ou informações de segurança que você adquiriu para acesso não autorizado, vazamento de dados ou intervenção não autorizada no sistema de outra pessoa é ilegal e contra a ética profissional. O conteúdo de segurança deste módulo é inteiramente para fins de defesa, detecção e proteção.
três mini cases
Caso 1 – Limitação da injeção indireta. Um bot de suporte RAG estava renderizando o conteúdo da web. Instruções ocultas foram enterradas em uma página. O modelo foi parcialmente enganado, mas o bot não tinha privilégios de gravação (privilégios mínimos) e a saída passou pela verificação de regras antes de ser exibida ao usuário; Acabou sendo prejudicial e foi pego. A defesa em camadas impediu que uma única falha se tornasse um desastre.
Caso 2 – Vazamento de dados confidenciais. Uma equipe de suporte ao cliente ajustada faz login em um modelo sem mascará-los (unidade 6). O modelo começou a gerar nomes reais de clientes em questões irrelevantes. Também havia o risco de remoção de membros. Modelo retirado, dados mascarados, política de retenção corrigida. Lição: dados confidenciais não devem entrar na educação.
Caso 3 - Conjunto de dados venenosos. Uma equipe treinou em um conjunto de dados disponível publicamente sem auditá-lo. Havia amostras venenosas no set que enganaram o modelo quando ele viu uma palavra-gatilho específica (porta dos fundos). Depois de adicionar auditoria e verificação de anomalias, essas amostras foram capturadas. Lição: verifique a fonte de dados, não confie cegamente.
Modelos copiáveis
Check this LLM/agent system for prompt injection.- Are system instructions and user/external data clearly separated?- Is external content marked as "data" or is it handled as a command?- What is the worst that would happen if the model is fooled (authorization limit)?- Are irreversible actions subject to human approval?- Is the output inspected before use?System: [description]. Liste as deficiências defensivas em camadas.
Audite a confidencialidade deste fluxo de processamento de dados.- Cada campo pessoal coletado é realmente necessário (minimização)?- Quais campos devem ser mascarados nos dados que vão para o modelo?- Há controle de acesso e registro?- O período de retenção está definido?Fluxo: [descrição]. Sugira correção para cada deficiência.
Neste texto, encontre os dados pessoais que precisam ser mascarados antes de enviá-los ao modelo. Campos: nome, email, telefone, número de identificação/passaporte, morada, número de cartão, IP. Liste cada descoberta com seu tipo e máscara recomendada. Não substitua o resto do texto.Texto: [texto]
Gere uma lista de verificação de segurança antes de colocar este modelo/biblioteca de terceiros em produção.- A fonte e o editor são confiáveis e a assinatura é verificada?- Verificados em busca de vulnerabilidades conhecidas (CVE)?- De quais privilégios/acesso ele precisa, pode ser minimizado?Componente: [nome/fonte]
Tabela de defesa contra risco
Risco
defesa
camada
injeção imediata
Análise + privilégio mínimo + controle de saída
Design + tempo de execução
envenenamento de dados
Controle de origem + verificação de anomalias
linha de dados
Vazamento de dados confidenciais
Mascaramento + minimização de dados
Dados + treinamento
Extração de membros
Privacidade diferencial
Educação
autoridade excessiva
Autorização mínima + aprovação
projeto de agente
cadeia de abastecimento
Inspeção de componentes + assinatura
vício
Erros comuns
- Pensando que você resolveu a injeção imediata com uma única linha. A defesa em camadas é obrigatória.
- Processar/treinar dados confidenciais sem mascará-los. Infiltra-se permanentemente no modelo.
- Considerar o conteúdo externo confiável. Porta de injeção indireta.
- Não verificando a fonte de dados. O envenenamento passa despercebido.
- Confiar cegamente no componente de terceiros. Lacuna na cadeia de abastecimento.
- Pensando que a privacidade será adicionada mais tarde. Deve começar pelo design.
Em resumo
Além dos riscos clássicos de segurança, os sistemas de IA carregam ameaças únicas, como injeção imediata, envenenamento de dados, vazamento de dados confidenciais e extração de membros. Nenhum deles pode ser resolvido com uma única medida; defesas em camadas (análise, autorização mínima, controle de saída, aprovação humana) necessárias. A privacidade é um princípio de design: minimizar os dados, mascará-los, limitar o acesso, impor períodos de retenção. Controle a cadeia de fornecimento de componentes e dados. Toda esta informação é para defesa, detecção e consolidação; Explique as vulnerabilidades com responsabilidade, nunca explore.
Tarefa de aplicativo
Check an LLM/agent system (your own project or example) for prompt injection: are system instructions and external data separated, what is the authorization limit if the model is tricked, are irreversible actions confirmed? Adicione pelo menos duas camadas de defesa. Separadamente, encontre e mascare quaisquer campos pessoais que precisem ser mascarados em dados de amostra que vão para o modelo. Verifique a origem e as vulnerabilidades conhecidas de qualquer componente de terceiros que você usa.
lista de verificação
- [ ] System instruction and external/user data are clearly separated.
- [] O conteúdo externo é marcado como dados, não como comandos.
- [ ] Mesmo que o modelo seja enganado, o dano é limitado à autoridade mínima.
- [ ] Dados pessoais mascarados/minimizados; período de armazenamento definido.
- [] A fonte de dados e os componentes de terceiros foram verificados.
- [ ] Meu trabalho de segurança é para fins de defesa; Eu explico as lacunas com responsabilidade.