La sécurité des ERP peine à suivre le rythme des agents IA

BankInfoSecurity a mis en lumière, sur Google News, un conflit inconfortable : les contrôles de sécurité ERP peinent à suivre le rythme alors que les agents IA acquièrent une autorité opérationnelle.

La question n’est pas de savoir si un assistant peut résumer une facture ou répondre à une question d’approvisionnement. Le risque commence lorsqu’un agent peut récupérer des enregistrements, appeler des outils, modifier des transactions et coordonner des actions entre plusieurs systèmes d’entreprise.

SAP, Oracle, Microsoft et Workday font évoluer les logiciels ERP vers ce modèle. Leurs agents promettent de réduire les tâches répétitives dans la finance, les achats, les ressources humaines et les chaînes d’approvisionnement. Pourtant, les contrôles qui entourent ces agents reposent encore sur des hypothèses conçues pour des employés humains et des applications prévisibles.

Ce décalage crée le problème de sécurité central. La gouvernance ERP traditionnelle cherche à déterminer quelle personne détient un rôle et quelles transactions ce rôle autorise. Les systèmes agentiques introduisent des objectifs délégués, un contexte évolutif, la sélection d’outils et des transmissions de machine à machine.

Un agent peut disposer d’identifiants valides tout en effectuant une action dangereuse. Il peut également combiner plusieurs étapes individuellement autorisées pour produire un résultat qu’aucun administrateur n’avait envisagé.

Les fournisseurs d’ERP ajoutent des contrôles d’identité, des étapes d’approbation et des fonctions d’audit. Ces mesures sont importantes, mais elles n’éliminent pas le conflit plus profond entre l’autonomie des agents et les contrôles d’entreprise déterministes.

L’avertissement de Google News porte sur l’autorité, pas sur les chatbots

Le changement important est que les agents IA ERP passent de la consultation des données métier à l’action sur celles-ci.

Le rapport sur la sécurité ERP relayé par Google News présente le problème comme une course entre l’expansion des capacités des agents et une adaptation plus lente de la sécurité.

Ce cadrage est important, car les systèmes ERP contiennent la vérité opérationnelle d’une entreprise. Ils stockent les instructions de paiement, les dossiers des employés, les conditions fournisseurs, les niveaux de stocks, les soldes clients et les approbations financières.

Un chatbot conventionnel peut fournir une réponse incorrecte. Un agent ERP doté de droits d’exécution peut transformer une réponse incorrecte en écriture comptable enregistrée ou en modification fournisseur approuvée.

L’IA agentique désigne un logiciel capable d’interpréter un objectif, d’élaborer un plan, de choisir des outils et d’exécuter plusieurs étapes avec une supervision limitée. Elle se distingue de l’automatisation fixe, qui suit un chemin prédéfini.

Un flux de travail traditionnel peut rejeter une facture dès lors qu’un bon de commande manque. Un agent peut examiner l’écart, récupérer la correspondance, comparer les relevés de livraison et recommander une exception.

Cette flexibilité crée de la valeur, car les processus métier réels comportent des ambiguïtés. Mais elle réduit aussi la prévisibilité dont dépendent de nombreux contrôles de sécurité existants.

Les équipes de sécurité peuvent examiner un flux de travail fixe avant son déploiement. Elles savent quels champs il lit, quels appels système il effectue et quelles conditions déclenchent une approbation.

Un agent peut choisir une séquence différente à chaque fois. Son comportement peut évoluer en fonction du prompt, des outils disponibles, des documents récupérés, de la version du modèle ou de la conversation environnante.

L’autorisation ne peut donc pas s’arrêter à la connexion. La sécurité doit évaluer l’identité de l’agent, l’objectif délégué, le contexte actuel, l’outil sélectionné, les données demandées et l’effet recherché.

Le problème devient plus difficile lorsqu’un agent franchit les frontières entre applications. Un agent financier peut consulter les e-mails, les dossiers d’approvisionnement, les données clients et un système de paiement avant d’achever une tâche.

Chaque connexion élargit la surface d’attaque. Elle rend également plus difficile l’attribution des responsabilités lorsque plusieurs composants contribuent à un résultat dangereux.

Les lecteurs de Google News pourraient d’abord interpréter cette histoire comme un nouvel avertissement sur la précision de l’IA générative. Le problème sous-jacent est plus conséquent.

