Les recommandations de CISA sur les tokens IA avertissent que l’usage peut devenir une attaque

CISA et des agences alliées de cybersécurité avertissent que la consommation d’IA peut devenir une menace pour la sécurité avant même qu’un système ne tombe en panne. Les recommandations de CISA sur les tokens IA traitent des attaques de type denial-of-wallet, des abus délibérés qui font grimper les frais facturés à l’usage d’une organisation. Leur portée dépasse les factures imprévues : les plafonds de dépenses et l’épuisement des capacités peuvent aussi interrompre des tâches qui dépendent de l’IA.

La couverture cybersécurité d’octobre d’ExecutiveGov a daté l’article du 23 octobre 2026. La tension centrale est simple. Les entreprises veulent des systèmes d’IA qui poursuivent leur travail au cours de tâches complexes, mais cette activité continue consomme aussi des ressources. Un système qui poursuit de manière fiable une tâche non autorisée ou inefficace crée un autre type de problème de fiabilité.

Cette préoccupation apparaît déjà dans le cadre de sécurité d’OWASP et dans la documentation de Microsoft sur la sécurité en entreprise. Les recommandations l’inscrivent dans une discussion sur les achats et la résilience opérationnelle. Les acheteurs d’entreprise, les développeurs et les équipes de sécurité sont désormais confrontés à une question commune : qui décide qu’un workflow d’IA en a fait assez, et qui peut arrêter ses dépenses ?

Les recommandations de CISA sur les tokens IA relient les dépenses à la continuité de service

Le changement déterminant est de considérer la consommation d’IA comme une dépendance opérationnelle qui mérite une supervision de sécurité.

La publication conjointe, disponible via le Centre canadien pour la cybersécurité, s’intitule AI token consumption. Les tokens sont des unités d’information que les modèles d’IA traitent ou génèrent. Ils aident à mesurer l’utilisation, même si le lien entre le nombre de tokens, le travail informatique et les frais dépend du service.

La publication distingue le préjudice financier de l’épuisement de l’accès. Les attaques de type denial-of-wallet augmentent délibérément les coûts facturés à l’usage. Les attaques de type denial-of-tokens consomment les allocations ou déclenchent des limites, entravant l’accès légitime. Les résultats se recoupent, mais ne sont pas interchangeables.

Les recommandations identifient également des causes opérationnelles ordinaires d’épuisement, dont la demande légitime et les applications inefficaces. Elles invitent les organisations à comprendre la consommation et les conditions de service avant de conclure des accords avec des fournisseurs. Pour les opérateurs d’infrastructures critiques, la préoccupation inclut la continuité lorsque les capacités d’IA se dégradent ou deviennent indisponibles.

Ce cadrage est important, car une protection financière peut elle-même devenir une contrainte de disponibilité. Arrêter la consommation protège un budget, mais un arrêt indiscriminé peut interrompre un travail important. Poursuivre la consommation préserve temporairement l’accès, mais expose l’organisation à de nouvelles dépenses.

L’implication pratique est un conflit entre des objectifs concurrents. La finance veut une exposition prévisible. Les opérations veulent un accès fiable. Les équipes produit veulent mener les tâches à bien. La sécurité veut contenir les comportements suspects. Un déploiement d’IA doit prévoir un moyen explicite de résoudre ces objectifs lorsqu’ils entrent en conflit.

Prenons l’exemple illustratif d’un assistant documentaire d’entreprise utilisé pour des questions courantes et des investigations opérationnelles urgentes. Les deux activités pourraient dépendre du même compte de modèle sous-jacent. Une tâche d’arrière-plan inefficace devient déterminante si elle consomme les ressources nécessaires à l’investigation urgente.

Cet exemple n’établit pas qu’une organisation donnée a subi un tel incident. Il montre pourquoi l’emplacement de la limite de dépenses importe. Une limite associée à un compte entier produit des conséquences différentes d’une limite associée à un workflow individuel.

