Swarm

Bell–LaPadula et IA agentique : contrôler la confidentialité des flux dans Swarm

Fabrice Pizzi · IA agentique et cybersécurité

Dossier confidentiel, agent de synthèse et service externe : chemin de fuite, contrôle de destination et refus avant émission.
Ouvrir le GIFSchéma fixe
Dossier d’audit : le droit de lire ne donne pas le droit de transmettre à un service non habilité.

Un agent peut disposer d’un accès légitime à un document sans être autorisé à en transmettre le contenu à n’importe quel modèle, outil ou destinataire. Dans une architecture agentique, la confidentialité dépend donc de la circulation de l’information : sa lecture, son incorporation au contexte, sa transformation et les sorties qui peuvent en résulter.

Cette question complète celle de l’intégrité abordée avec Biba. Une proposition peut être admissible du point de vue de l’intégrité et contenir des informations que son destinataire n’est pas habilité à recevoir. L’autorisation d’agir et l’autorisation de divulguer constituent deux contraintes distinctes.

Bell–LaPadula fournit un cadre formel pour organiser ce second contrôle. Dans Swarm, son intégration associe classifications, habilitations et vérification de destinations, avec une couverture encore partielle des flux d’exécution.

La confidentialité comme propriété des flux

Le modèle de Bell et La Padula décrit des contraintes d’accès entre sujets et objets, associées à des niveaux de sécurité et à des catégories. Dans sa formulation usuelle, la lecture vers un niveau supérieur est interdite (no read up). La propriété étoile contraint les écritures afin d’empêcher qu’un sujet transfère une information vers une classification inférieure (no write down). Les opérations de lecture-écriture et les sujets de confiance demandent un traitement plus précis que ces deux raccourcis. [1]

Pour un système agentique, cette distinction entre lecture et sortie est essentielle. Un contrôle d’accès au document ne suffit pas si le contexte qui l’intègre peut ensuite être transmis à un service non habilité. La sécurité doit porter sur les frontières où les octets sont effectivement exposés.

Une habilitation de lecture ne constitue pas une autorisation de transmettre l’information à toute destination accessible à l’agent.

Scénario de risque : un audit autorisé, une transmission qui ne l’est pas

Imaginons une équipe qui confie à un agent la synthèse d’un audit interne. Le dossier décrit des actifs sensibles, leurs faiblesses et des mesures encore ouvertes. La politique de l’organisation le classe « Confidentiel — Audit ». L’agent peut le consulter pour préparer la restitution dans un espace habilité. Cette autorisation ne couvre pas, par elle-même, un service externe de reformulation ou une messagerie accessible à un autre public.

La rupture se produit lorsque l’agent choisit un outil pratique pour accomplir sa tâche et lui transmet le contexte. Sans contrôle de cette sortie, la requête peut emporter les noms d’actifs, les constats et les priorités de traitement. L’exposition existe dès l’envoi : une réponse finale expurgée ne retire pas les données déjà reçues par le service. Les conséquences possibles sont la divulgation d’informations d’audit, l’exposition d’un chemin d’attaque ou une perte de maîtrise sur la conservation et les destinataires des données.

Bell–LaPadula conduit à contrôler la destination avant cette transmission. Pour la sortie ordinaire considérée, le destinataire doit couvrir la classification de l’information : niveau suffisant et compartiment Audit présent. Un compte techniquement utilisable, une clé API valide ou une instruction du modèle ne constituent pas cette habilitation. Le modèle distingue ainsi l’accès légitime au dossier et le droit d’en divulguer le contenu. Bell et La Padula, 1976

Le contrôle attendu porte sur les octets engagés et le destinataire effectif. Il doit encore s’appliquer si le modèle propose un autre outil, un autre endpoint ou un autre compte. La classification seule ne remplace ni la vérification du prestataire, ni l’isolation du transport, ni les autres autorisations de l’action. La protection dépend de la médiation des voies réellement disponibles.

Scénario de risque : la synthèse confidentielle finit dans un journal partagé

Considérons maintenant un agent qui reçoit deux documents : un dossier « Confidentiel — Audit » et une note « Interne — RH ». Il prépare une synthèse qui réunit un problème d’habilitation et une information concernant l’organisation des équipes. Même courte, cette synthèse peut conserver les deux types d’information.