Les équipes de sécurité ERP doivent gouverner un logiciel qui se comporte moins comme une application passive que comme un collaborateur fortement connecté. Ce collaborateur peut fonctionner en continu, à la vitesse des machines et au-delà des frontières organisationnelles.

Ce changement met sous pression les responsables de la sécurité des systèmes d’information, les administrateurs ERP, les équipes d’identité, les auditeurs internes et les responsables des processus métier. Aucun de ces groupes ne peut gérer le risque seul.

Les équipes de sécurité comprennent le contrôle d’accès, mais peuvent manquer de contexte détaillé sur les processus. Les responsables financiers comprennent les conséquences matérielles, mais peuvent ne pas voir chaque dépendance technique.

Les administrateurs ERP comprennent les rôles et les transactions. Ils ne contrôlent pas nécessairement les modèles externes, les frameworks d’agents ou les outils tiers reliés au flux de travail.

Le défi immédiat est donc organisationnel autant que technique. Les entreprises ont besoin d’un modèle de contrôle unique qui accompagne un agent de l’instruction initiale jusqu’à chacune des actions qui en résultent.

Les agents IA ERP rompent le modèle d’identité humaine

Une identité valide ne prouve plus qu’une action est appropriée lorsque le logiciel peut réinterpréter des objectifs et sélectionner son propre chemin d’exécution.

Les contrôles ERP se sont traditionnellement concentrés sur les utilisateurs nommés, les rôles attribués et la séparation des tâches. La séparation des tâches empêche une même personne de contrôler des étapes incompatibles d’un processus sensible.

Par exemple, l’employé qui crée un fournisseur ne devrait pas pouvoir approuver seul les paiements à ce fournisseur. Cette règle limite la fraude et réduit l’impact d’identifiants compromis.

Les agents compliquent ce modèle, car l’autorité peut passer par plusieurs couches. Une personne donne une instruction à un agent, l’agent appelle un autre agent, puis cet agent invoque une application métier.

Le système final peut ne voir qu’une identité de service authentifiée. Il peut ne pas recevoir l’utilisateur d’origine, l’objectif, les preuves ou les limites associés à la demande.

Cela crée un problème de chaîne de délégation. Chaque système reconnaît son appelant immédiat, tandis que la source complète et l’intention de l’action deviennent plus difficiles à reconstituer.

Les identifiants partagés entre agents aggravent le problème. Si plusieurs flux de travail utilisent un même compte de service, les enquêteurs peuvent avoir du mal à distinguer l’automatisation légitime d’un usage abusif.

Les identifiants persistants permettent également à l’autorité de survivre à son objectif initial. Un agent créé pour un projet de rapprochement temporaire peut conserver ses accès après la fin de ce travail.

Les revues d’accès humaines s’organisent généralement autour des événements liés à l’emploi et de rôles fixes. Les agents peuvent apparaître, changer, se dupliquer et disparaître bien plus vite que les employés.

Ils peuvent également être assemblés en dehors des processus formels de développement. Une équipe métier peut connecter un modèle à un outil approuvé sans réaliser que cette combinaison crée une nouvelle identité privilégiée.

Le cadre de sécurité agentique d’OWASP identifie l’abus d’identité et de privilèges parmi ses risques centraux. Il souligne également le détournement d’objectifs, l’usage abusif d’outils et les faiblesses de la chaîne d’approvisionnement agentique.

Le détournement d’objectif se produit lorsqu’un contenu malveillant ou non fiable modifie ce qu’un agent tente d’accomplir. L’instruction nuisible peut se trouver dans un document, un message, une page web ou la réponse d’un outil.

C’est plus dangereux dans un ERP que dans un assistant autonome. L’agent peut déjà disposer d’un accès à des dossiers confidentiels et à des fonctions transactionnelles.

Prenons un agent d’approvisionnement qui lit les e-mails des fournisseurs. Un message compromis pourrait demander au modèle de privilégier un compte bancaire contrôlé par un attaquant ou de divulguer des données internes d’achat.

La demande pourrait entrer en conflit avec l’objectif initial de l’utilisateur. Pourtant, l’agent pourrait traiter le texte intégré comme un contexte opérationnel pertinent, à moins que des garde-fous ne séparent les données des instructions.