Il modifie aussi la manière dont une démonstration réussie doit être interprétée. Une démonstration établit qu’un assistant peut accomplir certaines tâches dans certaines conditions. Elle n’établit pas le comportement du service lorsque la demande évolue, que des dépendances échouent ou qu’une activité autorisée devient excessive.

Pour les acheteurs, cela crée un écart entre les preuves de capacité et les preuves opérationnelles. Les premières répondent à la question de savoir si le système peut réaliser le travail. Les secondes répondent à celle de savoir si l’organisation peut continuer à l’utiliser dans des conditions défavorables.

Les recommandations de CISA sur les tokens IA rendent cette seconde question plus difficile à laisser en dehors du processus d’achat. Le sujet doit être abordé aux côtés de la disponibilité du service, des attentes en matière de reprise et de la responsabilité en cas de défaillance.

La pression s’exerce sur les acheteurs qui ne peuvent pas voir les workloads individuels

Une facture d’IA agrégée ne peut pas expliquer si un workflow individuel mérite de continuer à s’exécuter.

La pression immédiate s’exerce sur les organisations qui achètent des capacités d’IA via des applications, des intégrations et des services partagés. Leur défi consiste à relier la consommation à un objectif métier. Sans ce lien, une hausse de l’utilisation est de peu d’aide lors d’un incident.

Une tâche inhabituellement coûteuse peut être légitime. Elle peut impliquer une analyse difficile, une vaste collection de documents ou des tentatives répétées de résoudre des preuves contradictoires. Le même profil de dépenses peut aussi refléter une intégration défaillante ou un abus délibéré.

Cette ambiguïté rend les jugements simples peu fiables. Une consommation élevée n’établit pas une intention malveillante. Une faible consommation n’établit pas un comportement sûr. La question pertinente est de savoir si l’activité reste autorisée, proportionnée et utile.

Les équipes achats ont donc besoin de preuves concernant les limites de contrôle, plutôt que de formulations rassurantes sur la surveillance. Un tableau de bord peut afficher un problème sans l’empêcher. Une alerte peut prévenir une personne qui n’a ni l’autorité ni les moyens techniques d’intervenir.

La documentation de Microsoft sur la consommation d’IA non bornée décrit l’épuisement des ressources par des prompts exigeants, des requêtes répétées et une activité excessive des agents. Elle recommande des contrôles sur les appels aux modèles et les services en aval, notamment des quotas, du confinement et des limites à l’expansion des agents. Microsoft note également que les incidents malveillants largement médiatisés restent limités.

Cette dernière réserve est importante pour les acheteurs. Un modèle de menace crédible justifie la préparation, mais ne justifie pas de considérer chaque hausse de coûts comme une attaque. De bonnes décisions d’achat exigent de distinguer un mécanisme démontré de la prévalence mesurée des incidents.

La position de Microsoft offre également une comparaison utile avec le cadre de sécurité applicative d’OWASP. Microsoft décrit des contrôles dans un environnement de sécurité d’entreprise. OWASP classe la faiblesse de consommation sous-jacente à travers les applications. Ces perspectives renforcent le constat sans établir qu’un fournisseur particulier l’a résolu.

L’implication commerciale est que les fournisseurs devront expliquer de plus en plus clairement la portée de leurs contrôles. Une restriction s’applique-t-elle à un client, un département, une application ou une tâche individuelle ? Un opérateur peut-il isoler un travail suspect tout en préservant les activités sans rapport ?

Ces questions affectent également la responsabilité au sein de l’organisation acheteuse. Une équipe finance peut gérer le budget tandis que l’ingénierie gère l’intégration. La sécurité peut recevoir les alertes sans gérer le contrat. Un transfert de responsabilité non résolu peut laisser tout le monde informé et personne responsable de l’arrêt du workflow.

Pour les développeurs, la visibilité sur la consommation devient un élément du diagnostic du comportement applicatif. Savoir qu’un compte a davantage dépensé est moins utile que savoir quelle tâche a répété une action infructueuse. Des preuves utiles doivent relier la tâche, sa progression et les ressources qu’elle a consommées.

