Sécurité d’Agent NAS : menaces, Rule of Two et limites

Périmètre et hypothèses de confiance

Ce que nous protégeons : les données et l’historique du NAS ; la frontière de l’autorité ; l’intégrité de l’enregistrement ; la traçabilité de la mémoire.
Ce que nous ne protégeons pas : ce qu’un agent fait en dehors du NAS ; l’isolation du calcul lui-même (c’est le travail du sandbox) ; tout ce qui se passe du côté du fournisseur de modèle.
Hypothèses de confiance : la base de confiance informatique (TCB) comprend la passerelle du NAS, le moteur de politiques et le service d’enregistrement ; l’hôte n’est pas compromis ; le sandbox isole le calcul. Si la TCB est compromise, les garanties de cette page ne tiennent plus.

La Rule of Two : un invariant de session

Trois propriétés : [A] la session a lu du contenu non fiable, [B] l’habilitation permet de lire des données sensibles, [C] l’habilitation permet de modifier un état protégé ou de communiquer vers l’extérieur. Quand les trois sont réunies dans une même session, l’appel qui déclenche C n’est pas autorisé automatiquement.

Scénario	A	B	C	Résultat
Résumer une page web dans une note sur la branche	Oui	Oui	Non (branche seulement)	Automatique : une écriture dans la branche ne compte pas comme C.
Après la lecture d’une page web, proposer une fusion dans `main`	Oui	Oui	Oui	Human Gate.
Lire seulement des données publiques, écrire dans une zone temporaire	Oui	Non	Non	Automatique.
Après la lecture d’un e-mail externe, envoyer un e-mail (sortie de données)	Oui	Oui	Oui	Validation ; refus si `secret` est concerné.

C’est l’Agents Rule of Two de Meta, mise en œuvre à la frontière du stockage. Meta souligne elle-même qu’il s’agit d’une heuristique pour réduire le risque, pas d’un point d’arrivée, et qu’elle ne remplace pas le moindre privilège ; nous l’utilisons de la même façon. Le mécanisme est décrit dans Trust Labels.

Modèle de menaces

Menace	Ce que le NAS peut imposer	Ce que le NAS ne peut pas faire	Risque résiduel
T1 Injection de prompt indirecte (via des fichiers, des pages web, des e-mails)	La Rule of Two ; la portée des habilitations ; les branches ; les validations.	Empêcher une injection de se produire, ou arrêter un comportement malveillant dans les limites de l’habilitation après une injection.	Mauvais usage à l’intérieur de l’habilitation.
T2 Fuite d’identifiants (un agent lit une clé de longue durée)	Les identifiants de longue durée ne sont jamais entre les mains d’une exécution ; un détecteur de secrets marque `secret` ; des TTL courts.	Empêcher un agent d’envoyer des données, dans les limites de son habilitation, vers une sortie autorisée.	Données qui sortent dans les limites de l’habilitation.
T3 Permissions trop larges et erreurs	Habilitations étroites ; branches ; suppression logique ; instantanés hors de toute habilitation.	Annuler des effets de bord en dehors du NAS.	Conséquences au-delà du NAS.
T4 Empoisonnement de la mémoire (y compris entre rôles)	Provenance et contamination ; quarantaine ; chargement automatique seulement si relu ; retour arrière.	Reconnaître des faits faux mais plausibles.	Un poison qu’un relecteur laisse passer.
T5 Habilitations volées ou rejouées	TTL court ; révocable ; liaison facultative au détenteur (DPoP, mTLS).	Empêcher un abus pendant le TTL.	La fenêtre du TTL.
T6 Fatigue d’approbation et validation par réflexe	Validations rares ; le NAS produit lui-même le diff ; approbations liées à une empreinte ; taux d’approbation surveillé.	Obliger les gens à regarder attentivement.	Erreur humaine.
T7 Falsification des journaux	Chaîne de hachage ; ancrage externe facultatif.	Sans ancrage, empêcher root de détruire le journal.	Un administrateur malveillant.
T8 Exfiltration de données (sortie, partage, résultats de recherche)	La sortie exige une action d’habilitation et une validation ; `secret` ne peut pas sortir ; les dérivés héritent des étiquettes.	Empêcher les fuites après l’approbation d’une personne ; les canaux cachés.	Fuites après approbation.
T9 Chaîne d’approvisionnement (compétences, serveurs MCP, plugins, modèles)	Le contenu des compétences et des serveurs MCP externes est traité comme `external` ; un répertoire de compétences peut être épinglé sur un commit ; le manifeste du runtime est écrit dans l’enregistrement.	Garantir que du code tiers est inoffensif.	Une version malveillante épinglée.
T10 Épuisement des ressources (bombes de branches, budgets épuisés, boucles de lecture)	Quotas ; TTL ; budgets ; disjoncteurs.	Distinguer une grosse tâche légitime d’un emballement.	Déni de service local.

