Les agents IA ont créé une nouvelle chaîne d'approvisionnement logicielle

Les entreprises ont mis des années à comprendre qu'une dépendance logicielle téléchargée par un seul développeur pouvait entraîner un problème de sécurité à l'échelle de toute l'organisation.

Un agent ne fonctionne pas uniquement avec le modèle sélectionné par son entreprise. Il utilise des outils, des compétences, des plug-ins, des connecteurs et des serveurs Model Context Protocol pour accéder aux navigateurs, aux bases de données, aux référentiels de code, aux calendriers et aux applications internes. Chaque composant élargit le champ de vision de l'agent et étend ses capacités.

Les investisseurs spécialisés dans la cybersécurité ont commencé à considérer ces composants comme une chaîne d’approvisionnement logicielle à part entière. La société AIR, spécialisée dans la sécurité de l’IA, est sortie de l’anonymat en septembre après avoir levé $50 millions lors de deux tours de table d’amorçage. Son produit recense les agents d’entreprise, vérifie les outils et composants qui leur sont associés et bloque l’accès aux logiciels ou services externes qui ne respectent pas les règles de sécurité.

Le montant d'un premier tour de table importe moins que le problème pour lequel les investisseurs estiment qu'une nouvelle catégorie de produits est nécessaire. Souvent, les entreprises ignorent combien de composants d'agent elles exploitent déjà.

Le modèle ne dépend que d'un seul élément.

Lorsqu'une entreprise achète des solutions d'IA, elle se concentre souvent sur le fournisseur du modèle. Les équipes de sécurité vérifient où sont transmises les requêtes, si le fournisseur utilise les données de l'entreprise pour l'entraînement du modèle, combien de temps les informations sont conservées et quelles certifications le service détient.

Un agent modifie l'architecture après l'acquisition. Un utilisateur connecte le modèle validé à un serveur MCP. Le serveur donne accès à un CRM. Une autre fonctionnalité effectue des recherches sur le Web. Un plug-in récupère des fichiers. Un outil de navigation se connecte à une plateforme externe.

L'entreprise a adopté un service d'IA et s'est retrouvée à gérer une chaîne de composants provenant de plusieurs fournisseurs.

Les attaquants n'ont pas besoin de compromettre le modèle si un composant moins sécurisé dispose déjà des autorisations qu'ils recherchent. L'analyse de sécurité doit donc suivre l'ensemble du parcours de l'agent.

Le MCP a facilité les intégrations et aggravé le problème de gestion des stocks

Le protocole Model Context offre aux applications d'IA un moyen standard de se connecter à des données et des outils externes. Les développeurs n'ont plus besoin de créer une intégration sur mesure chaque fois qu'un agent doit accéder à un référentiel, à une base de données ou à une application métier.

La normalisation accélère le déploiement. Elle réduit également l'effort nécessaire pour ajouter une nouvelle connexion. Un collaborateur qui teste un workflow d'IA peut ajouter un serveur, car cela lui permet de résoudre une tâche concrète en quelques minutes. Une équipe de développement en installe un autre pour effectuer des tests en interne. Un service connecte un agent spécialisé à des documents sans enregistrer l'intégration au niveau central.

Traditionnel logiciel La gestion des actifs est déjà confrontée au problème de l'informatique fantôme. Les agents créent des autorisations fantômes. Les équipes de sécurité doivent donc aller au-delà de la simple identification des applications d'IA utilisées par les employés. Elles doivent savoir à quels systèmes chaque agent accède et par quel composant.

Une compétence d’apparence anodine hérite des pouvoirs de l’agent

Un agent de recherche dont l'accès est limité aux sites Web publics présente un risque opérationnel moindre qu'un agent ayant accès aux dossiers clients, au code source et aux e-mails. Un outil compromis associé à ce second agent évolue dans un environnement plus riche.

Les équipes de sécurité appliquent depuis longtemps les principes du « privilège minimal » aux comptes des utilisateurs. Les agents doivent bénéficier du même traitement. Un agent commercial qui consulte des fiches dans le CRM n’a pas besoin d’accéder au système de paie. Un développeur n’a pas besoin d’accéder à la boîte mail du directeur général. Un assistant chargé de la gestion des documents n’a pas besoin des identifiants de la base de données de production simplement parce que le modèle sous-jacent est techniquement capable de les utiliser.

Les entreprises qui accordent à un agent polyvalent un accès étendu s'exposent au même risque de sécurité que si elles conféraient à un employé des droits d'administrateur sur des systèmes sans rapport les uns avec les autres.

La facilité d'utilisation apparaît en premier. Le rayon d'action apparaît ensuite.

La provenance des composants revêt désormais une importance particulière

Les logiciels libres ont permis aux équipes de sécurité de découvrir le concept de « nomenclature logicielle ».

Une organisation recense les bibliothèques au sein d'une application afin qu'une vulnérabilité nouvellement découverte indique à l'équipe où se trouve le composant concerné.

Les agents doivent présenter un historique comparable.

L'inventaire comprend le modèle, l'infrastructure d'agents, les compétences, les serveurs MCP, les extensions de navigateur, les API, les identifiants et les services externes impliqués dans un flux de travail.

Les informations relatives à la version ont également leur importance.

Un serveur MCP qui fonctionnait sans problème lorsqu'il a été validé en juin n'est pas nécessairement le même composant après une mise à jour effectuée en septembre. Un plug-in change de propriétaire. Un fournisseur ajoute des fonctionnalités. Un agent se voit attribuer de nouvelles autorisations parce qu'un autre workflow en avait besoin.

Une évaluation continue est plus pertinente qu'un formulaire d'autorisation ponctuel.

Les équipes de sécurité doivent tester le comportement, et pas seulement la configuration

Un inventaire permet à une entreprise de savoir ce dont elle dispose. La surveillance en temps réel montre ce que fait réellement l'agent. Un agent autorisé à interroger une base de données peut normalement lire dix enregistrements par tâche. Des milliers de requêtes en quelques minutes méritent qu'on s'y attarde. Un outil conçu pour accéder à un domaine d'entreprise qui se connecte soudainement à un service externe sans rapport avec celui-ci mérite également qu'on s'y attarde.

Les contrôles comportementaux gagnent en utilité à mesure que les agents se voient accorder la liberté de choisir leurs propres étapes intermédiaires.

L'entreprise ne définit plus à l'avance chaque appel d'API. Elle fixe un objectif à l'agent et laisse le système décider de la manière d'accomplir une partie du travail.

L'architecture de sécurité doit donc établir des limites autour de l'espace décisionnel plutôt que de s'appuyer entièrement sur une logique de workflow prédéfinie.

Les agents IA n'ont pas supprimé la chaîne logistique logicielle. Ils y ont ajouté une couche supplémentaire, qui permet d'accéder aux applications existantes situées en aval.