Pour les travailleurs du savoir, les conséquences prennent la forme de réponses retardées, de recherches interrompues ou d’assistants indisponibles. Ils contrôlent rarement l’allocation des ressources sous-jacentes. Leur expérience dépend de décisions prises par les achats et l’ingénierie bien avant l’interruption.

Les équipes qui examinent ces dépendances peuvent conserver les contrats approuvés, les décisions d’architecture et les procédures d’incident dans une base de connaissances techniques consultable. La documentation favorise une réponse coordonnée, même si elle ne peut remplacer les contrôles appliqués par l’application.

L’autonomie utile et la consommation bornée tirent dans des directions opposées

Le compromis central consiste à permettre à un système de poursuivre un travail utile tout en l’empêchant de continuer indéfiniment.

Un agent d’IA est un logiciel qui utilise un modèle pour sélectionner des actions au cours d’une tâche. Cela peut faciliter la délégation de travaux difficiles. Cela signifie également que la demande initiale ne décrit pas nécessairement toutes les actions qui suivront.

Un utilisateur peut autoriser une investigation sans savoir quelles recherches, quels documents ou quels services externes l’agent devra utiliser. Une limite restrictive risque d’interrompre prématurément un travail utile. Une limite ouverte laisse l’organisation accepter des conséquences qu’elle n’a pas entièrement définies.

La catégorie d’OWASP consacrée à la consommation non bornée identifie l’utilisation non contrôlée des modèles comme une source de dégradation du service et de préjudice économique. Ses exemples incluent les requêtes excessives et les requêtes gourmandes en ressources. Le cadre recommande des protections en couches, notamment la gestion des ressources, les délais d’expiration, la surveillance et la dégradation gracieuse, c’est-à-dire une fonctionnalité réduite qui préserve un service utile.

Cette perspective rend le sujet plus large que la longueur d’un prompt. Une courte instruction peut déclencher un workflow complexe. Compter uniquement les requêtes entrantes ne dit presque rien de tout ce que l’application fait après les avoir acceptées.

Un assistant de recherche illustratif pourrait explorer une collection de documents, examiner des passages contradictoires et demander davantage de preuves. Chaque action peut être raisonnable individuellement. La question métier est de savoir si la séquence fait toujours progresser l’investigation autorisée.

C’est là que l’achèvement d’une tâche et sa poursuite divergent. Une activité continue peut paraître productive dans une interface alors que la tâche sous-jacente ne progresse plus. Un flux de mises à jour de statut n’établit pas que l’action suivante mérite davantage de ressources.

La même tension apparaît lors de la reprise après erreur. Réessayer une action infructueuse résout parfois un problème temporaire. Répéter une action qui ne peut pas réussir ne fait que prolonger l’échec. Une application doit pouvoir distinguer ces situations à l’aide de preuves allant au-delà de la volonté du modèle de réessayer.

Cette distinction doit également façonner la manière dont les organisations évaluent l’autonomie. Une moindre intervention humaine n’est pas automatiquement meilleure si les opérateurs perdent la capacité de comprendre ce qui continue. Davantage d’intervention n’est pas automatiquement plus sûr si les approbations de routine deviennent des interruptions dépourvues de sens.

Une évaluation utile demande quelles preuves permettent au workflow de continuer. A-t-il obtenu de nouvelles informations ? Une dépendance a-t-elle changé ? A-t-il achevé un résultat intermédiaire significatif ? Il s’agit de questions analytiques sur la progression, plutôt que d’affirmations selon lesquelles un produit actuel y répond de manière fiable.

La responsabilité s’étend également au-delà du fournisseur du modèle. Une application décide quel travail demander, quels outils exposer et comment gérer les tâches inachevées. Ces décisions influencent l’exposition, même lorsque le modèle sous-jacent se comporte comme prévu.

Cela explique pourquoi changer de modèle ne peut pas être supposé résoudre le problème. Un modèle moins gourmand en ressources peut réduire le coût de chaque action. Cela n’établit pas que l’application choisira un nombre approprié d’actions.