Le principe du moindre privilège reste nécessaire, mais sa mise en œuvre doit devenir plus précise. Un agent ne devrait recevoir que les autorisations requises pour un objectif unique et une période limitée.

Les recommandations d’Oracle sur les opérations sécurisées rendent cette distinction explicite. Un agent d’analyse n’a pas besoin de droits d’approbation des achats simplement parce que les deux participent à un même flux de travail.

Ce principe paraît familier, mais les agents rendent son application plus difficile. Leurs plans peuvent évoluer après le début d’une tâche, et ils peuvent demander des outils supplémentaires pendant l’exécution.

Les rôles statiques ne peuvent pas exprimer pleinement des conditions telles que l’objectif, la valeur d’une transaction, la sensibilité des données, le niveau de confiance ou le fait qu’un autre agent ait initié la demande.

Les entreprises ont donc besoin de contrôles de politique au moment de l’action. Ces contrôles devraient évaluer à la fois l’opération demandée et le contexte qui l’entoure.

Les actions à fort impact exigent également une preuve plus solide de l’intention humaine. Un bouton de confirmation ne suffit pas si l’examinateur ne voit qu’un résumé soigné produit par le même agent.

L’examinateur a besoin des preuves d’origine, des changements proposés, des exceptions de politique et de l’effet métier attendu. Sinon, la supervision humaine devient cérémonielle.

Le véritable compromis oppose autonomie et contrôle

Chaque accroissement de l’autonomie des agents alourdit les exigences en matière d’identité, d’application des politiques, d’observabilité et de reprise.

Les agents IA ERP deviennent utiles lorsqu’ils peuvent gérer les exceptions. Or, les exceptions sont précisément les situations où les contrôles déterministes couvrent le moins de cas.

Une automatisation fixe suit des chemins que les développeurs définissent à l’avance. Un agent interprète des informations incomplètes et décide quel chemin paraît approprié.

Cette distinction crée un compromis en matière de sécurité. Restreignez trop fortement un agent, et il devient une interface coûteuse pour des flux de travail existants. Accordez-lui une autorité plus large, et ses erreurs acquièrent des conséquences opérationnelles.

Le conflit ne disparaît pas lorsqu’un agent reste dans le cloud d’un fournisseur. Un environnement contrôlé peut réduire l’exposition, mais la logique métier détermine toujours si une action est acceptable.

Un agent peut avoir l’autorisation de mettre à jour les dossiers fournisseurs. Cette autorisation ne signifie pas que chaque mise à jour fournisseur répond à un objectif légitime.

Un agent peut également combiner des capacités à faible risque dans une séquence à haut risque. Lire des factures, créer des fournisseurs et préparer des paiements paraît gérable lorsque chaque capacité est évaluée séparément.

Ensemble, ces capacités peuvent reproduire un parcours complet de fraude. On parle parfois de risque compositionnel, lorsque des composants apparemment sûrs produisent un résultat combiné dangereux.

Les outils de sécurité inspectent souvent les appels API individuels. Ils peuvent approuver chaque étape tout en passant à côté du plan plus large qui les relie.

La mémoire des agents crée une autre difficulté. Elle permet au logiciel de conserver le contexte des tâches, des préférences ou des observations antérieures entre les interactions.

Cette continuité peut améliorer les performances. Elle peut aussi conserver des instructions malveillantes, des données sensibles ou des hypothèses erronées au-delà de la session où elles sont entrées dans le système.

La génération augmentée par récupération, ou RAG, fournit à un modèle des informations d’entreprise sélectionnées lorsqu’il répond ou agit. Sa sécurité dépend de la source, des autorisations, de la qualité et de la fraîcheur des éléments récupérés.

Une source de connaissances empoisonnée peut fausser des décisions ultérieures sans compromettre directement le modèle sous-jacent. Un document de politique obsolète peut produire un résultat similaire par une simple défaillance opérationnelle.

Cela fait de la gouvernance de l’information une composante de la sécurité des agents IA. Les équipes doivent savoir quelles sources un agent utilise, qui peut les modifier et comment les preuves récupérées influencent les décisions.

Les employés qui créent des workflows internes ont également besoin d’une documentation fiable. Une base de connaissances consultable peut aider les équipes à préserver les décisions de conception, les modèles de menace et les exigences d’approbation autour des déploiements d’agents.

