Le Proof-of-Control d’Advanced AI Society ouvre un nouveau front dans la sécurité des agents

Advanced AI Society a publié Proof-of-Control pour consultation publique le 17 septembre, malgré des questions non résolues concernant la version, le périmètre et le degré de préparation du projet. La norme proposée demande aux agents IA de produire des preuves infalsifiables montrant que chaque action contrôlée est restée dans les limites de ses autorisations. Elle éloigne également la sécurité des agents de la confiance accordée aux journaux privés d’un fournisseur.

Ce changement est important, car les agents dépassent désormais la simple génération de texte. Ils peuvent appeler des outils, accéder à des dossiers, modifier des logiciels, communiquer avec des services externes et lancer des transactions. Un audit trimestriel ne peut observer chaque décision au moment où elle est prise, tandis qu’un journal contrôlé par l’opérateur de l’agent peut n’offrir qu’une assurance indépendante limitée.

Advanced AI Society affirme que plus de 80 responsables de la sécurité ont contribué à façonner son approche. Le groupe place ce travail au sein de Linux Foundation Decentralized Trust, ce qui donne au projet un cadre neutre pour sa gouvernance technique. Toutefois, une gouvernance neutre ne rend pas un projet complet, pas plus que des preuves cryptographiques ne garantissent qu’une organisation a choisi les bons contrôles.

Le Congrès aborde le même problème sous un autre angle. Une proposition bipartisane à la Chambre des représentants chargerait le NIST d’élaborer des pratiques de sécurité pour les agents couvrant la vérification continue, l’évaluation de la sécurité, les inventaires et les enregistrements résistants aux altérations. La rencontre entre des normes ouvertes volontaires et des exigences soutenues par le gouvernement constitue le véritable enjeu.

Le Proof-of-Control d’Advanced AI Society est plus qu’une annonce d’adhésion

Le changement important est la publication d’une proposition vérifiable d’inspection pour la validation des agents, et non le titre lié à l’adhésion qui l’entoure.

Advanced AI Society a présenté son annonce de septembre comme son entrée dans la Linux Foundation et LF Decentralized Trust. Pourtant, les archives de Linux Foundation indiquent que l’organisation est devenue membre associé de LF Decentralized Trust le 21 avril 2026. L’annonce plus récente associe donc une évolution antérieure de son adhésion à la présentation publique de Proof-of-Control et de son laboratoire associé.

Cette distinction est importante. L’adhésion place une organisation dans un réseau collaboratif, mais elle ne valide pas chaque affirmation ou conception technique que publie cette organisation. L’action déterminante consiste à intégrer une norme de vérification proposée dans l’environnement d’une fondation, où des contributeurs externes peuvent l’examiner, la contester et l’étendre.

L’archive d’adhésion d’avril identifie Advanced AI Society comme l’un des deux nouveaux membres associés. L’avis de lancement de septembre présente Proof-of-Control comme un laboratoire de LF Decentralized Trust et invite le public à formuler des commentaires.

Proof-of-Control est conçu autour d’une question directe : une partie indépendante peut-elle vérifier qu’un agent IA est resté dans les limites des contrôles qui lui sont attribués ? Un contrôle peut empêcher un agent de déplacer de l’argent sans approbation, restreindre les dossiers clients auxquels il peut accéder ou limiter les outils disponibles pendant une tâche.

La proposition se concentre sur la frontière de l’action, c’est-à-dire le point où un agent tente d’appeler un outil ou de produire un effet externe. Son architecture place une passerelle d’interception distincte à cette frontière. La passerelle évalue l’action proposée, bloque les actions qui sortent de la politique déclarée et émet des preuves concernant sa décision.

Cette conception est plus précise que les promesses conventionnelles concernant une IA responsable. Elle décrit où l’application des règles intervient, quelles preuves doivent être produites et comment une autre partie pourrait vérifier ces preuves. Advanced AI Society identifie également six domaines de vérification : la provenance, la confidentialité, la portabilité, l’autorisation, l’identité et la sécurité.

L’idée centrale du cadre est que le journal d’exécution d’un agent ne reste qu’une affirmation lorsque le même opérateur contrôle à la fois l’exécution et la tenue des registres. Un système compromis pourrait omettre une action, réécrire un enregistrement ou contourner la journalisation. Un mécanisme de vérification utile doit donc révéler les modifications et identifier les hypothèses dont dépendent ses preuves.