Les orientations de la CISA sur les jetons d’IA s’inscrivent donc dans une discussion plus large sur l’autorité déléguée. Autoriser un système d’IA à poursuivre un objectif devrait inclure une limite définie concernant les ressources qu’il peut engager.

Le problème de conception difficile consiste à préserver une marge de manœuvre utile à l’intérieur de cette limite. Les entreprises ont besoin de suffisamment de flexibilité pour les tâches complexes, tout en pouvant expliquer de manière crédible ce qui se passe lorsque la limite est atteinte.

Le logiciel autour du modèle détermine la limite de dépenses

Le jugement d’un modèle et l’autorisation de dépenser accordée à une application sont deux décisions distinctes.

L’avis de l’Australian Signals Directorate sur les environnements d’exécution pour l’IA agentique, publié le 11 septembre 2026, attire l’attention sur le logiciel environnant. Un environnement d’exécution est la couche logicielle qui relie un modèle aux outils, aux données, à la mémoire et aux contrôles d’exécution.

L’avis soutient que les organisations devraient évaluer cette couche comme une source distincte de risques opérationnels et de sécurité. Il met notamment l’accent sur les autorisations, la surveillance, la supervision et les interactions des modèles avec les systèmes connectés. Cela offre un complément architectural utile aux orientations sur les jetons.

Cette distinction importe, car un assistant peut recommander une action sans détenir l’autorité nécessaire pour l’exécuter. L’application qui entoure le modèle détermine si l’action a lieu. La même séparation peut s’appliquer à l’autorisation d’une consommation supplémentaire de ressources.

Dans cette perspective, une limite de dépenses devrait relever d’une décision de l’application que le modèle ne peut pas simplement contourner par le dialogue. Demander à un modèle de rester économe diffère de l’imposition d’une restriction applicable. La première exprime un objectif ; la seconde modifie les comportements autorisés.

Des recherches soumises en septembre ajoutent une préoccupation technique plus ciblée. Une prépublication sur l’état facturable persistant examine le contenu d’outils externes conservé entre les interactions d’un agent. Les auteurs indiquent que le contenu retenu peut devenir une entrée facturable récurrente lorsque des requêtes ultérieures l’incluent de nouveau.

Leur étude teste des attaques et des défenses côté hôte dans des flux de travail contrôlés. Ses conclusions concernent la gestion des informations conservées, plutôt que des preuves d’une compromission généralisée des entreprises. En tant que prépublication, elle mérite un examen attentif et une réplication indépendante avant toute conclusion générale sur les risques de déploiement.

Cette recherche met néanmoins en évidence une distinction importante entre accepter une information et payer à plusieurs reprises pour son traitement. Une réponse d’outil peut rester dans un flux de travail alors que son objectif immédiat a pris fin. Les décisions de conservation méritent donc une attention au même titre que les décisions d’accès.

Une enquête documentaire illustrative rend le problème concret. Un assistant récupère un long rapport pour répondre à une question précise. Si l’application continue de fournir ce rapport lors d’actions de suivi sans lien, ce traitement continu nécessite sa propre justification.

Supprimer systématiquement toutes les informations ne constitue pas une réponse générale adéquate. L’assistant peut avoir besoin d’éléments antérieurs pour résoudre des contradictions ou expliquer sa conclusion. La question architecturale est de savoir quelles informations restent nécessaires et comment l’application rend ce jugement visible.

C’est également à ce niveau que les comparaisons entre fournisseurs deviennent plus pertinentes. Les acheteurs peuvent comparer la gestion de l’historique des tâches, de l’intervention et du redémarrage. Un contexte disponible plus long, c’est-à-dire les informations qu’un modèle peut prendre en compte lors d’une requête, ne résout pas ces questions opérationnelles.

De même, changer de fournisseur crée une nouvelle dépendance plutôt que de supprimer le besoin de gouvernance. Le service destinataire peut traiter les informations différemment. Une solution de repli qui préserve la disponibilité doit toujours être évaluée en matière d’exactitude, d’autorisations et d’exposition aux ressources.

