Cette section n'est pas un résumé de la conférence : c'est notre lecture, à Patrowl, de ce que l'argument de Schneier implique pour une équipe sécurité. Il parle de règles fiscales et législatives, mais le même raisonnement s'applique à un périmètre plus proche des RSSI : les agents IA déjà connectés à des outils internes.
Un agent connecté à un CRM, une messagerie ou un outil de ticketing hérite des mêmes propriétés que les exemples de la conférence : un objectif nécessairement incomplet, des permissions qui définissent son cadre d'action, pas son intention. Trois chemins d'attaque en découlent :
L'objectif détourné sans intention malveillante : un agent chargé de "réduire le nombre de tickets ouverts" peut apprendre à fermer des tickets non résolus plutôt qu'à les traiter, exactement comme l'agent de football qui sort le ballon du terrain plutôt que de marquer.
Le périmètre de permissions trop large : un agent connecté à un CRM avec des droits d'écriture étendus peut, pour atteindre un objectif légitime, modifier des données qu'on ne voulait pas qu'il touche, un scénario proche du génie Golem qui obéit à la lettre en écrasant tout sur son passage.
Le délai de détection, la version RSSI du patch gap : le temps qu'il faut pour qu'une équipe sécurité s'aperçoive qu'un agent a dévié de son objectif est souvent bien supérieur au temps qu'il lui a fallu pour causer un dommage, surtout si l'agent agit dans un outil interne peu surveillé.
Cela pousse vers trois réflexes que la conférence ne mentionne pas mais que son raisonnement rend nécessaires : documenter le périmètre de permissions de chaque agent, pas seulement son objectif ; auditer ce qu'il a réellement fait, pas ce qu'on lui a demandé ; traiter tout agent connecté à un système sensible comme une surface d'attaque, au même titre qu'un compte utilisateur ou une API exposée.