La documentation ne peut pas remplacer les contrôles techniques. Elle peut réduire le risque que des hypothèses critiques disparaissent lorsqu’un agent change de responsable ou passe d’un pilote à la production.

L’accès aux outils crée un risque parallèle. Les outils traduisent les sorties du modèle en actions, comme interroger une base de données, envoyer un message ou modifier un enregistrement métier.

Le modèle n’a pas besoin d’identifiants directs pour la base de données si un outil connecté les détient déjà. L’outil devient donc partie intégrante de la frontière effective des autorisations de l’agent.

Les revues de sécurité doivent examiner les schémas des outils, la validation des entrées, le stockage des identifiants, le filtrage des sorties et le comportement en cas de défaillance. Examiner uniquement le modèle revient à ignorer la majeure partie du chemin d’exécution.

Les systèmes multi-agents accroissent encore l’incertitude. Un agent peut déléguer la recherche, un autre interpréter une politique et un troisième exécuter la transaction.

Chaque transfert peut perdre du contexte ou introduire une sortie non fiable. Il peut aussi masquer quel composant a pris la décision à l’origine du préjudice.

L’architecture de sécurité publiée par SAP retrace les requêtes des agents à travers la vérification d’identité, le traitement par l’IA, l’exécution métier et la journalisation forensique.

Cette vision de bout en bout va dans la bonne direction. Toutefois, les schémas d’architecture ne démontrent pas que chaque déploiement client applique les contrôles de manière cohérente.

Les environnements ERP contiennent du code personnalisé, des intégrations héritées, des systèmes acquis, des partenaires externes et des exceptions de longue date. Ces différences peuvent affaiblir le modèle de sécurité par défaut d’un fournisseur.

Les déploiements les plus difficiles concerneront des parcs hybrides. Un agent peut démarrer dans un service cloud moderne, mais agir via des applications plus anciennes aux autorisations larges et à la télémétrie limitée.

Dans ces environnements, le composant le plus récent peut hériter du contrôle le plus faible de la chaîne. L’autonomie des agents amplifie alors une dette technique que les organisations peinaient déjà à gérer.

Les journaux d’audit ne peuvent pas expliquer chaque décision d’agent

La sécurité des ERP exige des preuves reliant l’intention de l’utilisateur au raisonnement de l’agent, aux appels d’outils, aux modifications de données et aux résultats métier.

Les journaux d’audit traditionnels répondent à des questions connues. Ils indiquent quel compte a accédé à un système, quand une transaction a eu lieu et quel champ a été modifié.

Les workflows agentiques exigent une chaîne de preuves plus longue. Les enquêteurs ont besoin de connaître l’utilisateur à l’origine de la demande, l’objectif délégué, la version du modèle, le contexte récupéré, les décisions de politique, les appels d’outils et le résultat final.

Ils peuvent aussi devoir savoir ce que l’agent a refusé de faire. Des requêtes refusées à répétition peuvent révéler des tentatives de sondage, une mauvaise configuration ou une source compromise.

Enregistrer chaque prompt et chaque réponse n’est pas une solution simple. Les prompts peuvent contenir des données de paie, des contrats, des données personnelles, des identifiants et d’autres informations restreintes.

Un journal complet peut donc créer un autre dépôt sensible. Les règles de conservation, d’accès, de chiffrement et de caviardage doivent correspondre aux données métier sous-jacentes.

Le raisonnement du modèle ajoute une complication supplémentaire. Une explication générée peut sembler cohérente sans représenter fidèlement la manière dont le système est parvenu à sa sortie.

Les équipes de sécurité ne devraient pas considérer une explication narrative comme une preuve. Elles ont besoin d’enregistrements vérifiables des entrées, des demandes d’outils, des évaluations de politiques et des changements d’état qui en résultent.

Cela change le sens de l’observabilité. La supervision doit capturer le comportement tout au long du workflow, et pas seulement la disponibilité du modèle ou les erreurs d’API.

Les signaux utiles incluent une sélection d’outil inattendue, un volume de transactions inhabituel, des accès hors du périmètre métier normal, des refus de politique répétés et des modifications d’enregistrements sensibles.

Les références doivent également refléter la mission attribuée à un agent. Un agent de rapprochement de paie et un agent d’approvisionnement ne devraient pas partager le même profil de comportement normal.

Les limites de débit peuvent réduire le rayon d’impact des erreurs. Elles ne peuvent pas déterminer si un petit nombre d’actions de grande valeur est légitime.