L’implication centrale concerne le contrôle organisationnel. Les entreprises devraient comprendre quelles décisions relèvent du modèle, lesquelles relèvent de l’application et lesquelles exigent une autorité humaine. Brouiller ces responsabilités rend plus difficile l’enquête sur les dépenses excessives comme sur les interruptions inutiles.

L’avertissement est crédible, mais la prévalence des attaques reste incertaine

Une voie d’attaque plausible ne permet pas d’établir la fréquence à laquelle les attaquants l’exploitent ni l’ampleur des dommages qu’ils causent.

Les sources disponibles justifient de considérer la consommation excessive comme un enjeu de sécurité et de résilience. Elles ne fournissent pas de mesure exhaustive des incidents malveillants de déni de portefeuille dans les entreprises. Cette incertitude devrait rester visible dans la couverture de l’avertissement.

Cette distinction importe, car plusieurs défaillances différentes peuvent produire des symptômes similaires. Une requête malveillante, un défaut logiciel et une tâche légitime étonnamment complexe peuvent tous accroître la consommation. Un pic de dépenses ne peut à lui seul déterminer quelle explication est correcte.

Qualifier chaque pic d’attaque déformerait le signalement des incidents. Qualifier chaque pic de demande ordinaire masquerait les abus. Les organisations ont besoin d’éléments suffisants au niveau des tâches pour enquêter avant de retenir l’une ou l’autre interprétation.

Les affirmations relatives aux contrôles de protection ont également une limite importante. Un seuil configuré montre qu’un paramètre existe. Il n’établit pas la rapidité de l’application, les activités qu’il couvre ni si des travaux dépendants se poursuivent ailleurs.

Une alerte présente une affirmation encore plus limitée. Elle établit que le système peut avertir quelqu’un dans des conditions spécifiées. Les acheteurs doivent néanmoins comprendre les délais de notification, les responsabilités d’escalade et les actions possibles après la notification.

De même, une démonstration de confinement réussie doit être interprétée dans les conditions où elle a été testée. Arrêter une charge de travail artificielle prouve quelque chose d’utile concernant ce test. Cela n’établit pas automatiquement une protection contre chaque flux de travail, intégration ou schéma d’abus.

La question sceptique la plus importante concerne les conséquences métier. Un contrôle qui arrête une consommation excessive peut aussi interrompre un travail légitime. Évaluer la protection exige donc d’examiner à la fois l’exposition évitée et le travail que cette protection bloque.

Ce compromis devient particulièrement important lorsque les organisations utilisent les taux d’achèvement pour évaluer les assistants. Un arrêt agressif peut réduire les achèvements réussis. Une poursuite permissive peut améliorer le taux d’achèvement apparent tout en augmentant l’exposition. Une comparaison pertinente doit prendre en compte ces deux résultats.

Une autre incertitude concerne le point de départ et de fin de la responsabilité contractuelle. Un fournisseur peut assurer la surveillance tandis que le client configure l’application des règles. Un éditeur d’applications peut dépendre du service de modèle d’une autre entreprise. Les acheteurs devraient éviter de déduire la responsabilité du seul nom d’une fonctionnalité.

Les orientations elles-mêmes doivent également être décrites avec précision. Une publication sur la cybersécurité n’est pas automatiquement une nouvelle obligation légale. Toute affirmation concernant des obligations obligatoires nécessiterait une autorité distincte et applicable. Les sources établissent ici des orientations et des préoccupations techniques, plutôt qu’une échéance universelle de conformité.

Pour les équipes produit, la réponse raisonnable consiste en une validation proportionnée. Elles peuvent examiner si des tâches représentatives restent utiles sous des limites réalistes. Elles peuvent également tester si les tâches suspectes ou défaillantes s’arrêtent sans désactiver des travaux sans rapport.

Pour les lecteurs, la norme de couverture devrait demeurer tout aussi rigoureuse. Exigez des distinctions claires entre les contrôles recommandés, les comportements testés de manière indépendante et les incidents vérifiés. Ces catégories répondent à des questions différentes, et les traiter comme interchangeables rend les décisions d’achat moins fiables.

