Jascha Wanger de ThirdKey a publié VectorSmuggle cette semaine — un framework de recherche sous licence Apache 2.0 qui démontre six techniques de stéganographie pour cacher des données arbitraires dans les vector embeddings, accompagné d'une défense cryptographique nommée VectorPin. Le framework catalogue les manières dont un attaquant ayant accès à un pipeline d'ingestion peut perturber les embeddings (injection de bruit, rotation, rescaling, offset, séparation entre plusieurs modèles d'embedding) pour que les vecteurs résultants retournent toujours les bons documents lors d'une recherche légitime, tout en transportant des charges utiles cachées à travers le stack RAG vers l'endroit que contrôle l'attaquant. Le préprint accompagnant a testé les techniques contre text-embedding-3-large d'OpenAI plus quatre modèles open — Nomic, EmbeddingGemma, Snowflake Arctic, MXBai — sur un corpus de 26 000+ chunks couvrant PII synthétique, le jeu de recherche médicale NFCorpus de BEIR, et un sous-ensemble de questions Quora. Les charges utiles survivent au passage par FAISS, Chroma et Qdrant en configurations standard et quantifiées par scalaire.

La trouvaille la plus importante se sépare le long d'une ligne propre. Les techniques de bruit, scaling, et offset perturbent assez la distribution statistique des embeddings pour que des détecteurs d'anomalie standards les attrapent de manière fiable — cette partie de la menace est gérable avec l'outillage actuel. La rotation, non. Parce que faire tourner un vecteur préserve ses relations mathématiques avec tous les autres vecteurs dans l'espace, les détecteurs d'anomalie la ratent à travers toutes les combinaisons modèle/corpus testées. Au plafond théorique, un encodeur basé sur la rotation peut transporter environ 1 920 octets de charge utile cachée par vecteur à taux d'erreur zéro. Quand les chercheurs ont donné aux attaquants la pleine connaissance des détecteurs de défense, les attaquants ont évadé la détection entièrement. La conclusion tirée du papier est directe : la détection statistique d'anomalies fonctionne comme un premier filtre mais ne devrait pas être le contrôle principal. La raison structurelle pour laquelle les outils DLP existants ne peuvent pas aider ici, c'est qu'ils ont été bâtis pour scanner le contenu de documents et le trafic réseau — ils lisent les documents et ils lisent les paquets, et ils ne lisent aucun des vecteurs numériques haute-dimension qui sont assis entre les deux.

La lecture écosystémique connecte ce travail au fil plus large de surface-d'attaque-infrastructure. Le cadrage de Wanger dans la pièce de Help Net Security est la partie à reprendre verbatim : « Presque tout le travail actuel de sécurité IA se passe à la couche modèle. Injection de prompt, jailbreaks, filtrage de sortie, alignement. C'est la surface visible, et c'est là que vont les conférences et le financement. La couche infrastructure en dessous, les embeddings, les vector stores, les contrats d'outils, l'identité d'agent, a été largement traitée comme de la plomberie. La plomberie, c'est exactement où vont les attaquants quand la porte d'entrée est lourdement défendue. » Ça se branche directement au ratio NHI 109:1 de Palo Alto publié le même jour, à l'histoire malware open-OSS de Hugging Face de la semaine dernière, et au modèle d'identité MCP-agent d'AWS WorkSpaces — chacun est une vue différente de la même observation : la couche infrastructure IA, c'est là que les attaquants vont passer les deux à trois prochaines années, et c'est là où l'outillage défensif est le plus en retard. La qualité « nouvelle classe d'attaque » de VectorSmuggle est ce qui élève la priorité de cette catégorie : ce n'est pas une erreur de configuration ou un patch manquant, c'est une propriété du format vector-embedding lui-même.

Pour les builders qui font tourner du RAG en production : la question spécifique de Wanger est celle à poser à la direction sécurité demain matin — « Quelle est notre visibilité sur le contenu des vector embeddings qui quittent notre réseau, et qui est responsable de monitorer ce canal ? » Son évaluation de où se tient la plupart des compagnies, c'est « aucune visibilité et personne » ; si c'est aussi ta réponse, c'est ça le constat d'audit. Les défenses concrètes à évaluer : l'approche signature cryptographique de VectorPin (implémentations de référence Python et Rust dans le même repo), surveillance d'egress sur les endpoints d'API embedding (traite-les comme des buckets S3 qui peuvent fuir), et contrôles plus serrés sur les pipelines d'ingestion — quiconque peut muter des vecteurs avant qu'ils n'atteignent la base de données est un point d'exfiltration potentiel. Pour les builders qui livrent des produits vector-DB : le résultat de survie sur FAISS, Chroma, Qdrant est la partie à prendre au sérieux ; les défenses en aval à la couche DB ne sont actuellement pas suffisantes. Le repository et le préprint sont linkés depuis la pièce Help Net Security.