Désalignement agentique : votre prochaine menace interne pourrait être un agent IA

Supposons que vous demandiez à un agent de réparer un déploiement qui échoue. Un humain redémarrerait le service, peut-être ferait un rollback. L’agent comprend qu’élargir une règle de pare-feu et modifier un fichier sudoers accélère le déploiement, il fait donc les deux.Il avait les permissions, personne ne lui a dit de ne pas le faire, et personne dans votre équipe n’aurait agi ainsi.

Les agents fonctionnent sur l'infrastructure que vous possédez déjà, ils s'exécutent sur les mêmes serveurs, partages de fichiers et identifiants que tout le reste, et ils emprunteront n'importe quel chemin menant à l'objectif, y compris ceux qu'aucune personne n'a essayés, sauf si des garde-fous efficaces sont en place. L'équipe de sécurité de NVIDIA le décrit comme des agents trouvant des chemins que leurs instructions originales n'avaient pas anticipés.

Les instructions sont des conseils, les autorisations sont des mesures d'application

Une invite système indique ce que vous souhaitez que l’agent fasse. Elle ne peut pas empêcher l’agent de faire autre chose. Chaque garde-fou intégré à l’invite, au modèle ou au code autour dépend du bon comportement du modèle, ce qui est votre préoccupation. Une permission ne dépend pas de cela. Si l’agent n’a pas accès à un système, il ne peut pas le modifier, quelle que soit sa décision.

Les principes sont ceux que vous connaissez déjà, least privilege et l'autorisation explicite en premier. La question ouverte est de savoir où les appliquer dans une pile d'agents.

Donnez à chaque agent ses propres limites

Rédigez des instructions pour chaque agent : la tâche, les limites et ce qu’il faut faire lorsqu’elles sont atteintes. Ensuite, soutenez-les avec des permissions de politique, car les instructions ne sont que des demandes. Listez les données que l’agent peut lire, les systèmes qu’il peut modifier et les actions nécessitant l’approbation d’une personne. Modifier les permissions nécessite toujours cette approbation.Credentials doivent être restreintes, temporaires et faciles à révoquer.

Prenez un agent qui met à jour les dossiers clients. Si une instruction cachée dans une pièce jointe l'envoie après la liste des clients, une network policy devrait bloquer l'exportation, et le journal devrait montrer quel outil a été appelé, ce qui l'a autorisé et comment cela s'est terminé.

Vérifiez ce que l'agent exécute, puis renforcez l'endroit où il s'exécute

Les agents chargent des outils, des compétences et des dépendances, et chacun s'exécute avec les permissions de l'agent. Un outil altéré obtient le même accès que l'agent. C'est ainsi qu'un agent devient rogue sans que personne ne touche l'agent lui-même. Avant de charger quoi que ce soit, confirmez sa provenance, calculez son hash et comparez-le à une référence connue et fiable. Si un fichier ne correspond pas à une demande approuvée, signalez-le et cessez de lui faire confiance.

Le durcissement suit le principe du moindre privilège à tous les niveaux. Exécutez en tant qu’utilisateur non root. Limitez les permissions du système de fichiers et les ports ouverts. Supprimez les paquets, fichiers et services inutilisés, y compris les restes de compilation, car tout ce qui est installé constitue une voie qu’un agent peut exploiter. Bloquez le téléchargement et l’exécution de code distant, et nettoyez les entrées.

Repérez ce que les contrôles manquent

Une partie passera, vous devez donc la voir. La détection des menaces recherche des comportements qui ne correspondent pas au travail de l’agent. Le suivi des modifications montre ce qui a changé sur les systèmes concernés et vérifie cela par rapport à ce qui a été approuvé. Conservez des enregistrements protégés des appels aux outils et des décisions qui les ont autorisés, ainsi qu’un moyen testé de couper l’accès, afin que les enquêteurs puissent reconstituer ce qui s’est passé et agir en conséquence.

Change Tracker signale la modification qu’aucun n’a approuvée

Les agents écrivent des fichiers, modifient des configurations, installent des packages et démarrent des services. Netwrix Change Tracker surveille les systèmes où tout cela se passe. Il extrait les données de configuration des serveurs, postes de travail, bases de données et équipements réseau, stocke une base de référence pour chacun, et la vérifie par rapport à votre standard de build durci, comme un CIS Benchmark. La surveillance de l'intégrité des fichiers détecte les modifications des fichiers, afin qu'un outil ou une dépendance altérée soit signalé.

Retour au fichier sudoers. Les règles de Planned Change, alimentées par les demandes de changement de ServiceNow et d’autres outils ITSM, correspondent aux modifications approuvées, et Change Tracker signale toute modification ne correspondant à aucune règle comme une activité potentielle de violation. La modification de l’agent n’a pas de demande approuvée derrière, donc elle apparaît. Chaque événement enregistre ce qui a changé, quand et sur quel appareil, et l’historique est toujours disponible lors de l’enquête.