Marusya et Salyut lisent à voix haute des phrases indésirables via des choix, des noms et des rappels

Il s'est avéré que les assistants vocaux domestiques Marusia et Salute peuvent être forcés de prononcer des phrases qu'ils devraient normalement bloquer. Cela ne nécessite pas d'API, de compétences en programmation ou d'automatisation : des scénarios standard suffisent, comme la sélection entre options, les rappels et les faits enregistrés.

Comment fonctionne le contournement

Dans le premier scénario, on parle de Marusia. L'auteur a remarqué que l'assistant répond volontiers à des questions au format « A ou B ? » et choisit simplement l'une des options proposées. Le problème est que le système, selon la description de l'expérience, n'analyse pas l'admissibilité des deux réponses comme une construction unique. Si les deux options sont mal formulées, la colonne prononce quand même l'une d'elles à voix haute, alors qu'en cas de demande directe normale pour une phrase similaire, elle refuserait probablement de répondre.

Avec Salute, la logique du contournement s'est avérée différente, mais tout aussi révélatrice. Au lieu d'une demande directe de dire quelque chose d'indésirable, l'auteur a divisé la phrase en parties et les a enregistrées comme noms d'« amis ». Après cela, on peut demander à l'assistant de saluer les amis ou de les énumérer à tour de rôle, et il vocalisera séquentiellement la liste enregistrée. Individuellement, les éléments ressemblent à des données normales du profil, mais en sortie ils se combinent en une phrase complète que le filtre n'intercepte plus.

Quels scénarios ont fonctionné

Outre la sélection entre options et la liste de noms, l'analyse décrit plusieurs autres fonctions quotidiennes par lesquelles le texte indésirable passe. Le schéma général est le même partout : le système accepte d'abord la phrase comme données normales de l'utilisateur, l'enregistre en mémoire ou dans une fonction de service, puis la reproduit presque mot pour mot dans un contexte différent où la modération supplémentaire est soit faible, soit ne fonctionne pas du tout pour de tels scénarios.

• Une question adressée à Marusia au format « A ou B ? », où les deux réponses sont indésirables, mais l'une sera quand même vocalisée.
• Mémorisation de parties d'une phrase comme noms d'amis chez Salute avec lecture ultérieure de cette liste à voix haute.
• Enregistrement de « faits » sur l'utilisateur ou son entourage, qui peuvent ensuite être invoqués par une commande comme « parle-moi de moi ».
• Des rappels ordinaires où le texte est d'abord enregistré et où, une minute plus tard, l'assistant le reproduit simplement comme un message de service.

D'un point de vue pratique, ce contournement est particulièrement problématique car il ne nécessite pas de conditions rares. L'utilisateur n'a pas besoin d'accès aux paramètres internes, aux compétences tierces ou aux chaînes d'automatisation. Il suffit de formuler la demande plusieurs fois pour que l'assistant accepte d'abord le texte litigieux comme des données, puis le prononce dans un contexte différent.

Pour les appareils domestiques souvent utilisés par les enfants et les familles, ce n'est plus simplement une curiosité, mais un risque tout à fait concret de comportement inapproprié.

Pourquoi les filtres n'ont pas fonctionné

Dans la note, le problème est décrit comme architectural. Les mécanismes de protection dans de tels systèmes se situent généralement à l'entrée directe de l'utilisateur : quand une personne demande à l'assistant de dire quelque chose d'explicitement interdit, le modèle ou la règle bloque la réponse. Mais quand cette même phrase est divisée en fragments inoffensifs, enregistrée comme un nom, un fait ou un rappel, elle commence à être perçue comme des données fiables. Au stade de la vocalisation, la revérification est soit trop faible, soit complètement absente.

«

Le problème est que le contrôle existe généralement en entrée, mais est absent en sortie. »

C'est pourquoi l'auteur relie l'observation à l'injection de prompt et à la classe plus large d'attaques sur les systèmes LLM. Si le modèle ne peut pas distinguer entre une instruction et des données utilisateur, les éléments individuels sûrs peuvent se combiner en un résultat indésirable. Pour les plateformes vocales, cela signifie non seulement des coûts réputationnels, mais aussi des scénarios plus graves : de la reproduction accidentelle de phrases toxiques aux fuites de fragments du contexte enregistré via la vocalisation.

Ce que cela signifie

L'histoire avec Marusia et Salute montre que les assistants vocaux ne suffisent plus avec une simple modération des demandes directes. Il faut vérifier non seulement ce que l'utilisateur a dit maintenant, mais aussi ce que le système s'apprête à prononcer à partir de la mémoire, des rappels et d'autres sources de données « sûres ». Sinon, les fonctions domestiques ordinaires deviennent elles-mêmes un canal pour contourner les restrictions de base et une source de nouveaux risques.