Le projet propose plusieurs niveaux d’assurance. Les niveaux inférieurs reposent sur les affirmations de l’opérateur ou sur l’accès d’un auditeur. Les niveaux supérieurs recherchent des enregistrements vérifiables de manière indépendante ou des barrières d’exécution qui empêchent une action contrôlée sans preuve correspondante.

Cela établit une distinction significative entre l’observation d’une action et sa contrainte. Un enregistrement infalsifiable peut aider les enquêteurs à établir ce qui a été consigné après un incident. Une barrière d’exécution correctement mise en œuvre peut empêcher une action couverte lorsque ses conditions d’autorisation échouent.

Proof-of-Control ne prétend pas déterminer si le modèle sous-jacent est sûr, précis ou aligné. Il ne décide pas non plus si une entreprise a accordé trop d’autorité à un agent. Il cherche à établir si les contrôles déclarés ont régi les actions incluses dans un périmètre défini.

Cet objectif plus restreint est une force, car il donne aux responsables de l’implémentation un élément testable. Il est aussi la source de la plus grande limite du projet. La preuve qu’un agent a suivi une politique faible ne démontre que sa conformité à cette politique faible.

Le Congrès transforme la vérification des agents en enjeu d’approvisionnement

La sécurité des agents passe d’une préférence technique à une condition pour faire affaire avec des acheteurs réglementés et le gouvernement fédéral.

Le Stop Rogue AI Act proposé chargerait le National Institute of Standards and Technology de publier des normes, des lignes directrices et des bonnes pratiques pour le déploiement sécurisé des agents. Selon les détails du projet de loi rapportés, ces travaux couvriraient les inventaires continus d’agents, les évaluations de sécurité, les journaux résistants aux altérations et la vérification des actions des agents.

La proposition émane des représentants Josh Gottheimer, démocrate du New Jersey, et Mike Lawler, républicain de New York. La plupart des organisations utiliseraient volontairement les pratiques NIST qui en résulteraient. Les sous-traitants fédéraux concourant pour de nouveaux marchés subiraient une pression plus forte pour les respecter.

Ce mécanisme compte davantage qu’une vaste déclaration réglementaire. Les exigences d’approvisionnement peuvent influencer les marchés technologiques sans imposer une architecture obligatoire à chaque organisation privée. Les fournisseurs adoptent souvent des contrôles destinés au gouvernement dans l’ensemble de leurs produits, car maintenir des systèmes de sécurité distincts accroît les coûts et la complexité.

Le NIST travaillait déjà sur ce domaine avant l’émergence de la proposition de la Chambre. En février, l’agence a annoncé une initiative sur les normes applicables aux agents couvrant l’interopérabilité, l’identité, l’autorisation et la sécurité. Elle a également sollicité les contributions des déployeurs, développeurs, chercheurs et fournisseurs d’infrastructures.

Le chevauchement avec Proof-of-Control est clair. Les deux démarches se concentrent sur une identité persistante, une autorité définie, des actions observables et des preuves qui subsistent au-delà du propre récit de l’agent. Toutes deux reconnaissent également que les agents interagissent avec les systèmes existants par l’intermédiaire d’outils, d’identifiants et d’interfaces de service.

Leurs rôles restent différents. Le NIST élabore des orientations dans le cadre d’un processus fédéral de normalisation et peut influencer les attentes en matière d’approvisionnement. Advanced AI Society propose une norme orientée vers l’implémentation au sein d’une communauté ouverte et souhaite voir se développer autour d’elle des outils de vérification indépendants.

La proposition de la Chambre exerce une pression sur trois groupes. Les fournisseurs d’agents doivent expliquer comment leurs systèmes identifient chaque agent et limitent ses autorisations. Les entreprises qui les déploient doivent tenir des inventaires et déterminer quels systèmes peuvent effectuer des actions importantes. Les fournisseurs de sécurité doivent produire des preuves que des évaluateurs externes peuvent examiner.

Les sous-traitants fédéraux sont confrontés au levier potentiel le plus clair. Un fournisseur pourrait considérer la vérification ouverte comme facultative lorsqu’il vend sur les marchés commerciaux ordinaires. Cette position devient plus difficile à maintenir lorsqu’un acheteur important demande des inventaires lisibles par machine, des enregistrements continus et des contrôles testables de manière indépendante.

