Biba et agents IA : quelle information peut devenir une décision ?
Les systèmes d’IA agentique mettent en relation des contenus de provenances hétérogènes et des capacités d’exécution : lire un dépôt, proposer une modification, invoquer un outil ou modifier une ressource. Leur sécurité dépend notamment de la manière dont une information peut influencer une décision protégée.
Une instruction issue d’un document, d’un résultat d’outil ou d’une mémoire peut être reprise dans une proposition, puis transmise comme une décision acquise. Cette transformation pose un problème d’intégrité : la circulation d’un contenu ne doit pas lui conférer une autorité d’exécution.
Le modèle de Biba fournit un cadre formel pour analyser ces flux. Son application aux architectures agentiques exige toutefois de distinguer le modèle, les mécanismes qui l’appliquent et les propriétés effectivement établies.
Le problème d’intégrité dans une architecture agentique
Considérons un agent qui lit un rapport contenant l’instruction de désactiver un contrôle. Le danger apparaît si cette instruction peut modifier la politique de validation ou déclencher une action protégée sans décision de l’autorité compétente. Le même mécanisme peut résulter d’un contenu hostile, d’une erreur ou d’une transmission qui perd son contexte.
L’identité de l’agent, son rôle de superviseur ou la persistance de sa mémoire ne résolvent pas cette difficulté. L’authentification établit une identité sous certaines hypothèses. L’autorisation détermine les opérations permises. L’intégrité contraint les influences et modifications admissibles. Ces fonctions doivent rester distinctes.
Les règles de Biba strict
Dans Integrity Considerations for Secure Computer Systems, Kenneth J. Biba formalise des politiques d’intégrité fondées sur des contraintes d’accès. Le rapport MTR-3153 de 1975 présente notamment une politique stricte ; une révision est référencée en 1977. [1, 2]
Un sujet désigne une entité active, par exemple un processus. Un objet désigne une ressource manipulée, par exemple un document ou un enregistrement. Pour des niveaux ordonnés, en notant I(s) l’intégrité du sujet et I(o) celle de l’objet, les accès ordinaires obéissent aux règles suivantes :
-
Lecture : I(s) ≤ I(o), soit l’interdiction de lire vers un niveau inférieur, ou no read down.
-
Écriture : I(s) ≥ I(o), soit l’interdiction d’écrire vers un niveau supérieur, ou no write up.
-
Invocation : un sujet ne peut invoquer directement un sujet d’intégrité supérieure.
La restriction de lecture vise les influences indirectes : un processus de confiance qui consomme librement des données de moindre intégrité peut ensuite compromettre les objets qu’il est autorisé à modifier. Les niveaux expriment une politique d’intégrité, pas une probabilité de vérité.
Scénario de risque : un rapport de test demande de désactiver le contrôle
Imaginons un agent chargé d’examiner l’échec d’une chaîne d’intégration. Il consulte un compte rendu produit par un outil ou fourni avec une contribution externe. Le document contient des résultats utiles, mais aussi une instruction demandant de désactiver une vérification de sécurité pour terminer la livraison.
Sans séparation entre contenu reçu et autorité d’exécution, l’agent peut reprendre cette instruction dans son plan, la présenter à un autre agent comme une décision, puis appeler un outil disposant de droits suffisants. L’auteur du rapport n’avait pas le droit de modifier la politique ; son texte obtient pourtant un effet par l’intermédiaire d’un composant mieux doté. Les conséquences possibles sont un contrôle désactivé, une modification non approuvée ou un déploiement dont les préconditions de sécurité n’ont pas été remplies.
Le problème ne se résume pas à reconnaître une phrase suspecte. Le NCSC souligne que les modèles ne constituent pas eux-mêmes une frontière robuste entre instructions et données ; le risque dépend aussi des outils et privilèges mis à leur disposition. NCSC — Prompt injection is not SQL injection
Biba fournit une règle pour empêcher qu’une influence de moindre intégrité modifie directement un objet protégé de plus forte intégrité. L’écriture vers le niveau supérieur et l’invocation ordinaire vers une cible supérieure sont interdites. Le composant protégé ne doit pas non plus contourner cette séparation en lisant librement un contenu de moindre intégrité. Biba, 1975, politique stricte
Cela n’oblige pas à ignorer le rapport. Une procédure de confiance peut examiner une demande attribuée, vérifier son mandat, ses paramètres et les validations requises, puis créer un nouvel objet admissible. La demande d’origine reste une demande ; elle ne devient pas sa propre approbation. Dans le noyau local des actions de confiance de Swarm, l’admission et l’approbation sont des étapes distinctes. Cette propriété ne permet pas d’affirmer que toute modification de fichier ou tout outil de livraison est déjà couvert par ce noyau.
Scénario de risque : une proposition devient un accord dans la mémoire des agents
Considérons une équipe d’agents qui prépare un changement sensible. Le premier propose de supprimer une mesure de contrôle afin de résoudre un blocage. Un second résume l’échange. La mémoire conserve finalement une phrase indiquant que la suppression est validée, alors qu’aucune autorité compétente n’a donné cet accord.
Un agent ultérieur peut lire cette mémoire et traiter la phrase comme une décision. La répétition du contenu et sa conservation ont effacé la différence entre proposition, discussion et approbation. Le risque porte sur l’intégrité de l’état de décision : une action peut être engagée sur un accord inexistant, une alerte classée à tort ou un registre modifié sans autorité suffisante. La trace peut elle-même devenir trompeuse si elle conserve seulement le résumé et perd les éléments d’origine.
Le contrôle attendu consiste à conserver la provenance et le statut des objets, puis à empêcher qu’un contenu de moindre intégrité écrive directement dans l’état d’autorisation. Une procédure de confiance doit pouvoir revenir à l’identité courante, au mandat, à la ressource, aux paramètres exacts et à l’accord requis. Un résumé signé ou une mémoire persistante ne démontre pas, à lui seul, l’existence de cet accord.
Dans Swarm, l’original et son empreinte sont conservés lors des admissions ciblées, et le demandeur n’est pas promu. La protection complète de ce scénario exige aussi que la mémoire, les transmissions interagents et les outils consommateurs passent par les frontières appropriées. La couverture du noyau local ne suffit pas à établir ce raccordement transversal.
Ce que le modèle apporte, et ce qu’il ne promet pas
Biba protège une propriété d’intégrité des influences et des modifications admissibles. Il ne démontre pas qu’une information est vraie, qu’un code est correct ou qu’une décision métier est pertinente. L’OWASP décrit justement des injections capables d’influencer le contenu et les décisions ; les contrôles doivent aussi limiter les privilèges et encadrer les actions sensibles. OWASP — Prompt Injection
Une organisation peut appliquer une séparation équivalente sans appeler son dispositif « Biba ». Le risque apparaît lorsque la chaîne confond les données examinées, les propositions générées, l’autorité de décision et le droit de produire un effet. Les modèles formels rendent ces frontières discutables et vérifiables ; leur seule présence dans une documentation ne les fait pas respecter à l’exécution.
L’admission de confiance comme frontière explicite
Un agent doit pouvoir analyser des sources externes et produire des propositions. Lui attribuer simultanément l’autorité de transformer ces propositions en décisions protégées créerait un chemin d’élévation d’autorité par le contenu.
Une proposition ne devient une décision autorisée qu’au travers d’une procédure de confiance explicitement définie.
Une telle procédure appartient à la base de confiance. Elle doit appliquer les contrôles adaptés : identité courante, mandat, ressource, paramètres exacts et validations requises. Elle peut créer un nouvel objet relié à la demande d’origine, sans modifier rétroactivement la provenance de celle-ci ni augmenter les droits de son auteur.
L’admission, l’approbation et l’engagement d’un effet constituent des opérations distinctes. La conformité syntaxique d’une demande ne démontre ni sa légitimité métier ni l’existence d’un accord. Un résumé ou une signature ne suffit pas davantage à établir la vérité de son contenu.
L’application dans Swarm
Swarm retient Biba strict comme référence d’intégrité. Son noyau Rust des actions de confiance utilise quatre niveaux ordonnés, I0 à I3, et un moniteur de lecture, d’écriture et d’invocation. Les parcours concernés associent ces règles aux contrôles d’identité, de rôle et de mandat.
Dans ce noyau local, une demande authentifiée et conforme au mandat peut créer une nouvelle action I2 en attente d’approbation. L’original et son empreinte restent conservés. Cette admission ne promeut pas le demandeur. L’interface refuse les opérations directes d’écriture et d’auto-élévation qu’elle expose.
Les réponses participent également aux flux d’intégrité. Un composant I3 ne dispose pas, par sa seule position, d’un droit de lecture ordinaire sur un objet I2. Pour certaines réponses métier et leurs rejeux, le noyau utilise un accusé limité à un identifiant et à un état, plutôt que de transmettre l’objet complet.
Biba et Bell–LaPadula dans Swarm
Les travaux Swarm articulent Biba pour l’intégrité et Bell–LaPadula pour la confidentialité. La protection des décisions contre des influences de moindre intégrité et le contrôle de la divulgation répondent à deux exigences complémentaires. Une autorisation d’intégrité ne remplace pas une habilitation de confidentialité.
Des mécanismes Bell–LaPadula sont déjà présents dans Swarm : classifications, compartiments, habilitations, politique révisionnée et contrôles ciblés. Leur intégration se poursuit. La présence de ces mécanismes ne constitue pas une garantie de confidentialité de bout en bout ; réciproquement, les limites propres à Biba ne signifient pas que la confidentialité est absente de Swarm.
Leur composition requiert d’identifier les sujets, les objets, les lectures et les destinations effectives, puis d’appliquer les contrôles pertinents aux frontières concernées. L’articulation détaillée avec Bell–LaPadula fera l’objet d’un article distinct.
Conditions de protection et limites
Une politique d’intégrité n’a d’effet que sur les accès effectivement soumis à ses contrôles. La qualification d’une architecture agentique doit donc considérer les outils, les fichiers, les processus descendants, les mémoires, les connecteurs et les voies alternatives pertinentes. Dans Swarm, la couverture du noyau local des actions de confiance doit rester distincte de l’extension des contrôles à l’ensemble de ces flux.
Biba ne détermine pas la véracité d’une facture, la pertinence d’un code ou l’innocuité sémantique d’une instruction. Il ne constitue donc pas, à lui seul, une protection générale contre les injections de prompt. Les règles métier, les habilitations, l’isolation et les contrôles des ressources conservent leurs fonctions propres.
Le caractère déterministe d’un contrôle ne démontre ni la justesse de sa politique ni la sécurité de l’architecture qui l’emploie.
La maîtrise des systèmes agentiques repose sur la continuité entre provenance, autorité, décision et effet. Biba contribue à formaliser cette continuité sur l’axe de l’intégrité. Sa composition avec les autres contrôles doit être évaluée sur des périmètres explicites, sans confondre existence d’un mécanisme et garantie globale.
Références
[1] K. J. Biba, Integrity Considerations for Secure Computer Systems, MTR-3153, 1975, section « The Strict Integrity Policy », pp. 28–29.
[2] K. J. Biba, révision ESD-TR-76-372, MITRE, avril 1977, notice CERIAS.
Code source et documentation de Swarm : github.com/mo0ogly/swarm.