Contrôles

Moteur de politiques : déterministe (style Cedar ou Rego), refus par défaut, et en cas de refus il donne une raison lisible et la règle qui a correspondu ; il n’appelle pas de LLM.
Courtier d’identifiants : les clés de longue durée restent chez le courtier ; il n’émet, pour une exécution, des jetons aval de courte durée que dans le cadre d’une action de sortie approuvée.
Isolation et clés : un Home et un espace de chemins par rôle ; la classe de rétention sensitive utilise un domaine de clés distinct.
Chaîne d’approvisionnement : le contenu des compétences, des serveurs MCP et des plugins est traité comme external ; au début d’une exécution, les compétences et versions utilisées sont écrites dans l’enregistrement.

Limites assumées

Ce n’est pas une défense contre l’injection de prompt. Il en limite les conséquences et les rend visibles.
Des permissions légitimes à l’intérieur d’une habilitation peuvent toujours être détournées.
Il ne peut rien contre les effets de bord en dehors du NAS : un e-mail déjà envoyé, une API déjà appelée.
Les canaux cachés et les canaux auxiliaires sont hors du périmètre.
Si la TCB est compromise, les garanties tombent.
Les gens se trompent : les validations réduisent ce risque mais ne peuvent pas le supprimer.
La contamination est prudente et apporte de la friction et des faux positifs ; elle demande des réglages et des raisons de refus visibles.
L’effacement cryptographique ne protège que les copies que nous contrôlons.

Réponse aux incidents

Disjoncteur : revoke_run et revoke_role révoquent aussitôt les habilitations et gèlent la branche.
Retour arrière : restaurer l’arbre concerné à un commit antérieur.
Traçage : utiliser le manifeste de lecture et la chaîne d’enregistrements pour retrouver ce qu’une exécution a lu, ce qu’elle a écrit et quelles notes elle a touchées.
Nettoyage : utiliser Cascade Forget pour supprimer les dérivés concernés, et délivrer un rapport.

Observabilité et audit

Trois sortes de données : l’enregistrement (les événements), le manifeste de lecture (l’ensemble des entrées), et les métriques et traces.
**explain(commit) :** renvoie quelle exécution et quelle habilitation ont produit un commit, quelles validations il a franchies, ce qui a été lu et les entrées dont il dépend.
Intégration à l’observabilité existante : une exécution correspond à un span OpenTelemetry GenAI, avec les habilitations et les validations attachées comme événements ; les enregistrements peuvent être exportés en JSON Lines ou envoyés à un SIEM.
Métriques : taux d’émission et de refus des habilitations ; longueur de la file des validations, taux d’approbation et délai d’approbation ; nombre et âge des branches ; fraîcheur des index ; consommation des budgets ; résultats de vérification de la chaîne d’enregistrements.
Vie privée et rétention : par défaut, seules les métadonnées sont enregistrées, jamais le contenu ; la rétention des enregistrements et la suppression du contenu sont indépendantes ; lire l’enregistrement lui-même exige une habilitation.

Citer cette page

Des adresses stables et une citation suggérée, pour les personnes, les moteurs de recherche et les agents.

URL canonique: https://agentnas.com/fr/security/
Version Markdown: https://agentnas.com/fr/security/index.md
Citation suggérée: Agent NAS project. “Sécurité.” agentnas.com, 2026-11-11. https://agentnas.com/fr/security/

Périmètre et hypothèses de confiance #

La Rule of Two : un invariant de session #

Modèle de menaces #

Contrôles #

Limites assumées #

Réponse aux incidents #

Observabilité et audit #