Les assureurs et les auditeurs créent une autre source de pression. Un assureur évaluant un agent capable de déclencher des paiements a besoin de davantage qu’un document de politique interne. Il lui faut des preuves montrant quelle identité a agi, quelle autorité existait, quel contrôle a évalué la demande et si l’enregistrement résultant est resté intact.

Le même problème apparaît dans la santé. Un agent peut récupérer des dossiers médicaux, résumer un cas ou préparer une ordonnance. Un hôpital doit distinguer la confirmation de l’intégrité du dossier de la confirmation du caractère approprié de la décision clinique. Proof-of-Control traite du premier point, tandis que la gouvernance et l’examen professionnel déterminent toujours le second.

Les développeurs ressentiront le changement aux points d’intégration. La sécurité ne peut plus s’arrêter à la protection d’un point d’accès de modèle. Les équipes doivent prendre en compte les identifiants, les autorisations des outils, les chaînes de délégation, l’accès aux données et les effets secondaires dans chaque service qu’un agent peut atteindre.

C’est pourquoi la sécurité des agents devient un enjeu d’approvisionnement plutôt qu’une comparaison de fonctionnalités. Les acheteurs ont besoin de preuves qui restent significatives d’un fournisseur à l’autre. Les tableaux de bord propriétaires aident les opérateurs à gérer leurs propres systèmes, mais ils ne créent pas automatiquement un langage d’assurance commun pour les auditeurs, assureurs, régulateurs et clients.

La vérification ouverte remet en cause les journaux contrôlés par les fournisseurs

Le principal affrontement oppose des preuves tierces portables à des enregistrements de sécurité qui restent contrôlés par le fournisseur évalué.

Les journaux d’entreprise traditionnels ne sont pas inutiles. Ils soutiennent la réponse aux incidents, la supervision, le débogage et la conformité. Le problème est que la valeur d’un journal dépend de l’identité de son producteur, de sa capacité à capturer chaque parcours pertinent et de la possibilité pour quelqu’un de le modifier ultérieurement.

Les agents IA rendent ces questions plus difficiles. Leurs actions peuvent dépendre d’un contexte changeant, de données récupérées, de sorties de modèle, de réponses d’outils et d’autorisations déléguées. Un système peut enregistrer l’appel d’outil final sans préserver suffisamment de contexte pour établir pourquoi cet appel a été autorisé.

Proof-of-Control propose des preuves générées pendant l’exécution, et non reconstituées après un incident. Il recherche également des enregistrements portables que différentes parties peuvent interpréter sans obtenir un accès privilégié à l’ensemble de l’environnement de l’opérateur.

La présentation de la norme publiée par le projet décrit les preuves comme binaires, contemporaines, infalsifiables et transparentes quant aux hypothèses de confiance résiduelles. Binaire signifie que l’action contrôlée est restée ou non dans la limite déclarée. Cela ne signifie pas que le résultat plus global était correct.

Prenons l’exemple d’un agent d’achat autorisé à passer des commandes inférieures à une limite définie par l’entreprise. La couche de vérification pourrait enregistrer l’identité de l’agent, l’autorité déléguée, le montant évalué et le résultat de la politique. Elle pourrait également rejeter une commande dépassant cette limite.

Cependant, ces preuves n’établiraient pas que l’achat était nécessaire, que le fournisseur était fiable ou que le prix représentait un bon rapport qualité-prix. Il s’agit de jugements commerciaux distincts. La vérification montre si un contrôle explicite a été respecté, et non si l’organisation a conçu un contrôle pertinent.

Cette séparation est essentielle, car le langage de la sécurité regroupe souvent plusieurs affirmations distinctes. Un fournisseur peut décrire un agent comme sûr parce qu’il dispose d’autorisations, de journaux d’audit et d’options d’approbation humaine. Ces fonctionnalités ne prouvent pas qu’aucune voie de contournement n’existe ni que chaque action aux conséquences importantes passe par le point de contrôle.

La passerelle d’interception d’actions proposée par Proof-of-Control tente de résoudre ce problème. Elle se situe hors du processus de l’agent et assure la médiation des appels d’outils contrôlés. Pour que l’architecture fonctionne, l’agent ne doit disposer d’aucun autre identifiant ni chemin réseau lui permettant de contourner la passerelle.

