Filosofia e Inteligência Artificial
IA como alvo
Modelos e sistemas de IA podem ser explorados ou comprometidos, como alvos em sofisticados ataques cibernéticos. Este é um risco de segurança importante.
Imagem gerada com apoio de IA.
Quando a própria IA é o alvo de ataques adversariais
Como discutido em IA e Cybersecurity, a relação entre a IA e a segurança cibernética é interessante, e pelo que entendo, tem 3 dimensões. Primeiro, a IA pode ser utilizada para ajudar a DEFESA cibernética. Segundo, a IA pode ser utilizada para apoiar ATAQUES cibernéticos. Terceiro, a própria IA (modelos e sistemas de IA) podem ser alvos de ataques adversariais.
Nesta página, estamos interessados neste terceiro contexto - onde a própria IA é o alvo de ataques.
Como veremos, há diferentes tipos de ataques adversariais que podem comprometer modelos e aplicações de IA, O aprendizado de máquina (Machine Learning) traz novos desafios, alguns difíceis de prever e evitar. Estes novos desafios não substituem, mas se somam aos riscos já tradicionais para a privacidade e segurança da informação que requerem medidas já conhecidas como autenticação, controle de acesso e proteção de infraestruturas. Ou seja, a IA traz novos problemas de segurança que precisam ser gerenciados. Para isso, o primeiro passo é criar conscientização (awareness) sobre quais são estes novos vetores de ataque, para que em seguida bons processos de trabalho e novas ferramentas e técnicas possam ser selecionadas.
Crédito da imagem: Adversarial Robustness Toolbox (ART) v1.11
O CID da IA
Os sistemas de Machine Learning podem apresentar vulnerabilidades que permitem que hackers e outros agentes (por exemplo, equipes estatais ou militares de cybersecurity) violem a integridade, a confidencialidade e/ou a disponibilidade do sistema.
No contexto da segurança da IA:
-
Integridade significa garantir que o modelo produza saídas corretas e não seja manipulado para cometer erros. No aprendizado de máquina (Machine Learning). Por exemplo, ataques adversariais podem inserir pequenas perturbações nos dados de entrada (Adversarial Examples) para induzir o modelo a erros sistemáticos, como alterar alguns pixels de uma imagem para que um sistema de reconhecimento classifique um “cachorro” como “lobo”.
-
Confidencialidade significa proteger informações sensíveis, seja do modelo, seja dos dados usados para treiná-lo. Ataques do tipo Inversão de Modelo (Model Inversion) permitem recuperar dados pessoais a partir das saídas do modelo, enquanto ataques do tipo Inferência de Pertencimento (Membership Inference) permitem identificar se um dado específico fez parte do treinamento. Assim, por exemplo, atacantes podem conseguir extrair registros médicos a partir de um chatbot treinado com dados de pacientes, violando sua confidencialidade.
-
Disponibilidade significa garantir que o sistema de IA permaneça acessível e operacional. Para isso, é preciso protegê-lo de diferentes tipos de ataques de negação de serviço (DoS/DDoS) contra APIs de IA, ou de sobrecarga proposital do modelo, através do envio proposital de consultas massivas a um modelo de linguagem para torná-lo indisponível.
Em função da dimensão CID mais afetada, os ataques contra sistemas de IA podem ser agrupados em diferentes categorias.
Categorias de ataques contra a IA
Por motivos metodológicos (para facilitar a discussão e alinhamento com as dimensões do CID discutidas acima), vou classificar os diferentes tipos de ataques contra os sistemas de IA em 3 categorias, que são normalmente utilizadas na literatura especializada:
Ataques Informacionais → violam confidencialidade.
-
Model inversion
-
Membership inference
-
Model stealing
Ataques de Manipulação de Comportamento → violam integridade.
-
Data poisoning
-
Adversarial examples
-
Prompt injection
Ataques de Interrupção/Exaustão de Recursos → violam disponibilidade.
-
DoS/DDoS contra APIs
-
Resource exhaustion (consultas massivas)
Classificação por superfície de ataque
Uma outra classificação que pode ser aplicada em paralelo e é adotada em alguns frameworks de segurança para a IA (relacionada com a superfície de ataque) é se o ataque é esencialmente voltado contra o modelo, contra o sistema (ou aplicação) que consome o modelo, ou ambos.
Essa classificação também é útil porque permite entender onde o ataque atua e, portanto, quais controles são mais relevantes. É complementar à taxonomia por tipo de objetivo CID (informacional, manipulação, indisponibilidade).
Imagem gerada com apoio de IA.
Considerando esta abordagem para classificar os ataques, teríamos três alvos possíveis:
1. Ataques contra o modelo
Nestes ataques (Model Level Attacks), o foco principal é um modelo de IA (pesos, arquitetura, dados de treinamento etc.).
Estes ataques em geral não exigem comprometer a aplicação que hospeda ou utiliza o modelo. Os alvos podem ser por exemplo um modelo de linguagem (LLM) ou um classificador de imagens. Os riscos incluem vazamento de informações privadas, comportamentos imprevisíveis, descrédito do sistema (ataques reputacionais) e outros. Alguns ataques podem ocorrer durante o treinamento, outros podem afetar modelos já em produção. Os atacantes podem ser internos (pessoas com acesso na infraestrutura de treinamento) ou externos interagindo diretamente com a IA através de APIs.
Como exemplos de ataques típicos em nível de modelo podemos citar Model Stealing, Model Inversion, Membership Inference Attack, Data Poisoning, Adversarial Examples e Neural Trojan Attacks. A mitigação típica envolve defesas adversariais, privacidade diferencial, controle de acesso aos pesos, monitoramento de inputs e outros controles.
2. Ataques contra sistemas
Outros ataques são direcionados aos sistemas ou aplicações de IA (System-level Attacks) que hospedam ou consomem os modelos. Como exemplos, temos os ataques de negação de serviços (DoS/DDoS) e o abuso de permissões de execução no sistema que consome um modelo de IA. Neste caso os vetores de ataque podem incluir toda a arquitetura de uso do sistema com IA (por exemplo, redes, servidores e APIs), incluindo a exploração de integrações do sistema de IA com sistemas externos de terceiros.
Para mitigar os riscos destes ataques, é necessário combinar controles tradicionais de cibersegurança corporativa (rede, servidores, APIs) com medidas de segurança específicas para contextos de IA, como a filtragem e sanitização de entradas, a implementação de AI Firewalls (Guard Models), limitação de exposição das APIs etc.
3. Ataques híbridos
Muitas vezes o atacante combina vetores contra o modelo e contra a infraestrutura do sistema que o hospeda. Estes são os ataques híbridos. Nesta categoria, podemos destacar os ataques de Prompt Injection (é em essência um ataque em nível de modelo, mas se houver integração do modelo com aplicações ou ferramentas, o que é comum, torna-se híbrido), e também os IA Worms, malwares autônomos baseados em IA que conseguem se replicar nos ambientes corporativos explorando tanto falhas nos modelos (ex.: Prompt Injection) quanto em sistemas integrados (APIs, serviços externos, permissões). Os AI Worms diferem dos worms tradicionais porque não dependem apenas de exploits binários ou de rede, eles usam a linguagem natural (por exemplo, textos de e-mail) e automação via LLMs para se espalhar.
Esse ponto é importante porque mostra que controles isolados (aplicados só no modelo ou só no sistema) não são suficientes.
A tabela 1 resume alguns exemplos de ataques contra a IA e suas classificações quanto ao CID e à superfície de ataque.
Tabela gerada com apoio do ChatGPT-5
Vale ressaltar que a tabela não é exaustiva. Existem outros tipos de ataques que poderiam ser adicionados, mas foram omitidos em favor da simplicidade, tais como:
-
Ataques de Evasão ou Evasion Attacks - Ataque de modificação de comportamento, direcionado aos modelos de IA, onde o atacante cria entradas que evitam ou “enganam” filtros de detecção (ex.: malware adaptado para passar por um detector de malware).
-
Backdoor Attacks (pode ser tratado com Neural Trojan, mas alguns consideram como um conceito separado). Ataque de modificação de comportamento, direcionado aos modelos de IA, onde um gatilho específico é inserido durante o treinamento, e quando acionado, é capaz de produzir alterações na saída do modelo.
-
Data Extraction via Query Optimization - Ataque informacional, direcionado aos modelos de IA, onde o atacante utiliza consultas otimizadas para extrair grandes blocos de conhecimento memorizado, incluindo dados sensíveis. É um ataque cada vez mais presente com LLMs, onde dados de treino podem “vazar” por meio de prompt engineering refinado.
-
Fine-tuning Hijacking - Ataque de modificação de comportamento, direcionado aos modelos de IA, que visa introduzir comportamentos maliciosos durante um ajuste fino de modelo, usando datasets envenenados. O risco é maior em modelos de pesos abertos (open source), quando usuários enviam dados para fine-tuning em plataformas de terceiros.
-
Supply Chain Attacks - Este ataque pode ser de modificação de comportamento ou informacional (dependendo do caso), sendo direcionado aos modelos de IA. Envolve comprometer modelos públicos ou bibliotecas de Machine Learning antes da implantação, por exemplo, inserir código malicioso em modelos pré-treinados distribuídos publicamente. O risco é maior quando há dependência de repositórios externos (HuggingFace, GitHub, etc.).
Pesos dos modelos - um alvo desejado
Um alvo desejado dos atacantes são os pesos dos modelos de IA (model weights). Os pesos são valores numéricos que conectam os neurônios entre as diversas camadas de uma rede neural. Durante o treinamento do modelo, esses valores vão sendo ajustados automaticamente para minimizar o erro entre a saída prevista e a saída real.
Os pesos são centrais para a capacidade de um modelo de IA em fazer predições ou tomar decisões. De certa forma, eles representam a memória e o conhecimento do modelo, armazenando de forma distribuída tudo o que o modelo "aprendeu" durante o treinamento, a partir de milhões ou bilhões de exemplos. Por isso são tão valiosos para os atacantes.
Imagem gerada com apoio de IA.
Por exemplo, se você pede ao ChatGPT para completar a frase...
"O céu está cheio de...“
O assistente vai prever a próxima palavra (mais precisamente, o próximo token) que melhor completaria a sentença.
Imagem capturada pelo autor
São os pesos que determinam como cada parte dessa entrada (Prompt) deve ser interpretada — qual informações são mais relevantes, como elas se combinam, quais padrões foram reconhecidos no passado etc. Na prática, os pesos controlam quais palavras seriam mais prováveis como resposta (por exemplo: "estrelas", "nuvens", "balões") com base em tudo que o modelo aprendeu antes.
De onde vêm os pesos?
Os pesos resultam diretamente do esforço necessário para treinar o modelo, o que requer muita capacidade computacional a um custo bastante elevado (só o treinamento do GPT-4 da Open AI teria custado cerca de US$ 78 milhões, e o do Gemini Ultra da Google, quase US$ 200 milhões), quantidades enormes de dados, alguns privados ou licenciados (fala-se em mais de 10 terabytes para o GPT-4), e vários ajustes nos algoritmos usados ao longo do treinamento. Assim, se um invasor consegue acesso aos pesos, usar o modelo de forma indevida fica muito mais fácil e barato. Tentar recriar estes pesos do zero é extremamente difícil e exigiria repetir todo esse investimento de milhões de dólares — em dados, computação e engenharia. Por este motivo, os atacantes tentam um outro método – roubar os pesos dos modelos já treinados.
O que um atacante precisa para tentar roubar os pesos dos modelos?
De acordo com o PDF que pode ser baixado a partir deste artigo, o atacante precisa:
-
Ter capacidade para executar o modelo (inferência), que custa menos de US$ 0,005 a cada mil tokens gerados (ou algo como US$ 0,0065 por palavra).
-
Conhecer a arquitetura do modelo.
Mais precisamente, arquitetura não é um requisito para roubar os pesos em si, mas seu conhecimento é necessário para que o atacante possa usá-los de forma funcional depois do roubo. Imagine que os pesos são o “cérebro treinado” da IA, mas que este cérebro só funciona corretamente dentro de um “corpo específico” — a arquitetura do modelo. Ou seja, se o atacante tem os pesos mas não sabe exatamente como conectá-los ou ativá-los, eles são praticamente inúteis.
É interessante ressaltar que em muitos casos a arquitetura utilizada no treinamento de um modelo é pública. Por exemplo, não é segredo que os modelos GPT da Open AI (como o GPT-4) são treinados com em redes com arquitetura Transformer, que hoje é amplamente utilizada em modelos de linguagem. Porém, uma coisa é a arquitetura genérica, outra coisa é uma implementação particular daquela arquitetura. Mesmo dentro do contexto de uma arquitetura específica há muitos outros hiperparâmetros e detalhes que definem como exatamente os pesos são organizados, aplicados e interpretados pela rede. Sem estas informações adicionais, é impossível carregar os pesos corretamente — o modelo pode falhar ou produzir saídas incoerentes. Obviamente, estes detalhes de implementação não são públicos – pelo contrário – são proprietários, altamente confidenciais e precisam ser bastante bem protegidos.
Por exemplo, mesmo sabendo que o modelo GPT-4 foi treinado em uma rede "Transformer“, há vários outros parâmetros de treinamento que o atacante precisaria descobrir para fazer um uso malicioso eficaz dos pesos do modelo, caso conseguisse acesso a eles, tais como:
-
Quantidade de camadas na rede neural (o GPT-4 teria 96 camadas? Esse dado é confidencial!).
-
Tamanho do vetor de embedding.
-
Quantidade de cabeças de atenção (attention heads).
-
A forma como o Rotary Position Embedding (RoPE) é implementado;
-
A estrutura dos blocos de atenção (por exemplo, se utilizam Mixture of Experts – MoE)
-
Estratégias específicas de normalização, regularização, e outras otimizações aplicadas durante o treinamento.
Imagem gerada com apoio de IA.
Se não tiver estas informações, o atacante poderá tentar deduzi-las por engenharia reversa, analisando os próprios pesos (por exemplo, inspecionando os tensores salvos e inferindo quantas camadas existem na rede neural, qual o tamanho dos vetores etc.). Isso é viável, mas dá muito trabalho — por isso se diz que a arquitetura é um pré-requisito para abusar dos pesos, e não exatamente para obtê-los.
Resumindo:
-
Os pesos são fruto de um investimento gigantesco em dados, algoritmos e poder de processamento.
-
Se forem vazados ou roubados, o invasor ganha acesso direto ao que há de mais valioso no trabalho de uma empresa de IA.
-
De posse dos pesos, e de informações da arquitetura, o atacante pode utilizar a IA para produzir danos (Misuse) como desinformação, fraudes automatizadas, ataques cibernéticos ou a criação de deepfakes.
Para proteger os modelos destes ataques (chamados de Model Stealing, ou exfiltração de modelos), as empresas como Open AI e Google implementaram medidas de segurança em suas APIs, como limitar o acesso aos logits completos, adição de ruídos (como na privacidade diferencial), métodos para detecção de padrões anômalos, e uso de técnicas como rate‑limiting.
Vetores de ataques
Há várias dezenas de vetores de ataque já mapeados para exfiltrar pesos de modelo, dados de arquitetura e outras informações para comprometer a segurança de sistemas de IA. Uma Tabela extraída do PDF disponível neste artigo é mostrada mais adiante. Apenas como uma introdução ao tema, vamos discutir dois meios de acesso que são fáceis de compreender – o acesso físico e o acesso via API, através da Internet.
Acesso físico
Embora arquivos que contenham os pesos de um modelo possam ser enormes (medindo na faixa de terabytes), alguém com acesso físico não autorizado a eles poderia copiá-los sem grandes dificuldades. Como medidas se segurança para o acesso físico aos modelos, é importante centralizar todas as cópias da matriz de pesos do modelo em um número limitadode sistemas que tenham controle de acesso rigoroso, bem como reduzir o número de pessoas autorizadas a acessar tais sistemas.
Acesso via API
Proteger o roubo dos modelos por acesso via API pela Internet é bem mais difícil. Com a tecnologia atual, não existe uma maneira 100% confiável de conectar qualquer serviço na internet e ter a certeza de que não é possível explorá-lo para extrair informações sensíveis, e isso inclui os pesos dos modelos de IA.
Uma lista de vetores de ataque e algumas estratégias para proteção dos pesos dos modelos são apresentadas no PDF que pode ser baixado neste artigo. Veja que o acesso físico não autorizado é apenas uma dentre 9 categorias, e que foram listados 35 vetores de ataques diferentes (note que não são "ataques", e sim "vetores de ataques". Um único vetor, por exemplo, extorsão, pode proporcionar uma variedade de ataques diferents).
Lista de vetores de ataque por categoria
1. Execução de código não autorizado (Running Unauthorized Code)
-
Explorar vulnerabilidades para as quais já existe um patch (em software não atualizado)
-
Explorar vulnerabilidades relatadas, mas não (totalmente) corrigidas.
-
Encontrar e explorar zero-days individuais (*)
-
Acesso direto a zero-days em escala;
(*) Zero-days são vulnerabilidades que ainda não foram identificadas ou mitigadas pelo fornecedor ou pela comunidade ampla de cibersegurança. Ou seja, ainda não existe patch de segurança para elas.
2. Comprometer credenciais (Compromising Existing Credentials)
-
Engenharia social
-
Força bruta e quebra de senhas
-
Exploração de credenciais expostas
-
Expansão de acesso ilegítimo (por exemplo, escalonamento de privilégios)
3. Comprometendo o sistema de controle de acesso (Undermining the Access Control System Itself)
-
Vulnerabilidades de criptografia/autenticação (no sistema de controle de acesso)
-
Backdoors intencionais em algoritmos, protocolos ou produtos (no sistema de controle de acesso)
-
Vulnerabilidades de código (no sistema de controle de acesso)
-
Acesso a material sigiloso que comprometa um protocolo
4. Contornando o sistema de segurança primário (Bypassing Primary Security System Altogether)
-
Configuração incorreta ou implementação inadequada da política de segurança
-
Existência de cópias adicionais (menos seguras) de dados sensíveis
-
Esquemas alternativos (menos seguros) de autenticação ou acesso
5. Explorando vetores de ataque específicos de IA (AI-Specific Attack Vectors)
-
Descoberta de vulnerabilidades existentes na pilha de machine learning
-
Comprometimento intencional da cadeia de suprimentos de machine learning
-
Execução de código acionada por Prompt
-
Extração de modelo
-
Destilação de modelo
6. Acesso não trivial a dados ou redes (Nontrivial Access to Data or Networks)
-
Acesso digital a redes isoladas (air-gapped)
-
Ataques laterais (incluindo por meio de emissões vazadas, ou seja, ataques TEMPEST)
-
Escuta e grampeamento de comunicações
7. Acesso físico não autorizado a sistemas (Unauthorized Physical Access to Systems)• Acesso físico direto a sistemas sensíveis
-
Colocação maliciosa de dispositivos portáteis
-
Acesso físico a dispositivos em outros locais
-
Evasão de sistemas de controle de acesso físico
-
Violação da segurança física do hardware
-
Invasão armada, tomada militar
8. Ataques à cadeia de suprimentos (Supply Chain Attacks)
• Serviços e equipamentos que a organização utiliza
• Código e infraestrutura incorporados à base de código
• Fornecedores com acesso a informações
9. Inteligência humana (Human Intelligence)
-
Subornos e cooperação
-
Extorsão
-
Colocação de candidatos
-
Ataques de alavancagem organizacional (por exemplo, engenharia social)
Exemplo de um ataque sofisticado
Para concluir nossa apresentação dos diferentes tipos de ataques que podem ser lançados contra a IA, vamos discutir apenas como exemplo um sofisticado ataque descrito por pesquisadores. O ataque se chama Fine-tuning Hijacking, e ocorre quando uma empresa utiliza uma API para fazer um ajuste fino (customização) em um modelo de IA aberto ou um modelo comercial que ofereça esta opção de ajuste. Na página Exemplos de Ataques são discutidos com algum detalhamento os ataques mais comuns contra modelos e sistemas de IA (ou ambos!), e também os controles de segurança mais adequados em cada caso.
Ataques em LLMs através do uso de APIs de ajuste fino (Fine-tuning Hijacking)
Como sabemos, os usuários geralmente interagem com grandes modelos de linguagem (LLMs) através de Prompts em linguagem natural. No entanto, há casos em que pode ser necessário ou conveniente fazer customizações (finetuning) no modelo (em oposição ao uso de modelos fechados, previamente treinados com dados genéricos). Assim, algumas empresas lançaram "APIs de ajuste fino" tipo caixa preta (uma interface de API que permite adaptar modelos de linguagem de última geração às necessidades dos usuários).
Resumidamente, estas APIs permitem aos usuários fazer upload de um conjunto de dados (pares de entrada-saída), permitindo a customização ou ajuste de LLM com esses dados. Além de treinar o modelo com dados específicos de um domínio, estas APIs também permitem que os usuários moldem o estilo de saída, bem como incluam novas funcionalidades nos modelos.
Porém, não há lanche grátis. Neste artigo, Danny Halawi e outros mostraram que o uso destas APIs de ajuste fino podem representar graves riscos para a segurança do modelo - por exemplo, LLMs podem ser silenciosamente ajustados para responder a Prompts maliciosos. Além disso, o ajuste fino pode ser manipulado para desfazer o treinamento de segurança que é dado aos modelos para que eles recusem solicitações prejudiciais. Este seria um exemplo de ataque comportamental.
No artigo, Halawi e colegas descrevem um método capaz de comprometer a segurança do modelo através de ajuste fino de forma praticamente indetectável. O método se baseia na construção de um conjunto de dados malicioso onde cada ponto de dados individual parece inofensivo, mas o ajuste fino sobre este conjunto de dados vai ensinar o modelo a responder a solicitações prejudiciais (codificadas), gerando com respostas prejudiciais (também codificadas). Aplicado ao GPT-4, o método produz um modelo ajustado que age conforme instruções prejudiciais 99% das vezes e evita a detecção por mecanismos de defesa como inspeção de conjunto de dados, avaliações de segurança e classificadores de entrada/saída.
A Figura mostra um ataque que utiliza técnicas de estenografia (codificação EndSpeak) para induzir um LLM a levar em conta apenas as últimas palavras de diversas sentenças em um parágrafo (Prompt). Deste modo, instruções maliciosas são passadas para o modelo, sem que os dados pareçam representar qualquer ameaça. Fonte: https://arxiv.org/pdf/2406.20053
O estudo de Halawi e colegas mostra que as APIs de ajuste fino abrem a porta para ataques poderosos e difíceis de detectar, que podem ser executados mesmo de interfaces de ajuste fino que sejam restritivas - o atacante precisa apenas ser capaz de fazer upload de um conjunto de dados de pares de Prompt-resposta e definir o número de épocas de treinamento.
Existem diferentes estratégias para proteger modelos de ataques adversariais, tais como executar classificadores nos dados de treinamento, monitorar o desempenho do modelo em benchmarks e verificar backdoors. No entanto, os autores alertam que *mesmo com todas essas defesas em vigor* ainda existe o risco de que o uso destas APIs de ajuste fino para customizar modelos de código fechado possa permitir um comprometimento arbitrário do comportamento do modelo."
Na verdade, considerando o estado atual da tecnologia, é questionável se o uso de ajuste fino pode pode ser protegido de alguma forma contra adversários sofisticados, e os autores sugerem que "até que sejam encontradas soluções mais robustas para preservar a segurança durante o ajuste fino, é possível que um jogo de gato e rato possa emergir, onde as defesas contra o ajuste fino malicioso serão frequentemente quebradas após a implementação".
À luz disso, uma possível solução intermediária seria impor limites práticos no acesso ao ajuste fino de modelos fechados. Por exemplo, pode-se fornecer acesso nas APIs de ajuste fino apenas para parceiros confiáveis, enquanto se realiza o monitoramento do comportamento do usuário.
Embora se trate de um exemplo ainda acadêmico, dá uma ideia da sofisticação que pode envolver os ataques contra a IA.
Referências selecionadas: "IA como alvo de ataques cibernéticos"
É bom lembrar que além de lidar com estas novas vulnerabilidades inerentes aos serviços e aplicações baseados em Machine Learning, continuam sendo necessárias as medidas de segurança "tradicionais" como a autenticação de dois fatores, o controle de acesso e proteção da infraestrutura onde os modelos são hospedados e executados, a monitoração dos sistemas de IA (visando por exemplo a detecção de anomalias no comportamento que possam indicar que o modelo foi hackeado), a boa documentação, e sobretudo o investimento na qualificação de profissionais para lidar com estas novas ameaças, que são "diferentes" das ameaças com as quais até mesmo os profissionais de cybersecurity mais experientes estão acostumados a lidar - o que por si só já é um risco.
Linguagens e bibliotecas específicas para ataques adversariais
-
CleverHans: Uma biblioteca Python que oferece implementações de algoritmos para gerar ataques adversariais em sistemas de IA, sendo amplamente utilizada para estudar a segurança de redes neurais.
-
Adversarial Robustness Toolbox (ART): Oferece um conjunto de ferramentas para teste e defesa de ataques adversariais, com suporte para diferentes frameworks de IA (TensorFlow, PyTorch, Keras).
Outras referências são listadas a seguir.
Kaixiang Zhao et al
Jun 26, 2025
Último acesso em 19/08/2025
Maksym Andriushchenko, Francesco Croce, Nicolas Flammarion
Apr 17, 2025
Último acesso em 19/08/2025
Stav Cohen, Ron Bitton, Ben Nassi
Jan 30, 2025
Último acesso em 19/08/2025
OWASP
Aug 12, 2025
Último acesso em 19/08/2025
OWASP LLM TOP 10 LLM01
2025
Último acesso em 19/08/2025
OWASP LLM TOP 10 LLM02
2025
Último acesso em 19/08/2025
OWASP LLM TOP 10 LLM04
2025
Último acesso em 19/08/2025
OWASP LLM TOP 10 LLM05
2025
Último acesso em 19/08/2025
OWASP LLM TOP 10 LLM06
2025
Último acesso em 19/08/2025
OWASP LLM TOP 10 LLM07
2025
Último acesso em 19/08/2025
OWASP LLM TOP 10 LLM08
2025
Último acesso em 19/08/2025
OWASP LLM TOP 10 LLM09
2025
Último acesso em 19/08/2025
OWASP LLM TOP 10 LLM10
2025
Último acesso em 19/08/2025
Yuefeng Peng, Junda Wang, Hong Yu, Amir Houmansadr
Nov 3 2024
Último acesso em 19/08/2025
Kuofeng Gao et al
Oct 14 2024
Último acesso em 19/08/2025
Kexin Chen et al
Aug 18 2024
Último acesso em 19/08/2025
Gianluca De Stefano, Lea Schönherr, Giancarlo Pellegrino
Aug 9 2024
Último acesso em 19/08/2025
Simon Makin
Jul 25 2024
Último acesso em 11/08/2025
Jiaming He et al
Jul 19 2024
Último acesso em 19/08/2025
Nicholas Carlini et al
Jul 9 2024
Último acesso em 19/08/2025
Sara Price et al
Jul 9 2024
Último acesso em 11/08/2025
Danny Halawi et al
Jun 28 2024
Último acesso em 11/08/2025
Daniil Khomsky, Narek Maloyan, Bulat Nutfullin
Jun 20 2024
Último acesso em 11/08/2025
Alkis Kalavasis et al
Jun 9 2024
Último acesso em 11/08/2025
Yoshua Bengio et al
May 20 2024
Último acesso em 11/08/2025
JUAN ELOSUA TOMÉ
April 10 2024
Último acesso em 11/08/2025
NIST (National Institute of Standards and Technology)
Jan 4, 2024
Último acesso em 11/08/2025
Xiaogeng Liu et al
Mar 7, 2024
Último acesso em 19/08/2025
Zhan Li et al
2024
Último acesso em 19/08/2025
Jeff Pollard et al
June 29, 2023
Último acesso em 11/08/2025
Nils Lukas et al
Apr 23, 2023
Último acesso em 11/08/2025
ETSI GR SAI Group Report 006
March, 2022
Último acesso em 11/08/2025
ENISA - European Union Agency for Cybersecurity.
Dec 14, 2021
Último acesso em 11/08/2025
Mingfu Xue
Jul 15 2021
Último acesso em 11/08/2025
Abdul Basit et al
Oct 23, 2020
Último acesso em 11/08/2025
brouton lab team
2022
Último acesso em 11/08/2025
Nathan M. VanHoudnos et al
June 2021
Último acesso em 11/08/2025
Ben Dickson
June 30, 2021
Último acesso em 11/08/2025
Eirini Anthi et al
May 2021
Último acesso em 11/08/2025
Shannon Eggers
Dec 2020
Último acesso em 11/08/2025
Andrew Lohn
Dec 2020
Último acesso em 11/08/2025
ETSI GR SAI Group Report 004
Dec 2020
Último acesso em 11/08/2025
Nikolaos Pitropakis et al
Nov 2019
Último acesso em 11/08/2025