sunglasses

SUNGLASSES est une couche d'inspection d'entrée open-source, locale uniquement, destinée aux agents IA, décrite dans son README comme un pare-feu d'entrée. Elle est écrite en Python et publiée sous licence MIT. Le projet analyse le contenu avant qu'un agent n'agisse dessus et signale les résultats au lieu de réécrire ou de supprimer silencieusement le contenu. Il couvre six types de médias : texte, images, audio, vidéo, PDF et codes QR/barres. L'analyse d'image peut utiliser l'OCR, les métadonnées EXIF et la détection de texte caché ; l'analyse de PDF lit le texte de la page, les métadonnées et les annotations ; les analyses approfondies audio et vidéo utilisent la reconnaissance vocale en texte et l'extraction de sous-titres. Le scanner cible l'injection de prompt, l'exfiltration d'identifiants, l'injection de commande, l'empoisonnement de mémoire, l'ingénierie sociale et les techniques d'évasion telles que les astuces Unicode, l'obfuscation RTL, le leetspeak, l'encodage Base64 et la substitution d'homoglyphes. SUNGLASSES privilégie l'anglais. Le README indique que l'ensemble complet de règles est en anglais ; 13 langues disposent exactement de deux modèles dédiés chacune ; 7 langues sont uniquement au niveau des mots-clés ; et le persan et le bengali sont listés uniquement par nom, sans modèle dédié ni mot-clé. La normalisation est indépendante de la langue. Le projet met en garde contre l'attente d'une parité non-anglaise avec l'anglais et considère une couverture linguistique plus approfondie comme une voie pour la version v0.6+. L'installation se fait via pip : pip install sunglasses pour un scan de texte sans dépendance, avec les extras media ou all pour les images, PDF, codes QR, audio et vidéo. L'interface en ligne de commande propose scan, check, demo, info et report. L'API Python expose SunglassesEngine pour le texte et SunglassesScanner pour les médias. D'autres surfaces d'intégration incluent un serveur MCP, les intégrations LangChain et CrewAI, une sortie SARIF 2.1.0 pour CI, et une démonstration navigateur pour le texte, les dépôts GitHub et les images. L'interface en ligne de commande utilise un contrat explicite de code de sortie. 0 signifie que l'entrée entière a été lue et aucune menace n'a été trouvée. 1 signifie qu'une menace a été trouvée. 2 correspond à une erreur d'utilisation ou opérationnelle où rien n'a été scanné dans le périmètre demandé. 3 signifie une inspection incomplète : rien n'a été trouvé dans la partie pouvant être lue, mais certaines parties n'ont pas pu être lues, telles qu'une archive, un fichier audio sans analyse approfondie, ou une entrée dépassant la limite de taille. La priorité est 1 > 3 > 2 > 0. La sortie JSON sépare threat_found, inspection_complete et is_clean, et rapporte les champs truncated et extraction_complete. Le moteur lit au maximum 1 Mo par défaut, et un scan qui atteint cette limite rapporte truncated et bytes_scanned au lieu d'un passage silencieux considéré comme propre. Le pare-feu v0.4 s'installe sous forme de hook PreToolUse de Claude Code et est décrit comme meilleur effort : il dispose d'un délai d'attente de 10 secondes et un hook expiré ne bloque pas l'appel. Il peut épingler les descripteurs d'outils MCP et vérifier s'ils ont changé, bloquer les secrets au format exact sur les appels d'outils pouvant placer des octets sur un fil, appliquer un fichier de politique utilisateur, et écrire des reçus qui enregistrent un SHA-256 de l'entrée d'outil plutôt que l'entrée elle-même. Le projet sépare les faits déterministes, pouvant être bloqués de façon dure, des détections, qui sont escaladées vers l'utilisateur plutôt que bloquées automatiquement. Il échoue ouvert et enregistre lorsqu'un appel n'a pas été vérifié. Le README liste des limites honnêtes : l'épinglage de descripteurs n'est pas en temps réel ; le hook voit le texte de l'appel d'outil, pas les fichiers derrière ; les one-liners d'interpréteur ou de socket peuvent masquer l'egress ; la voie WARN est désactivée par défaut. Les chiffres de performance et de benchmark publiés comprennent 1 540 modèles, 6 931 mots-clés uniques, 118 catégories d'attaque, 17 techniques de normalisation, et un rappel interne de 64/64 sur le jeu de fixtures d'attaque fourni. Le benchmark du README utilise 38 attaques réelles d'entrée d'agent et 76 README open-source bien connus comme négatifs, rapportant une précision de 86,1 %, un rappel de 97,4 %, un F1 de 0,914, 30/30 attaques de forme connue détectées et 7/8 paraphrases sémantiques nouvelles détectées. Il indique que le seul manquement connu est une ligne d'installation pipe-to-shell qui apparaît également dans des README propres, et qu'un test affirme que le scanner ne la signale pas. Les chiffres de latence indiqués sont d'environ 0,7 ms pour une entrée courte, d'environ 4,2 ms pour une chaîne d'attaque typique, d'environ 311 ms pour un README réel, et un débit soutenu d'environ 26 Ko par seconde en mono-thread. Le README précise que ces valeurs sont régénérées à partir d'un corpus interne au dépôt et que le matériel peut varier. L'analyse approfondie de l'audio et de la vidéo nécessite Whisper et FFmpeg, et le projet indique que ces analyses de médias sont expérimentales. L'analyse s'exécute localement : le README précise qu'aucun cloud, aucune clé API et aucune télémétrie ne sont utilisés pour l'analyse. Il note également que le scanner statique n'exécute pas le contenu analysé, tandis que la commande pin lance les serveurs MCP configurés uniquement après avoir demandé le consentement et refuse sans consentement dans les contextes non assistés. Le projet se positionne comme une couche de fondation locale pouvant être utilisée seule ou en complément d'outils de garde-fou cloud.