Les orientations de la CISA sur les jetons d’IA ont des conséquences importantes sans nécessiter d’affirmations exagérées. Elles identifient une dépendance que les organisations peuvent examiner dès maintenant, tout en laissant la fréquence et la gravité de l’exploitation dans le monde réel ouvertes à des éléments de preuve supplémentaires.

Surveillez l’application des règles, l’isolation des charges de travail et les tests indépendants

Les prochains éléments de preuve devraient montrer si les organisations peuvent contenir le travail excessif tout en préservant le service légitime.

Au cours des prochains mois, les signaux les plus utiles concerneront le comportement opérationnel plutôt que les promesses générales d’une IA plus sûre. La publication fournit une base claire pour poser des questions plus précises. Elle n’établit pas que les fournisseurs ou les acheteurs y ont déjà répondu.

Le premier signal est une documentation plus claire sur le comportement d’application des règles. Surveillez les fournisseurs qui distinguent les notifications des restrictions et expliquent précisément où chaque restriction s’applique. Cela renforcerait l’idée que la gouvernance de la consommation devient une capacité produit utilisable.

Le signal inverse affaiblirait cette évaluation. Si la documentation continue de décrire des budgets sans expliquer l’intervention, les acheteurs auront encore du mal à estimer leur exposition. Une fonctionnalité devrait être évaluée selon son effet opérationnel, y compris ce qui reste autorisé après son activation.

Le deuxième signal est la preuve d’une isolation des charges de travail dans les exigences d’achat et les tests d’acceptation. L’isolation des charges de travail consiste à restreindre une tâche problématique sans interrompre inutilement les autres tâches. Les éléments pertinents montreraient que les activités critiques se poursuivent tandis que les activités moins prioritaires ou suspectes s’arrêtent.

Cela étayerait le lien établi par les orientations entre les contrôles de consommation et la continuité. Un arrêt à l’échelle du compte peut encore être approprié dans certaines circonstances. Cependant, présenter ce comportement comme équivalent à un confinement sélectif masquerait une différence importante.

Le troisième signal est constitué de tests indépendants combinant confinement et achèvement utile des tâches. Surveillez les évaluations qui publient leurs hypothèses de charge de travail et expliquent pourquoi les tâches interrompues se sont arrêtées. Des résultats solides montreraient une exposition limitée ainsi qu’un achèvement crédible des travaux autorisés.

Des résultats qui ne mesurent qu’une réduction de la consommation laisseraient une lacune importante. Dépenser moins est facile si un assistant refuse suffisamment de travail. Le test difficile consiste à déterminer si les limites préservent l’objectif métier pour lequel le système a été acheté.

Ces signaux créent également un moyen pratique de comparer les offres concurrentes. Les acheteurs peuvent examiner l’application des règles documentée, le comportement d’isolation et les résultats évalués de manière indépendante. Cela produit une évaluation plus utile que de se fier uniquement aux affirmations sur les capacités des modèles.

Pour les développeurs, l’implication immédiate est de rendre le comportement opérationnel révisable. Une tâche devrait avoir un objectif identifiable, un responsable clairement désigné et une condition d’arrêt compréhensible. Ces propriétés facilitent le diagnostic des défaillances et le test des affirmations commerciales.

Pour les dirigeants d’entreprise, demandez à l’équipe responsable d’un service d’IA de suivre une tâche représentative, de son autorisation à son achèvement ou à son interruption. Identifiez qui est responsable de sa limite de ressources, qui peut intervenir et quels travaux sans rapport restent disponibles ensuite. Demandez des preuves issues d’un test réel plutôt que d’accepter un tableau de bord comme réponse. Utilisez les orientations de la CISA sur les jetons d’IA pour structurer cet examen autour de la continuité métier autant que des dépenses. Comparez ensuite le comportement observé avec l’accord de service et les responsabilités internes. Si ces versions divergent, résolvez le désaccord avant d’étendre le déploiement. La décision de déléguer un travail devrait s’accompagner d’une réponse claire sur la personne qui peut l’arrêter.