Cette condition d’absence de contournement est difficile à garantir. Les environnements logiciels modernes comportent des comptes de service, des identifiants mis en cache, des processus en arrière-plan, des plug-ins et des routes réseau directes. Un vérificateur doit tester le système environnant, et non se contenter d’inspecter la sortie de la passerelle.

La proposition introduit également des compromis en matière de confidentialité. Les éléments de preuve de vérification doivent en dire suffisamment pour étayer une conclusion pertinente, sans exposer les prompts, les dossiers personnels, les poids du modèle ou des données commerciales propriétaires. Les affirmations cryptographiques peuvent limiter la divulgation, mais leur utilité dépend de la qualité des mesures et de l’implémentation sous-jacentes.

La portabilité soulève un autre défi. Deux fournisseurs peuvent utiliser des langages de politique, systèmes d’identité, environnements d’exécution et formats de journalisation différents. Un schéma partagé d’éléments de preuve peut normaliser une partie de ces variations. Il ne peut pas effacer toutes les différences dans la manière dont les contrôles d’origine ont été définis ou appliqués.

Une gouvernance ouverte offre une réponse crédible à cette fragmentation. Des spécifications publiques, des vecteurs de test, du code de référence et des modèles de menace documentés donnent aux acheteurs et aux chercheurs des éléments qu’ils peuvent examiner. Un programme d’assurance contrôlé par un fournisseur peut divulguer moins d’informations et évoluer sans accord extérieur.

La Linux Foundation fournit l’infrastructure institutionnelle nécessaire à ce travail. Elle peut soutenir la gouvernance communautaire, les règles de propriété intellectuelle, les processus de contribution et une supervision à long terme. Elle ne certifie pas que la conception a résolu le confinement des agents ou l’adoption en entreprise.

Cette limite doit rester visible. L’hébergement par une fondation prouve qu’un projet dispose d’un cadre de collaboration. Il ne prouve pas que chaque déploiement est conforme, que chaque preuve est complète ou que les clients accepteront les enregistrements qui en résultent.

Le projet de brouillon montre déjà pourquoi un examen indépendant compte

Les premières incohérences de Proof-of-Control révèlent la différence entre lancer une norme et l’établir.

L’annonce de septembre d’Advanced AI Society qualifie la publication de « brouillon de travail v1.0 » et indique que les commentaires publics restent ouverts jusqu’au 30 octobre 2026. Sa page plus détaillée consacrée à la norme identifie le document comme un « Working Draft v0.1 » et fixe au 7 octobre la date limite de commentaires.

La description de l’événement par la Linux Foundation le désigne également comme Proof-of-Control v0.1. Ces différences peuvent refléter des publications non synchronisées, un changement de plan de publication ou des étiquettes distinctes pour des artefacts connexes. Quelle qu’en soit la raison, l’ambiguïté sur la version et l’échéance est importante pour les contributeurs qui décident de ce qu’ils doivent examiner.

Une norme dépend d’identifiants stables. Les implémenteurs doivent savoir quelles exigences normatives s’appliquent, si un vecteur de test correspond au texte en vigueur et quand un changement incompatible est intervenu. Les auditeurs ne peuvent pas évaluer la conformité à partir d’une étiquette mouvante.

Cela n’invalide pas l’objectif du projet. Cela démontre pourquoi des dépôts neutres, des balises de publication, des registres de modifications et un suivi public des problèmes sont importants. Une norme ouverte doit rendre sa propre provenance vérifiable avant de demander aux fournisseurs d’agents d’en faire autant.

La présentation publique prévue le 23 septembre réunira des responsables de la Linux Foundation, des représentants d’Advanced AI Society, des investisseurs spécialisés dans la sécurité, des fournisseurs d’identité, des assureurs et l’Agentic AI Foundation.

Cet événement peut clarifier la gouvernance, mais le débat public ne résoudra pas à lui seul l’incertitude technique. Les contributeurs ont besoin d’une spécification normative, d’un modèle de menace explicite, de tests de conformité et d’implémentations reproductibles. Ils ont également besoin d’un processus permettant de décider quels mécanismes satisfont chaque exigence.