Une chaîne multiagent peut ensuite copier la réponse dans une mémoire commune, un ticket ou un journal d’erreur destiné à un public plus large. Si chaque transformation est traitée comme une donnée neuve dépourvue de contraintes, la classification se perd alors que l’information subsiste. Le risque concerne les lecteurs ultérieurs de ces supports : équipes non habilitées, autres agents ou destinataires d’un export. Il peut se matérialiser sans instruction hostile, par le fonctionnement normal d’une chaîne de restitution.

Une synthèse ne devient pas publique parce qu’elle est plus courte que ses sources. Dans le raisonnement conservateur retenu ici, le contexte combine le niveau maximal et l’union des compartiments. Une sortie doit rester compatible avec ce domaine. Un journal limité à « Interne », ou une destination qui ne couvre que RH, ne satisfait pas cette condition pour un contexte « Confidentiel — RH et Audit ».

Une synthèse copiée dans un journal partagé expose l’information ; les niveaux et compartiments contraignent la sortie.
Ouvrir le GIFSchéma fixe
Synthèse et journal : la classification doit suivre l’information et contraindre chaque destination.

Ce cas montre aussi la limite du simple marquage : il faut que les producteurs attribuent les classifications et que les consommateurs les conservent effectivement. Dans Swarm, les mécanismes de dominance, de combinaison et de contrôle des destinations existent ; leur propagation à tous les résultats, mémoires, journaux, exports et voies alternatives reste une condition de protection transversale. Une déclassification relève d’une procédure distincte, avec une autorité et un périmètre explicites ; elle ne se déduit pas d’une reformulation par l’IA.

Pourquoi ce risque prend de l’importance avec les agents

Une application qui lit, résume et appelle des outils relie des périmètres qui étaient auparavant séparés. Les injections indirectes peuvent chercher à détourner ces capacités ; une erreur de routage peut produire une exposition similaire. L’OWASP décrit notamment l’exfiltration de données par des instructions présentes dans des contenus externes. OWASP — Prompt Injection

La question n’est donc pas seulement « l’agent a-t-il le droit de lire ? », mais aussi « quelles informations a-t-il reçues et quelles destinations peuvent les recevoir ? ». Bell–LaPadula apporte un cadre pour cette seconde décision. Une architecture peut employer d’autres contrôles équivalents ; l’absence du nom du modèle ne prouve pas une fuite. Le risque apparaît lorsque les sorties pertinentes ne sont pas effectivement soumises à une politique de confidentialité.

Niveaux et compartiments dans Swarm

Le contrat de confidentialité de Swarm représente une classification par un niveau et un ensemble de compartiments. La relation de dominance exige simultanément un niveau suffisant et la présence de tous les compartiments requis. Une classification élevée ne compense donc pas un compartiment manquant.

Considérons une politique comportant les niveaux Interne et Confidentiel, ainsi que les compartiments RH et Audit. Un contexte classifié « Confidentiel, RH et Audit » ne peut être transmis à une destination limitée à « Confidentiel, RH ». Le niveau convient, mais le compartiment Audit manque. Une destination « Interne, RH et Audit » ne convient pas davantage : son niveau est insuffisant.

Les niveaux, leurs libellés, les compartiments et les habilitations appartiennent à la politique configurée ; les noms de ce scénario ne désignent pas une classification réglementaire.

Le contexte hérite des contraintes de ses sources

Un prompt peut réunir des instructions, une mémoire, un historique, un document et des paramètres structurés. Classifier seulement la pièce jointe en ignorant les autres éléments laisserait une partie du contexte hors du raisonnement de confidentialité.

Swarm calcule une classification combinée à partir de toutes les sources attribuées : le niveau le plus élevé et l’union des compartiments. Le principal doit être habilité à cette combinaison. Une source absente ou non classifiée ne devient pas publique par défaut.

L’admission fixe ce domaine de confidentialité avant le transport. Il correspond aux informations effectivement réunies, pas à l’habilitation maximale du principal. Un accès ultérieur incompatible exige un nouveau contexte autorisé ; augmenter implicitement le domaine d’une exécution rendrait les contrôles de sortie précédents insuffisants.

Cette propriété dépend de la provenance des classifications. Un agent ne peut pas rendre une donnée publique en lui ajoutant une étiquette dans sa réponse. La classification doit provenir d’une attribution contrôlée portant sur les contenus concernés.

Lier la décision au destinataire effectif

