← Toutes les ressources
Note de discussionVersion 0.1

Fondements du confinement adversarial

Note de discussion préalable à la session, définissant la frontière du système, les hypothèses de menace, les couches de contrôle et les questions ouvertes pour le confinement d’agents autonomes capables.

Publiée le 24 juillet 2026

Objet et statut

Cette note établit une base technique pour PESAEAS Maroc n°1 à Rabat. Il s’agit d’un document de discussion, et non d’une spécification achevée, d’une affirmation de sécurité ou d’un consensus communautaire.

Le périmètre est le confinement : limiter ce qu’un système autonome peut observer, modifier, invoquer et transmettre lorsque son comportement ne peut être supposé coopératif. L’alignement des modèles, l’évaluation des capacités et la sécurité applicative générale comptent, mais ne remplacent pas une frontière de confinement défendable.

Le problème du confinement

Une sandbox conventionnelle suppose souvent que la charge est non fiable mais mécaniquement prévisible. Un agent autonome modifie cette hypothèse : il peut rechercher des chemins alternatifs, combiner des capacités bénignes en une séquence dangereuse, influencer les opérateurs ou s’adapter après le blocage d’une première tentative.

Le confinement doit donc être traité comme une propriété du système. Le modèle, les outils, les identifiants, l’environnement d’exécution, le réseau, les données, les opérateurs, la supervision et le mécanisme d’arrêt participent tous à la frontière. Un contrôle fort à un niveau ne compense pas un chemin sans restriction à un autre.

Hypothèses de menace

La discussion part des hypothèses suivantes. Elles sont volontairement prudentes et doivent être précisées pour chaque déploiement concret plutôt que considérées comme universelles.

  • Le système confiné peut découvrir des stratégies non anticipées par ses concepteurs.
  • Les appels d’outils, services externes, plugins et opérateurs humains peuvent devenir des chemins d’évasion indirects.
  • Les identifiants et permissions peuvent être plus larges que ne l’exige réellement la tâche.
  • La télémétrie peut être incomplète, retardée, désactivée ou manipulée pendant un incident.
  • La défaillance d’un composant ne doit pas étendre automatiquement l’autorité ou la portée externe du système.

Structure minimale de contrôle

Une conception d’enclave crédible doit expliquer comment les contrôles suivants fonctionnent ensemble et quel composant reste fiable lorsqu’un autre échoue.

  • Actifs et frontières de confiance explicites : identifier ce qui doit être protégé et ce que la charge peut atteindre.
  • Autorité refusée par défaut : accorder des capacités étroites pour une tâche, une durée et une destination définies.
  • Médiation complète : contrôler les transitions pertinentes d’outils, de données, de réseau, de fichiers et d’exécution.
  • Budgets de ressources : borner le temps, le calcul, le stockage, la création de processus, les tentatives et les appels externes.
  • Preuves indépendantes : enregistrer les décisions de politique et les événements de frontière hors du contrôle de la charge.
  • Récupération hors bande : conserver un chemin d’arrêt et de restauration que le système confiné ne peut autoriser.

Modes de défaillance à examiner

La note ne prescrit pas une implémentation unique. Elle demande à chaque implémentation de traiter des classes de défaillance récurrentes.

  • Évasion directe par une vulnérabilité de l’environnement d’exécution, du noyau, de l’hyperviseur ou du matériel.
  • Comportement de mandataire confus dans lequel un outil autorisé réalise une action inaccessible directement à l’agent.
  • Exfiltration de données par les sorties permises, les métadonnées, le temps ou un contenu encodé.
  • Épuisement des ressources dégradant la supervision, déclenchant un repli dangereux ou privant l’opérateur de contrôle.
  • Compromission de la politique, de la télémétrie, des mises à jour ou du plan de contrôle d’urgence.

Questions pour la session de Rabat

La session utilisera ces questions pour confronter cette base à des systèmes concrets.

  • Quelles actions doivent être médiatisées dans un déploiement minimal d’agent autonome ?
  • Où la politique doit-elle résider pour que l’agent ne puisse ni la réinterpréter ni la modifier ?
  • Quelles preuves permettent de distinguer une tentative bloquée d’une tentative non détectée ?
  • Quelles défaillances doivent fermer le système, et où un mode dégradé contrôlé est-il plus sûr ?
  • Quel est le plus petit profil de confinement utile qu’un ingénieur puisse implémenter et inspecter ?

Révision

Après la session de Rabat, la note sera révisée à partir des objections concrètes, exemples et questions non résolues soulevés pendant la discussion. Les révisions distingueront les changements d’hypothèses de menace des changements apportés à la structure de contrôle proposée.