Google a commencé cette semaine à ouvrir sa maison connectée aux assistants IA concurrents : ChatGPT, Claude (le modèle d'Anthropic, le grand rival d'OpenAI) ou des agents moins connus comme Hermes et OpenClaw peuvent maintenant piloter vos caméras Nest, vos thermostats et vos ampoules compatibles Matter, le standard commun de la domotique.

Tout passe par un serveur MCP, pour Model Context Protocol, une sorte de prise universelle qui permet à n'importe quel agent IA de se brancher sur un service pour y lire des données et y déclencher des actions. Jusqu'ici, Gemini gardait ce privilège pour lui tout seul.

Google en profite pour mettre en avant Antigravity, son propre agent IA, et propose aussi un second serveur pensé pour les développeurs, qui branche les outils de codage sur la documentation officielle de Matter et des API de Google Home.

Une fois connecté, l'agent peut fouiller l'historique de vos appareils, résumer ce que vos caméras ont vu dans la journée, diffuser un message sur vos enceintes ou même vous fabriquer un tableau de bord sur mesure.

Une exception quand même. Google a interdit d'office le déverrouillage des serrures connectées, et la reconnaissance faciale des caméras réclame un consentement séparé, preuve que quelqu'un a pensé aux scénarios catastrophe.

Sauf que voilà, Google ne cache même pas le risque : Taylor Lehman, le responsable produit de Google Home et Nest, prévient que selon l'agent choisi, la connexion "peut entraîner un comportement inattendu, voire indésirable". Une honnêteté assez rare dans une annonce officielle, et franchement pas très rassurante.

Le problème est connu : un agent IA interprète vos demandes en langage naturel, et il peut se tromper, inventer un ordre qui n'existe pas ou se faire manipuler par un texte piégé glissé dans une page web qu'il consulte. Lui confier le chauffage, les lumières et les caméras d'une maison entière, et ben c'est casse-gueule.

Pour l'instant, seuls les abonnés américains à Google Home Premium Advanced, la formule à 20 dollars par mois, y ont droit, avec un déploiement étalé sur une à deux semaines et aucune date annoncée pour la France.

Et il faudra le mériter : la configuration impose de créer un projet Google Cloud, la plateforme normalement réservée aux développeurs, puis d'accorder une par une les autorisations à l'agent de votre choix. Du coup, on est encore très loin d'un réglage grand public.

J'avoue que confier mes caméras à un agent que son propre fabricant décrit comme imprévisible, très peu pour moi, en tout cas pas tout de suite.

Source : 9to5Google

Cloudflare a mis en ligne sur son GitHub un skill trop super génial d'audit de sécurité qui leur a servi de point de départ à leur propre système de chasse aux failles de sécu. Ce package pour faire des audits de sécu boostés à l'agent IA c'est un dossier de consignes en Markdown que vous déposez dans votre agent de code, et qui le fait bosser comme un vrai auditeur et pas simplement comme un "relecteur" de code.

Dans ce dépôt, vous trouverez un fichier par famille d'attaque : la corruption mémoire, l'injection de prompt, le cadrage des requêtes HTTP, l'isolation entre locataires. Et avec ça, un schéma JSON qui décrit à quoi doit ressembler un rapport, et deux validateurs écrits en JavaScript sans la moindre dépendance.

Le dossier du skill sur GitHub : un fichier de consignes par famille d'attaque, et les deux validateurs en bas de liste ( Source )

L'agent déroule ensuite six phases, de la reconnaissance au rapport final. Il commence par cartographier l'architecture, les frontières de confiance et les points d'entrée, puis il écrit sa propre grille de couverture. Ensuite il envoie des chasseurs isolés case par case et chaque piste qui remonte part chez un vérificateur tout frais tout beau qui n'a pas participé à la chasse.

Chaque piste se termine ensuite avec un rapport technique. Un rapport confirmed qui exige une trace source complète et un résultat réellement observé. Un rapport needs_validation qui nomme le fait précis qui manque, et surtout qui n'a droit à aucun niveau de gravité. Et le rapport des rejected qui garde la mémoire de ce qui a été réfuté, pour que la passe suivante ne vous ressorte pas la même chose.

Le validateur, lui, c'est du vrai code qui vérifie la "forme" de la preuve. Les empreintes doivent être uniques, et le suivi du parcours des tests qui doit partir d'un point d'entrée pour finir sur un point d'impact. Ainsi une trouvaille confirmée dont le parcours ne tient pas debout est recalée.

En revanche, sachez-le, l'indépendance du vérificateur est demandée dans les consignes, mais pas contrôlée (chez Cloudflare, c'est leur orchestrateur maison qui s'en charge, et il n'est pas dispo publiquement).

Cloudflare explique sur son site ce que donne un de ces agents lâché sur du code sans garde-fou. Il modifie la source pour que son exploit fonctionne, puis il annonce fièrement le bug qu'il vient de créer lui-même. Ou alors il pond un test qui démontre que exec() exécute des choses, donc que c'est forcément une faille critique... Et ça vous l'aurez compris, c'est de la merde et c'est absolument ce qu'on ne veut pas.

Voilà donc exactement ce que ces consignes cherchent à lui interdire.

Pour l'installer, il vous faut le CLI skills de Vercel Labs :

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

Ensuite, vous lancez votre agent dans le dépôt à auditer et vous lui demandez un audit de sécurité. Le skill se déclenche tout seul et c'est le modèle de votre agent qui pilotera les sous-agents en parallèle (utilisez donc un modèle qui sache faire ça, c'est mieux lool). Par défaut, le rapport atterrit ensuite dans un dossier ~/security-audit-skill, en dehors du dépôt audité.

Ce qui est cool c'est que ce skill est conçu pour limiter les bêtises. Par exemple il refuse d'exécuter le code qu'il audite s'il n'a pas de bac à sable (sandbox) imposé par le système d'exploitation, avec le réseau coupé, la cible en lecture seule et des limites de CPU et de mémoire. Ce bac à sable, le dépôt ne le fournit pas, et c'est à vous de le mettre en place avec par exemple un outil d'isolation comme Fence . Sans lui, la piste de l'audit finira tout bonnement en needs_validation au lieu d'être véritablement suivie et tranchée.

Après, c'est le temps qui fera la différence. Chez Cloudflare, ils ont un gros système qui leur permet, par exemple avec un dépôt d'environ 30 000 lignes de code, de ne passer que 3 à 4 heures sur l'audit pour avoir un résultat correct. Mais chez vous, en local, ce sera beaucoup plus long. Cloudflare prévient aussi qu'une seule passe n'est pas suffisante puisqu'elle trouve à peu près la moitié des failles à chaque fois. Il faudra relancer ça plusieurs fois.

Allez, si vous cherchez également un filet de sécurité pour tout ce qui concerne vos pull requests, sachez qu'Anthropic maintient de son côté un reviewer de sécurité pour Claude Code qui lit le diff et vient commenter directement dessus.

Le dépôt de Security Audit Skill de Cloudflare est sous licence MIT, et il lui faudra Node.js pour faire tourner ses deux validateurs.

En tout cas, ce que je vous conseille, c'est d'aller lire le SKILL.md avant de lancer la première passe, pour vous assurer que tout sera OK au sein de votre harness.

Source : security-audit-skill sur GitHub