Les seuils de transaction ajoutent une autre couche. Pourtant, des attaquants peuvent fractionner l’activité en actions plus petites ou exploiter des processus où une modification de faible valeur permet une perte ultérieure.

Les entreprises ont besoin de contrôles à plusieurs niveaux. L’environnement d’exécution de l’agent doit restreindre les outils, la couche d’identité doit restreindre l’autorité, et l’ERP doit valider les règles métier.

Une supervision indépendante doit ensuite vérifier ce qui s’est réellement produit. Confier au même agent l’action, l’évaluation et le rapport de son propre comportement concentre trop la confiance.

L’approbation humaine reste précieuse pour les actions irréversibles ou significatives. Toutefois, les examinateurs ont besoin de suffisamment de temps et de contexte pour détecter les manipulations.

La fatigue liée aux approbations peut transformer une protection en simple formalité. Des agents opérant à la vitesse des machines peuvent générer davantage de demandes de revue que les employés ne peuvent en évaluer avec soin.

Une autonomie fondée sur des niveaux de risque offre un modèle plus praticable. Les tâches réversibles et à faible impact peuvent se dérouler automatiquement, tandis que les actions sensibles exigent une validation indépendante.

Parmi les travaux à moindre risque figurent la rédaction d’explications, la collecte de preuves et le signalement d’anomalies. Les travaux à plus haut risque incluent la modification des coordonnées de paiement, le déblocage de fonds ou la modification des accès.

La réversibilité doit influencer le niveau de contrôle. Un rapport erroné peut être corrigé, tandis qu’un paiement externe ou un enregistrement supprimé peut causer des dommages durables.

Le profil de risque du NIST organise la gestion des risques liés à l’IA autour de la gouvernance, de la cartographie, de la mesure et de la gestion. Cette approche par cycle de vie convient mieux aux agents ERP qu’une approbation ponctuelle.

Le risque d’un agent évolue lorsque ses outils, son modèle, ses sources de données, ses autorisations ou sa finalité métier changent. Chaque modification doit déclencher une réévaluation et des tests ciblés.

Les tests doivent inclure des entrées adversariales et des exceptions métier réalistes. Une démonstration reposant sur des données propres ne révélera pas comment un agent se comporte face à des instructions contradictoires.

Les équipes doivent également tester les défaillances partielles. Un système en aval peut expirer après qu’un agent a réalisé une étape, mais avant qu’il n’enregistre la suivante.

Sans idempotence, qui empêche une exécution répétée de produire des effets en double, un agent peut soumettre à nouveau la même transaction pendant la récupération.

Ces problèmes ordinaires de fiabilité deviennent des enjeux de sécurité lorsqu’ils affectent des enregistrements financiers, des droits d’accès ou des données réglementées. La sécurité des agents ne peut pas rester distincte de l’ingénierie des systèmes.

Les garde-fous des fournisseurs face à la réalité des ERP personnalisés

SAP et Oracle peuvent sécuriser leurs propres plateformes d’agents, mais les clients contrôlent toujours les intégrations, les rôles, les données et les exceptions qui déterminent le risque réel.

Les fournisseurs d’ERP disposent d’un avantage structurel. Ils comprennent leurs modèles applicatifs et peuvent intégrer des agents aux côtés des services existants d’identité, de workflow et d’audit.

Les agents natifs peuvent hériter de métadonnées métier qui manquent à un modèle externe. Ils peuvent également utiliser des interfaces approuvées plutôt que d’imiter les actions des utilisateurs via un écran.

Oracle conseille à ses clients de séparer les responsabilités des agents et d’appliquer le principe du moindre privilège entre les agents coopérants. SAP décrit des vérifications d’identité, l’isolation des locataires, la validation des sorties et des pistes d’audit forensiques.

Ces contrôles répondent à de véritables préoccupations. Ils étayent également l’argument des fournisseurs selon lequel les agents intégrés sont plus sûrs qu’une automatisation tierce faiblement connectée.

Cet argument a ses limites. La plupart des grandes organisations n’exploitent pas un environnement ERP unique et propre, avec des configurations standard.

Elles exécutent des processus personnalisés dans plusieurs systèmes. Certaines applications restent sur site, tandis que d’autres se trouvent dans des clouds publics ou des services gérés par des fournisseurs.

