Quand des contrôles corrects laissent quand même fuiter : la leçon de CONTINUITY sur la sécurité des agents IA

Vous pouvez assembler un traceur de provenance, une couche d'autorisation, un moteur de politiques, des adaptateurs de protocole et des gardes d'exécution — chacun correct isolément — et livrer malgré tout un système qui laisse un agent IA faire une chose qu'il n'a jamais été autorisé à faire. C'est la découverte inconfortable du cadre de recherche CONTINUITY, et elle explique pourquoi « nous avons tous les contrôles » n'équivaut pas à « nous sommes sécurisés ».

La faille se cache dans les coutures

L'action d'un agent ne se produit pas en un seul endroit. Elle voyage : une instruction arrive, la provenance est étiquetée, l'autorisation est vérifiée, une politique est appliquée, un adaptateur la traduit, et enfin quelque chose s'exécute dans le monde réel. À chaque frontière entre composants, le contexte de sécurité critique — le qui et le pourquoi de l'action — peut être perdu ou corrompu. Les auteurs appellent cela la discontinuité du contexte de sécurité.

Chaque contrôle peut réussir ses propres tests isolément. La vulnérabilité ne vit dans aucune boîte, mais dans l'espace entre elles.

Quatre façons de rompre le contexte

• Abandonné : le qui et le pourquoi disparaissent, et un composant en aval approuve à l'aveugle.
• Élargi : une autorisation à portée étroite est traitée comme plus large qu'elle ne l'était.
• Réaffecté : l'action est rattachée à une cible différente de celle autorisée.
• Réinterprété : le sens de la requête change lors de sa traduction entre couches.

La solution : un contexte qui voyage avec l'action

CONTINUITY traite la composition comme un problème de premier plan. Il modélise chaque composant par un contrat de type assume-garantit et porte un contexte de sécurité authentifié à chaque transition, via des concessions racines signées, des engagements de provenance, des reçus de transition liés au rôle et des permis d'exécution liés à l'effet. La propriété garantie est l'intégrité de conséquence : aucun effet externe réel ne se produit sans une chaîne d'autorisation complète, vérifiable et à jour derrière lui.

Les chiffres comptent

Sur 2 560 instances d'attaque paramétrées réparties en 128 classes de défaillance, la configuration complète n'a commis aucun effet externe nuisible, a accompli les 700 tâches bénignes et a escaladé les 200 cas ambigus vers un humain plutôt que de deviner. Un contrôle qui bloque tout est inutile ; celui-ci a laissé passer le travail réel.

Ce qu'un responsable sécurité doit en retenir

Nul besoin de déployer CONTINUITY pour en tirer la leçon : cessez d'évaluer les contrôles isolément et suivez tout le chemin, de l'instruction à l'effet. Avant de connecter un agent à vos systèmes, mesurez le risque du modèle avec le scanner de risque de modèles et gouvernez chaque connecteur avec la vérification de risque des serveurs MCP. Un tas de contrôles corrects n'est pas un système sécurisé : la sécurité vit dans les contrats entre eux.