Le projet affirme que son dépôt inclut une implémentation de référence, des définitions de revendications lisibles par machine, des scénarios d’attaque et des vecteurs de test signés. Il présente l’implémentation comme une référence plutôt que comme un produit de production. Cet avertissement est important, car du code précoce peut démontrer la faisabilité sans satisfaire les exigences de sécurité opérationnelle.

Une passerelle de référence peut montrer comment évaluer une politique et créer des éléments de preuve signés. Une passerelle de production doit aussi résister au vol d’identifiants, aux conditions de course, aux tentatives de rejeu, à une télémétrie incomplète, à la compromission de clés, aux pannes d’infrastructure et aux opérateurs hostiles.

L’exhaustivité crée un autre problème difficile. Des enregistrements infalsifiables peuvent montrer que les entrées enregistrées n’ont pas été modifiées. Ils ne peuvent pas, à eux seuls, prouver que chaque action pertinente a été consignée. Un agent disposant d’une route non surveillée pourrait agir hors registre tout en laissant la chaîne de preuves visible cohérente en interne.

Le niveau renforcé proposé par Advanced AI Society répond à ce problème par le contrôle d’exécution. Selon ce modèle, une action couverte ne peut avoir lieu que si elle passe par le contrôle et produit une preuve. La question restante est de savoir si chaque action aux conséquences importantes est réellement couverte.

Les effets externes compliquent également le tableau. Une passerelle peut vérifier qu’un agent a envoyé une demande de paiement autorisée. Elle ne peut pas prouver automatiquement qu’une banque a réglé le paiement exactement comme prévu. L’assurance doit relier les preuves côté agent aux reçus provenant de systèmes externes.

Les chaînes d’identité introduisent des risques similaires. Un agent peut déléguer du travail à un autre, qui appelle ensuite un service tiers. Chaque transfert peut modifier l’autorité, le contexte ou l’exposition des données. Une norme crédible doit préserver l’attribution sans supposer qu’un seul jeton d’identité explique toute la chaîne.

La qualité du contrôle demeure la plus grande limite conceptuelle. Proof-of-Control évite explicitement de juger si une règle choisie était judicieuse. Cette séparation rend la conformité technique gérable, mais les organisations peuvent présenter la conformité comme une preuve plus large de sécurité.

Les acheteurs devraient résister à ce raccourci. Un agent vérifié peut suivre fidèlement une politique dangereuse. Il peut aussi produire des actions autorisées fondées sur un raisonnement erroné du modèle. La vérification à l’exécution complète les tests, la supervision humaine, l’analyse des risques et la réponse aux incidents. Elle ne les remplace pas.

L’affirmation la plus responsable du projet est donc la plus limitée. Il cherche à améliorer les preuves indiquant si les contrôles déclarés ont régi les actions couvertes. Des affirmations sur une sécurité complète des agents, la conformité réglementaire ou l’élimination de la responsabilité iraient au-delà de ce que ces preuves établissent.

La norme doit prouver qu’elle fonctionne sur de véritables piles d’agents

L’adoption dépendra de la capacité de Proof-of-Control à fonctionner avec des modèles hébergés, des systèmes locaux et des flux de travail multi-fournisseurs sans créer une couche de conformité isolée supplémentaire.

Les piles d’agents d’entreprise proviennent rarement d’un seul fournisseur. Une entreprise peut utiliser un modèle hébergé, un cadre d’orchestration interne, un fournisseur d’identité tiers, des bases de données cloud et des outils spécialisés de plusieurs fournisseurs. Chaque couche expose des contrôles et une télémétrie différents.

Proof-of-Control affirme que son modèle de frontière d’action peut fonctionner dans des configurations ouvertes comme fermées. Le fournisseur du modèle n’a pas nécessairement besoin de révéler ses poids ni ses données d’entraînement. La couche de vérification observe plutôt les actions contrôlées lorsque le système d’orchestration invoque des capacités externes.

Cette approche favorise les organisations qui contrôlent leur propre boucle d’agent. Elles peuvent insérer une passerelle, restreindre les identifiants et acheminer les appels d’outils via une frontière définie. Un service d’agent géré est plus difficile à traiter, car le fournisseur contrôle l’environnement d’orchestration et décide quelles preuves exposer.