Des partenaires, sous-traitants, banques, prestataires logistiques et unités opérationnelles acquises peuvent se connecter au même processus. Chaque frontière introduit un modèle d’identité et de contrôle différent.

Un agent financier natif peut toujours recevoir du contenu non fiable par e-mail. Il peut dépendre d’un analyseur de documents tiers ou envoyer un résultat vers une ancienne application de paiement.

Le workflow global n’est fiable qu’à hauteur de ces dépendances. La documentation de sécurité des fournisseurs ne peut pas prendre en compte chaque extension client.

Les agents externes présentent un compromis différent. Ils peuvent coordonner le travail entre des plateformes ERP, CRM, de communication et d’analytique concurrentes.

Cette indépendance peut réduire la dépendance vis-à-vis d’un fournisseur et soutenir des workflows plus larges. Elle place également une couche supplémentaire d’identité, d’orchestration et d’écosystème d’outils entre les utilisateurs et les enregistrements métier.

Le choix pratique n’oppose donc pas un logiciel natif sûr à un logiciel externe non sûr. Les deux approches créent des risques, mais elles les concentrent à des endroits différents.

Les agents natifs concentrent la confiance dans la plateforme, le cloud et le modèle de gouvernance du fournisseur ERP. Les agents externes répartissent la confiance entre connecteurs, identifiants, modèles et outils d’orchestration.

Les équipes de sécurité devraient évaluer l’ensemble du chemin d’action plutôt que d’accepter des étiquettes de catégorie. Un produit natif peut devenir dangereux à cause d’une configuration trop large.

Un produit externe peut réduire le risque s’il reçoit une autorité étroitement limitée et de courte durée, et s’il ne peut pas finaliser directement des transactions sensibles.

Les revues d’approvisionnement doivent refléter ces différences. Les questionnaires logiciels standard saisissent rarement la profondeur de délégation, le comportement de la mémoire, le traitement des prompts ou les autorisations au niveau des outils.

Les acheteurs devraient demander quelle identité apparaît dans le journal ERP et si elle identifie l’utilisateur d’origine. Ils devraient également demander comment une politique accompagne une tâche lors des transferts entre agents.

D’autres questions essentielles concernent les mises à jour de modèles, le contexte conservé, la résidence des données, la réponse aux incidents et l’accès client à une télémétrie détaillée.

Le fournisseur doit expliquer comment les administrateurs peuvent suspendre immédiatement un agent. Ce contrôle doit révoquer les identifiants actifs et interrompre les actions en attente, pas seulement masquer l’interface.

Les clients ont également besoin de preuves sur la gestion des changements. Le comportement d’un agent peut évoluer après une modification du modèle, du prompt système, de la définition d’un outil ou d’une source de récupération.

Une mise à jour d’application traditionnelle modifie généralement du code déterministe. Une mise à jour de modèle peut modifier les décisions même lorsque le workflow environnant reste inchangé.

Les tests de sécurité doivent donc se poursuivre après le déploiement. Les équipes devraient exécuter des tâches représentatives et des scénarios d’abus chaque fois qu’un composant significatif change.

Elles devraient comparer les résultats entre versions et conserver suffisamment de preuves pour enquêter sur les régressions. Un test réussi il y a six mois ne dit pas grand-chose sur un agent modifié.

La pression concurrentielle peut saper cette discipline. Les fournisseurs d’ERP veulent que les clients adoptent les agents, tandis que les dirigeants métier recherchent des gains de productivité mesurables.

Les équipes de sécurité peuvent subir des pressions pour approuver de vastes pilotes avant que les systèmes d’identité et de supervision ne soient prêts. Cet enchaînement transforme la gouvernance en projet de réparation.

Un déploiement plus sûr commence par des tâches limitées et des résultats observables. L’autorité ne s’étend qu’une fois que l’organisation peut expliquer, détecter et inverser le comportement des agents.

Trois signaux montreront si la sécurité ERP rattrape son retard

La prochaine phase sera déterminée par des identités propres aux agents, une application des règles au niveau des actions et des preuves issues d’incidents réels en production.

Le premier signal sera de voir si les plateformes ERP adoptent des identités distinctes et de courte durée pour chaque agent et chaque tâche déléguée. Les comptes de service partagés devraient devenir l’exception.

