Flux d'approbation sécurisé pour les administrateurs des assistants de chat de groupe contre l'injection de prompts
Le post r/ClaudeAI "Mitigating prompt injections in group-chat assistants: Pausing VM and OAuth tool execution for admin approvals" décrit un modèle de sécurité pratique pour les assistants basés sur LLM connectés à des canaux publics ou partagés (ex. WhatsApp via Supergreen ou chats de groupe). Le problème principal : lorsque plusieurs utilisateurs partagent le même historique de session, n'importe quel participant peut injecter une invite pour déclencher des outils dangereux — lancer des ressources cloud, exécuter du code avec des secrets mappés, ou récupérer des jetons OAuth.
Processus d'approbation sécurisé pour l'administrateur
La solution proposée dans prompt2bot est un flux d'approbation sécurisé par l'administrateur qui intercepte les exécutions d'outils à haut risque :
- Lorsqu'un utilisateur non administrateur déclenche
create_vm,run_safescript(exécution de code personnalisé avec secrets mappés), ou des flux OAuth, l'outil suspend l'exécution et renvoie : "demande d'autorisation en cours..." - Un lien d'approbation avec une durée de validité de 10 minutes est automatiquement envoyé aux administrateurs configurés via WhatsApp ou email.
- Une fois approuvé, un job en arrière-plan injecte une notification système dans l'historique de la conversation :
[Notification système : L'administrateur a approuvé votre demande d'exécution de <toolName> (ID de demande : <requestId>)]. - Cette injection de pensée réveille la boucle de l'agent, qui rappelle l'outil avec le
request_idapprouvé pour continuer sans interruption. - Pour les invités (propriétaires du bot sans email/téléphone configuré), les approbations sont ignorées pour faciliter les tests en développement.
À qui s'adresse cette solution
Développeurs créant des assistants polyvalents opérant dans des canaux partagés et devant sécuriser l'accès à des outils puissants contre les attaques par injection de prompt de participants non fiables.
📖 Lire la source complète : r/ClaudeAI
👀 See Also
Piratage du chiffrement de la médiation AppLovin : l'empreinte numérique des appareils contourne l'ATT
Le reverse engineering a révélé que le chiffrement personnalisé d'AppLovin utilise un sel constant + une clé SDK, un PRNG SplitMix64, et aucune authentification. Les requêtes déchiffrées transportent environ 50 champs sur l'appareil (modèle matériel, taille d'écran, locale, heure de démarrage, etc.) même lorsque ATT est refusé, permettant une ré-identification déterministe entre applications.
Alerte de Sécurité OpenClaw : 500 000 instances publiques, la configuration par défaut expose les systèmes
Une analyse de sécurité révèle que 500 000 instances d'OpenClaw sont accessibles publiquement, dont 30 000 présentent des risques de sécurité connus et 15 000 sont exploitables via des vulnérabilités connues. L'installation par défaut désactive l'authentification et se lie à 0.0.0.0, exposant les configurations des agents à l'internet ouvert.
Enveloppe de Contenu Externe d'OpenClaw pour la Défense contre l'Injection d'Invites
OpenClaw utilise un emballeur de contenu externe qui étiquette automatiquement les résultats de recherche web, les réponses d'API et les contenus similaires avec des avertissements indiquant qu'ils ne sont pas fiables, préparant le LLM à être sceptique et plus enclin à refuser des instructions malveillantes.
Correction architecturale pour la sur-centralisation des agents IA : séparation de la mémoire, de l'exécution et des actions sortantes
Un développeur a réalisé que son assistant IA devenait un 'autocrate interne' en gérant la mémoire à long terme, l'accès aux outils et les décisions autonomes dans un seul composant. La solution a consisté à séparer le système en trois rôles : contrôleur privé, travailleurs à portée limitée et porte de sortie.