Cette différence fait de l’architecture un critère d’achat. Les clients qui évaluent un agent géré doivent demander s’il émet des preuves vérifiables de manière indépendante, si ces preuves couvrent chaque appel d’outil pertinent et si un opérateur peut contourner le chemin déclaré.

Une équipe financière offre un test concret. Supposons qu’un agent prépare des factures, mette à jour des registres comptables et initie des virements bancaires. Le système de vérification doit distinguer la consultation d’un grand livre, la proposition d’un paiement, l’obtention d’une approbation et l’envoi de l’instruction finale.

Chaque action nécessite une identité, une source d’autorité, une politique applicable, une référence temporelle et un résultat. Le système doit préserver cette chaîne entre les outils sans divulguer de données de compte dans un registre de vérification public. Il doit également gérer une approbation révoquée ou un changement de politique pendant l’exécution.

Un agent d’ingénierie logicielle pose un test différent. Il peut inspecter du code privé, modifier des fichiers, exécuter des tests et demander un déploiement. Proof-of-Control pourrait vérifier à quel dépôt l’agent a accédé et si le déploiement exigeait une approbation nominative.

La norme devrait toujours tenir compte des effets indirects. Du code qui franchit une porte d’autorisation peut ensuite exposer des données ou modifier le comportement en production. Les preuves d’exécution montrent comment l’agent a franchi une frontière, tandis que la revue logicielle et les tests de sécurité évaluent l’artefact qu’il a produit.

Le secteur de la santé teste la confidentialité et l’autorité professionnelle. Un agent peut récupérer le dossier d’un patient dans le cadre de la délégation d’un clinicien et envoyer un projet d’ordonnance pour approbation. Les preuves doivent démontrer que l’accès est resté dans le cadre de l’autorisation sans divulguer les informations médicales sous-jacentes.

Ces scénarios exigent davantage qu’un journal signé générique. Ils nécessitent une sémantique commune pour les identités, les autorisations, l’évaluation des politiques, la conservation des preuves et le comportement en cas de défaillance. Un enregistrement qu’un vérificateur interprète différemment d’un autre ne crée pas d’interopérabilité.

Les tests de conformité détermineront donc la crédibilité du projet. Des équipes indépendantes devraient pouvoir exécuter la même suite de tests sur des implémentations distinctes et obtenir des résultats cohérents. Les tests négatifs devraient montrer comment les systèmes échouent lorsque les enregistrements sont modifiés, que les actions contournent la passerelle ou que l’autorité expire.

Les performances compteront également. Les agents effectuent souvent plusieurs appels d’outils au cours d’une même tâche. La génération continue de preuves ajoute du travail de signature, de stockage, de vérification et d’évaluation des politiques. Les entreprises auront besoin de données de latence et d’exploitation issues de déploiements représentatifs.

Les documents publics de Proof-of-Control mettent l’accent sur la vérification à la vitesse des machines, car l’examen humain ne peut pas suivre le rythme d’exécution des agents. Cette prémisse est raisonnable, mais l’automatisation peut aussi répéter une règle défaillante à la vitesse des machines. Les changements de contrôle doivent donc être gouvernés avec autant de soin que les changements de code.

La propriété opérationnelle est une autre question ouverte. Les équipes de sécurité peuvent définir des politiques de référence, les équipes applicatives intégrer des passerelles, les équipes d’identité gérer la délégation et les équipes de conformité conserver les preuves. Une norme qui suppose un propriétaire unifié aura du mal à s’imposer dans les grandes organisations.

Le projet peut toutefois réussir sans devenir la seule norme de sécurité des agents. Son modèle de preuve pourrait éclairer les orientations du NIST, les API des fournisseurs, les questionnaires d’assurance ou les modèles d’approvisionnement. Des concepts partagés peuvent influencer le marché même lorsque les implémentations varient.

Le risque le plus important est une adoption cérémonielle. Les fournisseurs peuvent revendiquer un alignement tout en ne couvrant que certaines actions, ou employer le langage de la vérification ouverte sans fournir de tests indépendants. Des niveaux de conformité clairs et des exigences vérifiables par machine peuvent limiter ce comportement.

Trois signaux détermineront si la vérification ouverte devient une infrastructure

Les trois prochains tests sont la cohérence de la spécification, l’implémentation indépendante et l’adoption réglementaire.