Une conception mature préservera l’utilisateur d’origine, l’identité de l’agent, la finalité et l’autorité tout au long du workflow. Les applications en aval devraient recevoir ce contexte avant d’autoriser une action.

Cela renforcerait l’argument selon lequel les agents IA des ERP peuvent fonctionner au sein de structures de responsabilité établies. Le recours continu à des identifiants trop larges l’affaiblirait.

Le deuxième signal consiste à vérifier si les fournisseurs et les clients appliquent des politiques au niveau de chaque transaction. L’autorisation d’utiliser un outil ne doit pas devenir l’autorisation d’exploiter toutes les sorties possibles de cet outil.

Les contrôles doivent prendre en compte le type de transaction, sa valeur, sa destination, les preuves relatives à sa source et sa réversibilité. Les opérations sensibles doivent exiger des vérifications indépendantes, en dehors du modèle qui les exécute.

Les équipes de sécurité doivent surveiller les lancements de produits afin d’identifier des fonctionnalités concrètes d’application des règles. Le discours marketing sur une IA responsable est moins utile que des contrôles configurables et des journaux exportables.

Elles doivent également déterminer si ces contrôles fonctionnent dans l’ensemble des applications connectées. Une protection limitée à l’interface d’un seul fournisseur ne couvrira pas un flux de travail multiplateforme.

Le troisième signal concerne la qualité des rapports publics sur les incidents. Les défaillances en production révéleront les points où les architectures théoriques échouent dans des conditions métier réelles.

Les divulgations utiles identifieront l’identité compromise, l’entrée manipulée, les outils concernés, les actions non autorisées et la méthode de confinement. De vagues références à une erreur d’IA n’aideront pas les défenseurs.

Les incidents doivent aussi préciser si une approbation humaine était en place et pourquoi elle a échoué. Ces éléments montreront si la supervision réduit réellement le risque ou se contente de transférer la responsabilité.

L’affirmation centrale à l’origine de l’avertissement de Google News se renforcera si les agents se développent plus vite que ces trois mécanismes de contrôle. Elle s’affaiblira si l’identité, l’application des règles et les éléments de preuve progressent de concert.

Les organisations ne doivent pas attendre une perte majeure avant de cartographier leur propre exposition. Elles peuvent commencer par répertorier chaque agent connecté à un processus ERP.

Cet inventaire doit inclure le responsable, l’objectif, le modèle, les outils, les sources de données, les identifiants, les points d’approbation et la procédure d’arrêt. Les entrées inconnues méritent une enquête immédiate.

Ensuite, les équipes doivent suivre quelques flux de travail à fort impact, depuis l’instruction jusqu’à la transaction finale. Les modifications de paiement, les attributions d’accès, les écritures comptables et les mises à jour de dossiers employés constituent de bons points de départ.

Cet exercice mettra en évidence les informations contextuelles manquantes entre les systèmes. Il révélera également les cas où un identifiant ou un outil détient davantage d’autorité que ne l’exige la tâche métier.

Les entreprises doivent ensuite classer les actions selon leur impact et leur réversibilité. Une recherche en lecture seule n’exige pas les mêmes contrôles que le déblocage de fonds ou la modification de données de référence.

Enfin, les responsables de la sécurité doivent tester la réaction de l’organisation lorsqu’un agent se comporte de manière incorrecte. La détection sans confinement laisse sans réponse la question la plus importante.

Les administrateurs peuvent-ils arrêter l’agent, révoquer son autorité, préserver les preuves, annuler l’action et identifier les dossiers concernés avant que les dommages ne se propagent ?

La sécurité ERP n’a pas besoin d’éliminer l’autonomie. Elle doit garantir que l’autonomie ne devienne jamais une autorité sans limites.

La prochaine étape pratique est simple : choisissez un flux de travail d’agent actif ou prévu et suivez chaque identité, outil, source de données et approbation auxquels il a recours. Si votre équipe ne peut pas expliquer cette chaîne, l’agent n’est pas prêt à obtenir un accès plus étendu.

Demandez qui peut l’arrêter, quelles preuves subsistent et quelles actions peuvent être annulées. Ces réponses comptent davantage qu’une nouvelle démonstration soignée.

Google News a fait remonter l’avertissement. Les équipes d’entreprise doivent désormais décider si leurs contrôles ERP encadrent les agents avec autant de rigueur qu’ils encadrent les personnes.