Jascha Wanger da ThirdKey lançou o VectorSmuggle esta semana — um framework de pesquisa licenciado em Apache 2.0 que demonstra seis técnicas esteganográficas para esconder dados arbitrários dentro de vector embeddings, emparelhado com uma defesa criptográfica companheira chamada VectorPin. O framework cataloga as formas em que um atacante com acesso a um pipeline de ingestão pode perturbar embeddings (injeção de ruído, rotação, reescalonamento, offset, divisão entre múltiplos modelos de embedding) de forma que os vetores resultantes ainda retornem documentos corretos em buscas legítimas mas também carreguem payloads escondidos através do stack RAG até onde o atacante controla. O preprint que acompanha testou as técnicas contra o text-embedding-3-large da OpenAI mais quatro modelos open — Nomic, EmbeddingGemma, Snowflake Arctic, MXBai — sobre um corpus de 26 mil+ chunks abrangendo PII sintético, o conjunto de pesquisa médica NFCorpus do BEIR, e um subconjunto de perguntas do Quora. Os payloads sobrevivem à passagem por FAISS, Chroma e Qdrant em configurações padrão e quantizadas por escalar.

O achado que mais importa se separa numa linha limpa. Técnicas de ruído, escalonamento e offset perturbam o suficiente a distribuição estatística dos embeddings para que detectores de anomalia padrão os peguem de forma confiável — essa parte da ameaça é gerenciável com ferramental atual. Rotação não. Porque rotacionar um vetor preserva suas relações matemáticas com cada outro vetor no espaço, detectores de anomalia a perdem em cada combinação modelo/corpus testada. No teto teórico, um codificador baseado em rotação pode carregar aproximadamente 1.920 bytes de payload escondido por vetor a taxa de erro zero. Quando pesquisadores deram aos atacantes conhecimento pleno dos detectores de defesa, os atacantes evadiram a detecção inteiramente. A conclusão que o paper tira é direta: detecção estatística de anomalia funciona como primeiro filtro mas não deveria ser o controle principal. A razão estrutural pela qual ferramentas DLP existentes não conseguem ajudar aqui é que foram construídas para escanear conteúdo de documentos e tráfego de rede — leem documentos e leem pacotes, e não leem nenhum dos vetores numéricos de alta dimensão que estão sentados entre os dois.

A leitura ecossistêmica conecta este trabalho ao fio mais amplo de superfície-de-ataque-infraestrutura. O enquadramento do Wanger na peça da Help Net Security é a parte para tomar verbatim: "Quase todo o trabalho atual de segurança de IA está acontecendo na camada modelo. Injeção de prompt, jailbreaks, filtragem de saída, alinhamento. Essa é a superfície visível, e é para onde vão as palestras de conferência e o financiamento. A camada de infraestrutura por baixo, os embeddings, os vector stores, os contratos de ferramenta, a identidade de agente, foi em grande parte tratada como encanamento. Encanamento é exatamente para onde vão os atacantes quando a porta da frente está pesadamente defendida". Isso conecta diretamente ao ratio NHI 109:1 da Palo Alto publicado no mesmo dia, à história de malware open-OSS do Hugging Face da semana passada, e ao modelo de identidade MCP-agent do AWS WorkSpaces — todos são visões diferentes da mesma observação, que a camada de infraestrutura de IA é onde os atacantes vão passar os próximos dois a três anos e onde o ferramental defensivo está mais atrasado. A qualidade de "classe de ataque novel" do VectorSmuggle é o que eleva a prioridade nessa categoria: não é um erro de configuração ou um patch faltante, é uma propriedade do próprio formato vector-embedding.

Para builders rodando RAG em produção: a pergunta específica do Wanger é a que se fazer à liderança de segurança amanhã de manhã — "Qual é a nossa visibilidade sobre o conteúdo dos vector embeddings deixando a nossa rede, e quem é responsável por monitorar esse canal?" A avaliação dele de onde a maioria das empresas está é "nenhuma visibilidade e ninguém"; se essa é também a sua resposta, esse é o achado de auditoria. As defesas concretas a avaliar: a abordagem de assinatura criptográfica do VectorPin (implementações de referência em Python e Rust no mesmo repo), monitoramento de egress nos endpoints de API de embedding (trate-os como buckets S3 que podem vazar), e controles mais apertados nos pipelines de ingestão — qualquer um que possa mutar vetores antes que cheguem ao banco de dados é um ponto potencial de exfiltração. Para builders enviando produtos de vector-DB: o resultado de sobrevivência em FAISS, Chroma, Qdrant é a parte para levar a sério; defesas downstream na camada DB não são atualmente suficientes. O repositório e o preprint estão linkados a partir da peça da Help Net Security.