Une autorisation de sortie doit concerner la destination réellement utilisée. Le nom d’un fournisseur ou l’existence d’une clé API ne suffit pas à établir cette destination.

Le raccord de préparation de Swarm associe une destination attribuée à la connexion configurée, notamment à son endpoint, son modèle et son empreinte de configuration. La décision relit les informations courantes et refuse les discordances pertinentes. Cette liaison vise à empêcher qu’une destination approuvée soit remplacée entre la préparation et l’envoi.

Deux mécanismes doivent être distingués. L’opération de décision de transport vérifie la compatibilité sans émettre de requête. Le travailleur API dispose, pour les préparations classifiées liées à une admission, d’un contrôle au dernier usage avant la construction de la requête HTTP. Il revalide notamment l’admission, la fraîcheur de la configuration et la destination.

La portée de ce raccord est ciblée. Lorsqu’aucune admission correspondante n’est associée au tour concerné, le chemin historique conserve son comportement. La présence d’un contrôle dans une branche d’exécution ne permet donc pas de conclure que tous les appels fournisseurs sont soumis à Bell–LaPadula.

Une reformulation ne constitue pas une déclassification

Résumer un document, modifier son format ou supprimer quelques passages ne démontre pas que son contenu peut être divulgué. Une réponse brève peut encore révéler une information protégée, et une erreur peut contenir des éléments du contexte.

Le contrat de domaine de Swarm prévoit une classification de sortie, y compris pour les résumés et les erreurs. La propagation effective de cette classification à l’ensemble des résultats, mémoires, journaux et exports reste un raccord à achever. Une fonction qui calcule une classification n’établit pas à elle seule son application par tous les consommateurs.

La déclassification est une opération distincte, qui demande sa propre autorité et ses propres conditions. Swarm ne fournit pas actuellement de commande de déclassification humaine qualifiée. Une nouvelle révision de politique, un rôle administrateur ou une reformulation par un modèle ne remplace pas cet accord.

Réduire ou transformer un contenu ne suffit pas à réduire sa classification de confidentialité.

Ce qui existe et ce qui reste à établir

Swarm possède des mécanismes de politique révisionnée, de classifications et d’habilitations, d’attribution contrôlée d’objets, de combinaison des sources et d’admission immuable du contexte. Des lecteurs ciblés et le raccord du travailleur API ajoutent des frontières de contrôle concrètes.

L’intégration demeure néanmoins partielle. L’attribution de tous les producteurs, l’héritage des résultats, la médiation des accès fichiers et réseau, les descendants des agents et les parcours alternatifs doivent être considérés pour établir une confidentialité de bout en bout. Le statut de capacité globale de Swarm reste distinct de ces mécanismes ciblés.

Une politique de quarantaine permet par ailleurs de bloquer les émissions de préparation contrôlées par ce mécanisme. Elle ne constitue pas un confinement général du système et ne retire aucune information déjà transmise.

La vérification d’un tel ensemble doit porter sur les effets observables : accès légitime dans le périmètre prévu, refus lorsque le niveau ou un compartiment manque, revalidation après changement de politique, absence d’émission sur le chemin refusé et maîtrise des voies alternatives. L’existence d’un modèle formel ou de tests locaux ne suffit pas à démontrer l’ensemble de ces propriétés en déploiement.

Composer confidentialité et intégrité

Biba et Bell–LaPadula protègent deux dimensions complémentaires. Le premier contraint les flux d’intégrité ; le second organise les conditions de lecture et de divulgation. Leur composition exige que les sujets, objets et frontières contrôlées soient identifiés de façon cohérente.

Dans Swarm, les travaux portent sur cette articulation entre provenance, autorité, contexte et destination. La propriété recherchée est qu’une action autorisée ne puisse ni acquérir ses droits à partir du contenu qu’elle traite, ni exposer ce contenu à une destination incompatible avec sa classification.

La question opérationnelle devient alors : quelles informations cette exécution a-t-elle reçues, et quelles destinations sont effectivement autorisées à les recevoir ?

Références

[1] D. E. Bell et L. J. La Padula, Secure Computer System: Unified Exposition and Multics Interpretation, MTR-2997 Rev. 1 / ESD-TR-75-306, MITRE, mars 1976. Sections consacrées aux propriétés de sécurité, aux sujets de confiance et aux chemins de communication.

Code source et documentation : Swarm sur GitHub.