Le premier signal sera de savoir si Advanced AI Society résout les conflits du projet de texte concernant les versions et les échéances de commentaires. Une balise de publication publique devrait relier le texte normatif, les schémas, les vecteurs de test, l’implémentation de référence et l’historique des modifications.

Cette étape renforcerait l’argument central du projet. Une provenance vérifiable doit commencer par la norme elle-même. Si les artefacts restent étiquetés de manière incohérente, les entreprises hésiteront à bâtir autour d’eux des contrôles ou des contrats.

Le deuxième signal concerne l’implémentation indépendante. Le code de référence de l’organisation fondatrice peut prouver que ses auteurs ont construit ce qu’ils décrivaient. Une équipe distincte doit démontrer que la spécification communique suffisamment de détails pour produire des preuves et des résultats de vérification compatibles.

Les rapports d’implémentation utiles devraient documenter les échecs autant que les réussites. Ils devraient identifier la latence, la charge d’intégration, les frameworks d’agents non pris en charge, les contraintes de confidentialité et les éventuelles voies de contournement découvertes lors des tests. Les affirmations relatives à la production nécessitent des preuves provenant d’environnements hors du contrôle direct des auteurs.

Le troisième signal sera la manière dont le NIST et le Congrès définiront les exigences de vérification des agents. Si les orientations fédérales demandent des inventaires continus, des registres résistants à la falsification, des identités attribuables et des contrôles testables de manière indépendante, Proof-of-Control répondra à un besoin identifiable en matière d’achats publics.

Le projet gagnerait encore en dynamique si des sous-traitants fédéraux ou des acheteurs soumis à réglementation exigeaient des preuves portables plutôt que des captures d’écran de fournisseurs. Cette exigence récompenserait l’interopérabilité et créerait de la place pour plusieurs fournisseurs de vérification.

L’issue inverse affaiblirait l’argument en faveur d’un écosystème partagé. Les agences pourraient accepter des journaux conventionnels et des audits périodiques, ou le Congrès pourrait ne pas faire progresser la législation sous-jacente. Les entreprises pourraient alors considérer la vérification ouverte comme une expérimentation de sécurité facultative.

Le débat plus large de Washington sur l’IA demeure incertain. Des dirigeants du Congrès ont évoqué des garde-fous tout en soulignant une approche réglementaire légère et la concurrence avec la Chine. Cette tension rend des normes techniques ciblées plus plausibles qu’une loi globale sur l’IA.

La distinction entre législation et promulgation doit rester claire. La proposition de la Chambre sur la sécurité des agents n’est pas une politique fédérale établie. L’initiative existante du NIST est active, mais ses orientations finales et ses effets sur le marché sont encore en cours d’évolution.

Advanced AI Society dispose donc d’une fenêtre étroite pour influencer le vocabulaire émergent. Si elle peut démontrer des contrôles applicables avant que les règles d’achat ne se rigidifient, ses définitions pourraient façonner la manière dont les acheteurs décrivent l’assurance à l’exécution.

Les développeurs devraient surveiller si les frameworks d’agents courants ajoutent une prise en charge native des preuves portables. Les acheteurs d’entreprise devraient demander aux fournisseurs d’identifier chaque action contrôlée ainsi que toute voie contournant l’application des règles. Les équipes de sécurité devraient comparer l’intégrité des preuves à leur exhaustivité.

Les travailleurs du savoir sont également concernés. Un agent agissant sur les e-mails, documents, calendriers ou comptes financiers d’une personne peut avoir des conséquences avant que l’utilisateur ne les examine. Les utilisateurs ont besoin d’un registre compréhensible de l’autorité qu’ils ont accordée et de l’usage qu’en a fait l’agent.

L’initiative Proof-of-Control d’Advanced AI Society offre une réponse sérieuse à ce besoin, mais elle reste un projet préliminaire. Sa valeur viendra d’une interopérabilité testée, d’un périmètre précis et de preuves qui résistent à l’examen de parties autres que leurs créateurs.

La bonne prochaine étape n’est pas de supposer que la norme résout la sécurité des agents. Les acheteurs et les concepteurs devraient examiner le projet, tester l’exigence d’absence de contournement et soumettre des échecs d’implémentation concrets durant la consultation publique. La vérification ouverte ne devient une infrastructure que lorsque des participants indépendants peuvent reproduire ses affirmations et en identifier les limites.