# Agent NAS: documentation complète > Agent NAS est un stockage en réseau conçu autour de l’exécution (run) : chaque exécution d’un agent travaille dans une branche isolée et accède aux données par une habilitation étroite et de courte durée ; chaque modification peut être tracée et annulée ; et la mémoire, ce sont des fichiers ordinaires avec leur provenance. Il parle ce que les agents parlent déjà : fichiers, Git, S3 et MCP. État : concept et brouillon de spécification v0.2, novembre 2026. Pas encore d’implémentation de référence. Contenu sous licence CC BY 4.0. --- # Agent NAS : stockage en réseau pour agents d’IA > Agent NAS est un stockage en réseau conçu autour de l’exécution (run) : chaque exécution d’un agent travaille dans une branche isolée et accède aux données par une habilitation étroite et de courte durée ; chaque modification peut être tracée et annulée ; et la mémoire, ce sont des fichiers ordinaires avec leur provenance. Il parle ce que les agents parlent déjà : fichiers, Git, S3 et MCP. **Là où les agents travaillent et où vous gardez la main.** Un NAS qui prend l’exécution pour unité de base : chaque exécution a sa propre branche et sa propre habilitation, chaque modification peut être tracée et annulée, et la mémoire, ce sont des notes que vous pouvez lire, modifier et emporter. ## En un coup d’œil - **Catégorie**: Stockage en réseau pour agents d’IA, aussi appelé stockage natif pour agents (agent-native storage). - **Idée centrale**: L’unité d’accès est l’**exécution** (run), pas le compte : une exécution travaille sur une branche, accède aux données par une habilitation et laisse une trace dans le journal. - **Quatre promesses**: Circonscrit, récupérable, attribuable et inspectable. - **Substantifs centraux**: Tree, Commit, Principal, Run, Lease et Record. - **Concepts**: Neuf concepts nommés en trois groupes : Travail, Autorité et Connaissance. - **Interfaces**: Plan de données : montage, Git, S3, WebDAV. Plan de contrôle : MCP, HTTP, CLI. - **Spécification**: Brouillon v0.2 avec des niveaux de conformité de L0 Files à L4 Sync, chacun avec des tests d’acceptation exécutables. - **État**: Stade du concept et de la spécification, pas encore d’implémentation de référence. L0 et L1 peuvent être construits dès aujourd’hui avec des briques existantes. - **Licence**: Contenu sous licence CC BY 4.0. ## Pourquoi maintenant Quatre choses se sont déjà produites l’an dernier. - **Les agents travaillent dans des fichiers.** [AGENTS.md](https://agents.md), [Agent Skills](https://agentskills.io/specification), la mémoire adossée à Git ([Letta Context Repositories](https://www.letta.com/blog/context-repositories/)) et la [découverte dynamique du contexte](https://cursor.com/blog/dynamic-context-discovery), qui écrit les longues sorties dans des fichiers, ont fait des fichiers le support de travail des agents. - **Les erreurs sont rapides et coûteuses.** En avril 2026, un agent de programmation a utilisé un jeton trop large trouvé dans un fichier sans rapport et a [supprimé en 9 secondes la base de données de production d’une entreprise ainsi que les sauvegardes situées sur le même volume](https://www.theregister.com/software/2026/04/27/cursor-opus-agent-snuffs-out-startups-production-database/5224442). - **Les humains ne peuvent pas relire chaque étape.** Anthropic indique que les utilisateurs approuvent [93 % à 97 % des demandes d’autorisation](https://claude.com/resources/articles/auto-mode-default-in-claude-code) ; dans son expérience contrôlée, les participants n’ont repéré que 13,6 % des commandes dangereuses introduites à dessein. - **La mémoire est devenue une surface d’attaque.** [Plusieurs études de 2026](https://arxiv.org/abs/2606.04329) montrent qu’une instruction malveillante écrite dans la mémoire persistante survit d’une session à l’autre, et que se défendre uniquement à l’entrée ou à la récupération ne sert pas à grand-chose. Les fabricants de stockage ont eux aussi bougé : [QNAP QuAgent](https://www.qnap.com/en/software/quagent), [Synology DSM Agent](https://www.synology.com/en-us/beta/2026_DSM_Agent_1_0_Beta/release_note) et [TrueNAS MCP](https://truenas.github.io/truenas-research-labs/) permettent tous à un agent de gérer le boîtier. Mais, à notre connaissance, il n’existe toujours pas de contrat ouvert, auto-hébergé et vérifiable sur la façon dont d’autres agents travaillent en sécurité sur les données qu’il contient. Voir [comment Agent NAS se compare aux approches existantes](https://agentnas.com/fr/compare/). ## Quatre promesses | Promesse | Signification | Assurée par | | --- | --- | --- | | Circonscrit | Une exécution ne peut toucher que ce que nomme son habilitation, et l’habilitation cesse de fonctionner à l’heure dite ; une session qui a lu du contenu non fiable ne peut pas détenir en plus des données sensibles et un canal de sortie. | [Capability Lease](https://agentnas.com/fr/concepts/capability-lease/), [Trust Labels](https://agentnas.com/fr/concepts/trust-labels/) | | Récupérable | Les écritures atterrissent d’abord sur une branche ; les données protégées ne changent que par des fusions relues ; les suppressions sont logiques ; les instantanés sont hors de portée de toute habilitation. | [Agent Branch](https://agentnas.com/fr/concepts/agent-branch/), [Human Gate](https://agentnas.com/fr/concepts/human-gate/) | | Attribuable | Chaque modification peut répondre : qui l’a faite, au nom de qui, sous quelle habilitation, et ce qui a été lu. | [Flight Recorder](https://agentnas.com/fr/concepts/flight-recorder/) | | Inspectable | La mémoire, ce sont des notes ordinaires avec leur provenance, les index peuvent être jetés et reconstruits, et toutes les données peuvent être exportées. | [Agent Home](https://agentnas.com/fr/concepts/agent-home/), [Agent Memory](https://agentnas.com/fr/concepts/agent-memory/), [Budgeted Reads](https://agentnas.com/fr/concepts/budgeted-reads/), [Cascade Forget](https://agentnas.com/fr/concepts/cascade-forget/) | ## Neuf concepts, trois questions Agent NAS propose neuf concepts nommés. Chacun a sa propre page : une définition que vous pouvez citer, un mécanisme, une façon de commencer petit, une esquisse d’interface, ce que la spécification exige et ses limites assumées. ### Travail Où le travail a-t-il lieu, et que s’est-il passé ? - AN-01 [Agent Home (répertoire personnel)](https://agentnas.com/fr/concepts/agent-home/): Un répertoire par rôle, avec historique. Des fichiers ordinaires que vous emportez. - AN-02 [Agent Branch (branche d’agent)](https://agentnas.com/fr/concepts/agent-branch/): Chaque exécution travaille sur une branche en copy-on-write. Seule une fusion relue atteint la ligne principale. - AN-03 [Flight Recorder (enregistreur de vol)](https://agentnas.com/fr/concepts/flight-recorder/): Un enregistrement par exécution, chaîné par hachage, qui inclut ce que l’exécution a lu. ### Autorité Qui peut faire quoi, et sur ordre de qui ? - AN-04 [Capability Lease (habilitation de capacité)](https://agentnas.com/fr/concepts/capability-lease/): Une autorisation étroite pour une exécution, avec une expiration et des budgets. Les habilitations filles ne peuvent être que plus étroites. - AN-05 [Human Gate (validation humaine)](https://agentnas.com/fr/concepts/human-gate/): N’apparaît qu’avant les actions irréversibles, tournées vers l’extérieur ou qui élèvent les privilèges, et montre le vrai diff. - AN-06 [Trust Labels (étiquettes de confiance)](https://agentnas.com/fr/concepts/trust-labels/): Deux petites étiquettes plus la contamination de session appliquent la Rule of Two. ### Connaissance Que sait l’agent, comment lit-il et comment oublie-t-il ? - AN-07 [Agent Memory (mémoire de l’agent)](https://agentnas.com/fr/concepts/agent-memory/): Des notes que vous pouvez lire et modifier font la vérité. Les index sont un cache que vous pouvez jeter. - AN-08 [Budgeted Reads (lectures avec budget)](https://agentnas.com/fr/concepts/budgeted-reads/): Lire un fichier sous forme de plan, de section, de plage de lignes ou en entier, avec dégradation pour tenir dans le budget. - AN-09 [Cascade Forget (oubli en cascade)](https://agentnas.com/fr/concepts/cascade-forget/): Supprimer les dérivés en suivant le lignage, traiter l’historique selon la classe de rétention, et signaler ce qui n’a pas pu être fait. ## Quatre couches, six substantifs La couche Store utilise tel quel un stockage éprouvé. Toutes les couches au-dessus peuvent être reconstruites à partir d’elle, et le cœur ne compte que six substantifs : Tree, Commit, Principal, Run, Lease et Record. Nous n’inventons pas de moteur de stockage ; l’innovation est dans le contrat. - **Interface**: Projette les capacités dans des interfaces que les agents, les personnes et les outils utilisent déjà. Les passerelles sont sans état et ne décident jamais qui peut faire quoi. (Montage (POSIX), Git, S3, WebDAV/SMB, MCP, HTTP, CLI, A2A (optionnel)) - **Trust (confiance)**: Le seul point d’autorisation. Une politique déterministe, sans aucun modèle dans la décision. (Principals et exécutions, Capability Lease, Moteur de politiques, Human Gate, Trust Labels, Credential Broker, Flight Recorder) - **Memory (mémoire)**: Transforme les notes en connaissances interrogeables. Tout peut être reconstruit à partir de la couche inférieure. (Agent Memory, Budgeted Reads, Cascade Forget, Index, Tâches de maintenance, Lignage) - **Store (stockage)**: Un arbre avec historique, sur des instantanés de système de fichiers éprouvés, Git ou un stockage objet versionné. (Tree, Commit, Agent Branch, Instantanés du système de fichiers, Git, Stockage objet) - **Sync (synchronisation, optionnelle)**: Réplication et partage entre nœuds. Placée en dernier à dessein : il faut d’abord réussir un seul nœud. (Dépôts Git distants, Transfert d’instantanés, Liens d’habilitation, Paquets de passation) [Lire l’architecture](https://agentnas.com/fr/architecture/). ## Le parcours d’une exécution 1. **Demander une habilitation.** L’orchestrateur de l’agent de recherche Cleo demande une [Capability Lease](https://agentnas.com/fr/concepts/capability-lease/) pour cette exécution : lire `/shared/launch`, proposer des modifications, valable quatre heures. L’enveloppe de politiques que le propriétaire a fixée l’approuve automatiquement. 2. **Commencer à travailler.** Le NAS crée l’exécution et sa branche `cleo/run_91ab` ; le sandbox monte la branche comme un répertoire ordinaire. Cleo lit `AGENTS.md` et sa mémoire relue depuis son [Agent Home](https://agentnas.com/fr/concepts/agent-home/). 3. **Lire dans les limites d’un budget.** Il lit un long rapport avec [Budgeted Reads](https://agentnas.com/fr/concepts/budgeted-reads/) : d’abord un plan de 400 tokens, puis, selon les besoins, des plages de lignes précises. Chaque lecture est ajoutée au manifeste de lecture de l’exécution. 4. **Travailler sur une branche.** Les modifications atterrissent sur une [Agent Branch](https://agentnas.com/fr/concepts/agent-branch/). La branche partagée `main` ne change pas du tout pour l’instant. 5. **Rencontrer une validation.** Cleo a lu une page web ; les [Trust Labels](https://agentnas.com/fr/concepts/trust-labels/) donnent donc à sa session une contamination `external`. Quand elle propose de fusionner dans `main`, la politique exige une [Human Gate](https://agentnas.com/fr/concepts/human-gate/) : le propriétaire voit sur son téléphone le vrai diff calculé par le NAS et la source non fiable, puis approuve. 6. **Laisser une trace.** La fusion crée un commit avec provenance. Ce qui a été lu, ce qui a été écrit et qui a approuvé quoi vont dans le [Flight Recorder](https://agentnas.com/fr/concepts/flight-recorder/), chaîné par hachage. 7. **Consolider la mémoire.** Cleo note quelques faits nouveaux. Comme cette session a lu du contenu externe, ces notes d’[Agent Memory](https://agentnas.com/fr/concepts/agent-memory/) vont d’abord en quarantaine : elles peuvent être rappelées, mais ne seront pas chargées automatiquement tant qu’une personne ne les a pas relues. 8. **Oublier.** Des semaines plus tard, un client demande à être oublié. [Cascade Forget](https://agentnas.com/fr/concepts/cascade-forget/) supprime, en suivant le lignage, les résumés et les index associés, puis délivre un rapport qui indique ce qu’il n’a pas pu couvrir. ## Il parle la langue que les agents parlent déjà Aucun nouveau SDK n’est nécessaire pour commencer. Tout agent qui sait lire et écrire des fichiers, utiliser Git ou S3, ou appeler des outils MCP peut utiliser Agent NAS. La session ci-dessous illustre seulement la ligne de commande prévue. *Session illustrative* ```bash $ nas lease create --role cleo --paths "/shared/launch/**" --actions read,write,propose --ttl 4h lease lse_7Qk3 · run run_91ab · branch cleo/run_91ab · expires 16:00 $ nas mount --lease lse_7Qk3 ~/work # plain files, on a branch $ ./draft-release-notes.sh # the agent works with ordinary tools $ nas propose --into main gate gt_2Mx4 waiting for approval: merge cleo/run_91ab into main (4 files) $ nas gate approve gt_2Mx4 # the owner, from another terminal or a phone merged · commit 91ce3a7 · record 18211 ``` [Voir toutes les interfaces](https://agentnas.com/fr/interfaces/). ## Nos paris Une conception qui espère tenir des années doit dire sur quoi elle parie et ce qui se passe si elle perd son pari. - **Les agents continueront d’utiliser les systèmes de fichiers et Git comme principal support de travail.** Sinon, Agent Home se dégrade en format d’export et les autres concepts tiennent toujours. - **« Une exécution » restera l’unité naturelle d’autorisation et de responsabilité.** Si des processus autonomes de longue durée apparaissent, les habilitations deviennent des renouvellements continus avec budgets. - **L’injection de prompt ne sera pas éradiquée au niveau du modèle dans un avenir prévisible.** Si elle l’est, les Trust Labels deviennent une couche bon marché de défense en profondeur. - **L’attention humaine restera rare.** Si l’automatisation complète devient assez fiable, une Human Gate cède la place à une politique d’autorisation préalable, et la piste d’audit demeure. Les sept paris figurent dans les [principes de conception](https://agentnas.com/fr/principles/). ## Ce site est aussi lisible par les agents Chaque page a un jumeau Markdown, le site publie `llms.txt` et il exploite un petit serveur MCP en lecture seule. Essayez-le dans un terminal : *Terminal* ```bash curl -H "Accept: text/markdown" https://agentnas.com/what-is-agent-nas/ curl https://agentnas.com/llms.txt curl -X POST https://agentnas.com/api/search \ -H "content-type: application/json" \ -d '{"query": "capability lease", "limit": 5}' ``` Pour ajouter le serveur de documentation à un client MCP : *mcp.json* ```json { "mcpServers": { "agentnas-docs": { "url": "https://agentnas.com/mcp" } } } ``` ## Les questions qu’on pose en premier ### Qu’est-ce qu’Agent NAS en une phrase ? Un stockage en réseau conçu autour de l’exécution : chaque exécution d’un agent travaille dans une branche isolée et accède aux données par une habilitation étroite et de courte durée ; chaque modification peut être tracée et annulée ; et la mémoire, ce sont des fichiers ordinaires avec leur provenance. ### Y a-t-il un logiciel à télécharger ? Pas encore. Agent NAS est pour l’instant un concept doté d’un brouillon de spécification (v0.2). L0 et L1 peuvent être construits dès aujourd’hui avec Git, des instantanés de système de fichiers et une petite passerelle ; l’objectif pour l’implémentation de référence v0 est le premier semestre 2027. Voir la [feuille de route](https://agentnas.com/fr/roadmap/). ### En quoi diffère-t-il des agents d’IA fournis par les fabricants de NAS ? Ces agents gèrent le boîtier. Agent NAS spécifie comment d’autres agents travaillent sur les données qu’il contient : branches, habilitations, mémoire et oubli. Les deux se complètent, et le boîtier d’un fabricant peut servir de fondation à un déploiement Overlay. ### Va-t-il remplacer mon stockage actuel ? Non. La forme de déploiement Overlay se place devant un NAS, un stockage objet ou un hébergeur Git existant et ne gère qu’un seul répertoire ou bucket à l’intérieur. ### Peut-il arrêter l’injection de prompt ? Non. Il limite ce qui se passe après une injection et rend les conséquences visibles et réversibles. Ses limites assumées figurent sur la page [sécurité](https://agentnas.com/fr/security/). ### Puis-je partir à tout moment ? Oui. Tout peut être exporté sous forme de fichiers ordinaires et d’historique Git. C’est une garantie de conception, pas une fonctionnalité optionnelle. [Toutes les questions](https://agentnas.com/fr/faq/). ## Où en sont les choses > **État.** Agent NAS en est au stade du concept et du brouillon de spécification (v0.2, novembre 2026). La v0.2 est une révision de réalisme : treize concepts ont été ramenés à neuf, et chacun indique comment commencer petit et quelles sont ses limites assumées. Il n’y a pas encore d’implémentation de référence. - [Brouillon de spécification](https://agentnas.com/fr/spec/): Niveaux de conformité et tests d’acceptation exécutables. - [Feuille de route](https://agentnas.com/fr/roadmap/): Maintenant, ensuite, plus tard, et ce que nous ne ferons pas. - [À propos du projet](https://agentnas.com/fr/about/): Licence, comment citer et comment participer. --- URL canonique : https://agentnas.com/fr/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Qu’est-ce qu’Agent NAS ? > Agent NAS est un stockage en réseau conçu autour de l’exécution (run) : chaque exécution d’un agent travaille dans une branche isolée et accède aux données par une habilitation étroite et de courte durée ; chaque modification peut être tracée et annulée ; et la mémoire, ce sont des fichiers ordinaires avec leur provenance. Il parle ce que les agents parlent déjà : fichiers, Git, S3 et MCP. ## En un paragraphe Agent NAS conserve tout ce dont un agent a besoin pour travailler dans la durée : instructions, compétences, mémoire, travail en cours et historique. Il répond à des questions dont un NAS classique n’a pas à s’occuper : que peut toucher cette exécution, une erreur peut-elle être annulée, qui a approuvé quoi, et d’où vient un souvenir. Ce n’est pas un nouveau moteur de stockage. C’est un **contrat** posé sur un stockage éprouvé (systèmes de fichiers, Git, stockage objet), qui précise comment doivent fonctionner l’autorité, l’isolation, la traçabilité et la mémoire entre les agents et les données, et comment le vérifier. ## Lire le nom en le décomposant - **Agent**: Un système d’IA qui agit pour le compte de quelqu’un : il lit, décide et utilise des outils en de nombreuses étapes. Dans Agent NAS, un agent appartient à un **rôle**, et chaque tâche est une **exécution** (run). - **En réseau (Network-attached)**: Accessible par le réseau et par de nombreux clients à la fois, que ce soit un réseau local domestique, un serveur d’équipe ou une région cloud. Pas lié à un seul sandbox ni à une seule machine. - **Stockage (Storage)**: Durable, versionné et exportable. Le stockage est la source de vérité ; tout ce qui est « intelligent » en est dérivé et peut être jeté puis reconstruit. ## Ce qui fait d’un système un Agent NAS 1. **L’unité d’accès est l’exécution.** Chaque exécution a sa propre [habilitation](https://agentnas.com/fr/concepts/capability-lease/), et non une clé partagée ou un compte humain. 2. **Isolé et annulable par défaut.** Les écritures atterrissent d’abord sur une [branche](https://agentnas.com/fr/concepts/agent-branch/) ; les données protégées ne changent que par des fusions ; les suppressions sont logiques. 3. **Chaque modification est traçable.** Qui l’a faite, au nom de qui, sous quelle habilitation, et ce qui a été lu ([Flight Recorder](https://agentnas.com/fr/concepts/flight-recorder/)). 4. **La mémoire, ce sont des fichiers avec leur provenance, et les index sont jetables** ([Agent Memory](https://agentnas.com/fr/concepts/agent-memory/)). 5. **Il est servi par des interfaces existantes :** montages, Git, S3 et MCP, pas un nouveau protocole. 6. **Sans la couche d’IA, c’est encore un bon NAS généraliste,** et toutes les données peuvent être exportées intégralement. ## Ce qu’il n’est pas - **Pas un nouveau moteur de stockage, système de fichiers ou base de données vectorielle.** Tous sont utilisés comme des briques existantes. - **Pas un sandbox.** Il n’isole pas le calcul ; il encadre la relation entre les agents et les données, et doit s’utiliser avec un sandbox. - **Pas un remède contre l’injection de prompt.** Il en limite les conséquences, sans empêcher l’injection de se produire. Voir [sécurité](https://agentnas.com/fr/security/). - **Pas un framework d’agents.** Il ne dit pas comment les agents raisonnent, planifient ou appellent des modèles. ## Pour qui, et qui n’en a pas besoin - **Les développeurs qui utilisent déjà `AGENTS.md` et Git :** ils veulent une ligne principale protégée, des exécutions annulables et une trace vérifiable. - **Les équipes qui font tourner plusieurs agents :** elles ont besoin d’un arbre partagé, de la relecture des modifications des agents et d’une réponse à « qu’a-t-il réellement lu ? ». - **Les particuliers avec un agent personnel :** ils veulent garder la mémoire entre leurs mains, lisible, modifiable et portable. - **Les organisations qui traitent des données de clients :** elles ont besoin que la rétention et l’oubli soient des choix explicites à l’écriture, et d’un rapport d’oubli honnête. > **Qui n’en a pas besoin.** Si vous avez un seul agent et des données que vous referiez sans peine, vous n’avez **pas** besoin d’Agent NAS : un dépôt Git avec un `AGENTS.md` suffit. Il trouve sa place quand les données commencent à compter, que les agents se multiplient et que vous voulez savoir « qu’a-t-il réellement lu et modifié ? ». D’autres cas figurent dans les [cas d’usage](https://agentnas.com/fr/use-cases/). ## Agent NAS et les agents de gestion des fabricants | Question | Agents de gestion des fabricants de NAS | Agent NAS | | --- | --- | --- | | Que fait l’agent ? | Il administre ce NAS en langage naturel, en transformant la conversation en opérations. | Il travaille sur les données du boîtier : lire, écrire, mémoriser et laisser une trace. | | Comment l’accès est-il accordé ? | Il réutilise les droits de l’utilisateur, avec une seconde confirmation pour les opérations dangereuses. | Une habilitation de courte durée liée à une exécution : chemins, actions, expiration, budgets. | | Et si quelque chose tourne mal ? | On s’appuie sur des confirmations et des journaux. | Les écritures atterrissent sur une branche ; les suppressions sont logiques ; les instantanés sont hors de portée de toute habilitation. | | Où vit la mémoire ? | Sur les serveurs de l’assistant ou du fabricant. | Sous forme de notes avec provenance dans le Home de l’agent ; les index sont jetables. | | Contenu non fiable ? | Il entre dans le modèle comme n’importe quel autre texte. | Il porte une étiquette `external` ; après sa lecture, les actions à conséquences passent par une validation. | | Comment partir ? | Cela dépend du fabricant. | Tout s’exporte sous forme de fichiers ordinaires et d’historique Git. | ## À lire ensuite - [Les neuf concepts](https://agentnas.com/fr/concepts/): Une page chacun, avec la façon de commencer petit. - [Architecture](https://agentnas.com/fr/architecture/): Quatre couches, six substantifs et le parcours d’une exécution. - [Sécurité](https://agentnas.com/fr/security/): Modèle de menaces, contrôles et limites assumées. - [FAQ](https://agentnas.com/fr/faq/): Réponses courtes aux questions fréquentes. --- URL canonique : https://agentnas.com/fr/what-is-agent-nas/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Les neuf concepts > Agent NAS repose sur neuf concepts nommés. Ils répondent à trois questions : où le travail a lieu et ce qui s’est passé ; qui peut faire quoi et sur ordre de qui ; et ce que l’agent sait, comment il lit et comment il oublie. Les noms des concepts sont des termes forgés et restent en anglais dans toutes les langues, avec une glose dans la langue locale. Chaque page s’ouvre sur une définition citable, puis couvre le problème, le mécanisme, la façon de commencer petit, une esquisse d’interface, ce que la spécification demande, ainsi que ce qui est emprunté et les limites assumées. Le niveau de conformité dit à partir de quand une implémentation devrait prendre le concept en charge ; voir la [spécification](https://agentnas.com/fr/spec/). > **À propos de « nouveau ».** La plupart des neuf concepts combinent des briques éprouvées. Chaque page de concept dit ce qu’elle emprunte et ce qui est réellement nouveau. La liste récapitulative est sur la page de [comparaison](https://agentnas.com/fr/compare/). ## Trois groupes ### Travail Où le travail a-t-il lieu, et que s’est-il passé ? - AN-01 [Agent Home (répertoire personnel)](https://agentnas.com/fr/concepts/agent-home/): Un répertoire par rôle, avec historique. Des fichiers ordinaires que vous emportez. - AN-02 [Agent Branch (branche d’agent)](https://agentnas.com/fr/concepts/agent-branch/): Chaque exécution travaille sur une branche en copy-on-write. Seule une fusion relue atteint la ligne principale. - AN-03 [Flight Recorder (enregistreur de vol)](https://agentnas.com/fr/concepts/flight-recorder/): Un enregistrement par exécution, chaîné par hachage, qui inclut ce que l’exécution a lu. ### Autorité Qui peut faire quoi, et sur ordre de qui ? - AN-04 [Capability Lease (habilitation de capacité)](https://agentnas.com/fr/concepts/capability-lease/): Une autorisation étroite pour une exécution, avec une expiration et des budgets. Les habilitations filles ne peuvent être que plus étroites. - AN-05 [Human Gate (validation humaine)](https://agentnas.com/fr/concepts/human-gate/): N’apparaît qu’avant les actions irréversibles, tournées vers l’extérieur ou qui élèvent les privilèges, et montre le vrai diff. - AN-06 [Trust Labels (étiquettes de confiance)](https://agentnas.com/fr/concepts/trust-labels/): Deux petites étiquettes plus la contamination de session appliquent la Rule of Two. ### Connaissance Que sait l’agent, comment lit-il et comment oublie-t-il ? - AN-07 [Agent Memory (mémoire de l’agent)](https://agentnas.com/fr/concepts/agent-memory/): Des notes que vous pouvez lire et modifier font la vérité. Les index sont un cache que vous pouvez jeter. - AN-08 [Budgeted Reads (lectures avec budget)](https://agentnas.com/fr/concepts/budgeted-reads/): Lire un fichier sous forme de plan, de section, de plage de lignes ou en entier, avec dégradation pour tenir dans le budget. - AN-09 [Cascade Forget (oubli en cascade)](https://agentnas.com/fr/concepts/cascade-forget/): Supprimer les dérivés en suivant le lignage, traiter l’historique selon la classe de rétention, et signaler ce qui n’a pas pu être fait. --- URL canonique : https://agentnas.com/fr/concepts/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Architecture > Agent NAS a quatre couches et une couche de synchronisation optionnelle : Interface projette les capacités dans des interfaces existantes, Trust est le seul point d’autorisation, Memory transforme les notes en connaissances interrogeables, et Store conserve un arbre avec historique. La couche Memory peut être supprimée et reconstruite en bloc, et Store utilise simplement un stockage éprouvé. ## Quatre couches et une synchronisation optionnelle - **Interface**: Projette les capacités dans des interfaces que les agents, les personnes et les outils utilisent déjà. Les passerelles sont sans état et ne décident jamais qui peut faire quoi. (Montage (FUSE, NFS, SMB), Git, Compatible S3, WebDAV, MCP, API HTTP, CLI, A2A (optionnel)) - **Trust (confiance)**: Le seul point d’autorisation. Un moteur de politiques déterministe, sans modèle dans la décision ; enregistrer d’abord, agir ensuite. (Principals et exécutions, Capability Lease, Moteur de politiques, Human Gate, Trust Labels, Credential Broker, Flight Recorder) - **Memory (mémoire)**: Transforme les notes en connaissances interrogeables et lisibles dans la limite d’un budget. Tout peut être reconstruit à partir de la couche inférieure. (Conventions de notes, Index (texte intégral, vectoriel, graphe), Budgeted Reads, Tâches de maintenance, Lignage, Cascade Forget) - **Store (stockage)**: Un arbre avec historique, sur des instantanés de système de fichiers éprouvés, Git ou un stockage objet versionné. Il ne comprend ni la mémoire ni les étiquettes. (Tree, Commit, Agent Branch, Instantanés du système de fichiers, Git, Stockage objet) - **Sync (synchronisation, optionnelle)**: Réplication et partage entre nœuds. Placée en dernier à dessein : il faut d’abord réussir un seul nœud. (Dépôts Git distants, Transfert d’instantanés, Liens d’habilitation, Paquets de passation) - **La couche Memory est reconstructible.** Supprimez tous les index et reconstruisez : les notes de Store restent entièrement lisibles. - **Les passerelles sont sans état.** Tout l’état persistant est dans Store et dans les enregistrements de Trust ; une passerelle peut redémarrer librement et monter en charge horizontalement. - **Trust est le seul point d’autorisation.** Cela inclut les tâches d’arrière-plan du NAS lui-même (indexation, maintenance) : elles s’exécutent aussi comme des principals `svc:*` détenteurs d’habilitations. - **Store ne comprend ni la mémoire ni la sémantique des étiquettes.** Il se contente de conserver un arbre avec des métadonnées. - **Enregistrer d’abord, agir ensuite.** Une opération à conséquences doit d’abord écrire un enregistrement d’intention. ## Le noyau étroit : six substantifs Toute la conception repose sur six substantifs ; les étiquettes, les validations, la mémoire et les manifestes de lecture sont des conventions construites par-dessus. | Substantif | Signification | Invariant clé | | --- | --- | --- | | Tree | Une arborescence de répertoires avec historique. | N’importe quel commit peut être reproduit ; il existe un hachage de contenu ou une détection de changement équivalente. | | Commit | Une modification immuable. | Porte des métadonnées de provenance : `principal`, `on_behalf_of`, `run`, `lease`. | | Principal | Une entité qui peut être authentifiée et tenue pour responsable. | Le type est `human`, `agent`, `service` ou `node` ; un `agent` appartient à un rôle, pas à une seule exécution. | | Run | Une exécution avec un début, une fin, un but et un responsable. | Détient une habilitation racine ; possède une branche. | | Lease | L’autorisation d’une exécution. | A une expiration ; ne peut être que restreinte ; révocable ; porte des budgets. | | Record | Un enregistrement en ajout seul. | Chaîné par hachage ; enregistrer d’abord, agir ensuite. | ## La couche Store : contrat et moteurs optionnels Le contrat Store est fourni par un moteur ou émulé par la passerelle. Une implémentation peut combiner des moteurs, par exemple Git pour le texte et des instantanés pour les gros fichiers ; le contrat ne prescrit ni le moteur, ni la fonction de hachage, ni le format sur disque. 1. Commits atomiques. 2. Forks peu coûteux : idéalement proches de O(1) ; au pire dégradés en copie, auquel cas les quotas et un TTL sont obligatoires. 3. Instantanés immuables. 4. Détection des changements : un hachage de contenu ou un équivalent. 5. La différence entre deux commits. 6. Export complet dans un format standard : un répertoire, l’historique Git et les métadonnées en texte brut de `.nas/`. | Moteur | Adapté à | Coût d’un fork | Remarque | | --- | --- | --- | --- | | Git (avec worktrees) | Texte, mémoire, compétences, petits codes sources | Faible | Les gros fichiers demandent LFS ou un stockage externe ; les fusions binaires sont médiocres. | | Instantanés et clones de système de fichiers (ZFS, btrfs, APFS) | Grands répertoires, fichiers variés | Environ O(1) | Dépend du système de fichiers ; la copie entre machines demande send/receive. | | Stockage objet versionné (forks Tigris, lakeFS, S3 plus un manifeste) | Jeux de données, gros fichiers | Environ O(1) | La passerelle doit fournir une vue de fichiers. | | Répertoire simple plus copie | Démarrer avec Lite | O(n) | Seulement pour de petites données ; quotas et TTL obligatoires. | > **Le chemin de reprise est hors du rayon d’impact.** Les instantanés et les sauvegardes sont détenus par le principal propriétaire, et aucune habilitation ne peut inclure « supprimer un instantané » ou « supprimer une sauvegarde ». C’est la leçon la plus directe de l’incident d’avril 2026 : le chemin de reprise doit se trouver hors du rayon d’impact de ce qu’il protège. - Le chiffrement au repos vient de la couche inférieure ; la classe de rétention `sensitive` utilise son propre domaine de clés, de sorte qu’elle peut être détruite en détruisant la clé. - La déduplication et la destruction sont en conflit : la classe `sensitive` n’est pas dédupliquée entre domaines de clés. ## Le parcours d’une exécution 1. **Demande.** L’orchestrateur (ou le propriétaire) demande une habilitation pour une exécution : chemins, actions, expiration, objectif. Dans l’**enveloppe de politiques**, elle est émise automatiquement ; en dehors, elle passe par une Human Gate. 2. **Démarrage.** Le NAS crée le `run` et la branche `/`, et remet l’habilitation à l’exécution ; le sandbox monte la branche (ou fait un `git clone`). 3. **Travail.** L’agent lit et écrit avec des outils de fichiers ordinaires. Les lectures s’accumulent dans le **manifeste de lecture** et la contamination de session évolue avec elles ; tout accès hors limites est refusé et enregistré. 4. **Commit.** Les modifications sont versionnées dans un commit automatiquement (avec temporisation) ou explicitement, et chaque commit porte des métadonnées de provenance. 5. **Proposition.** `propose` crée une **Agent PR** : le diff, l’intention, un résumé du manifeste de lecture, les résultats des vérifications et un résumé des étiquettes. 6. **Décision.** Le moteur de politiques décide : si les vérifications passent et que le risque est faible, fusion automatique ; si des données protégées, une action vers l’extérieur ou une violation de la Rule of Two sont en jeu, passage par une Human Gate ; si c’est clairement interdit, refus. 7. **Fusion et enregistrement.** La fusion crée un commit avec provenance et écrit un Record. 8. **Clôture.** L’habilitation expire ; la branche est recyclée après son TTL ; les manifestes de lecture et les Records sont conservés selon la politique de rétention. **Le chemin de lecture :** requête, vérification de l’habilitation, vérification des étiquettes (la contamination actuelle de la session autorise-t-elle cette lecture ?), comptage du budget, lecture dans Store, enregistrement dans le manifeste de lecture, retour du contenu et des pointeurs de preuve. > **Enregistrer d’abord, agir ensuite.** Une opération à conséquences (fusion, suppression, partage, sortie de données, changement d’habilitation) doit d’abord écrire un enregistrement d’intention ; s’il ne peut pas être écrit, l’opération échoue (échec en mode fermé). Les lectures vont dans le manifeste de lecture, vidé par lots, sans exigence de synchronisme à chaque lecture. ## Formes de déploiement | Forme | Description | Adaptée à | | --- | --- | --- | | Lite | Une seule machine, un seul utilisateur : un processus de passerelle plus un stockage local (Git ou instantanés de système de fichiers) ; L0 à L1. | Les particuliers et les développeurs qui essaient. | | Overlay | Laisse le NAS ou le stockage objet existant tel quel : une passerelle se place devant et ne gère qu’un seul répertoire ou bucket ; les montages et la vue S3 passent par la passerelle. | **Le point de départ le plus réaliste :** ceux qui ont déjà un boîtier. | | Team | Plusieurs utilisateurs et agents, un serveur ou un petit cluster ; L0 à L3 ; notifications de validation et salle de contrôle. | Les petites équipes. | | Cloud | Un service hébergé multi-locataire avec une isolation forte ; L0 à L3. | Ceux qui n’ont pas leur propre matériel. | Le principe : aucun matériel spécial n’est requis, et n’importe quelle machine allumée en permanence convient ; les accélérateurs sont optionnels, car de petits modèles suffisent pour les embeddings et les résumés, et des services externes peuvent aussi être appelés. ## Construire une v0 avec des briques existantes | Capacité | Briques utilisables dès aujourd’hui | | --- | --- | | Store et branches | Git et worktrees ; instantanés btrfs ou ZFS ; ou Tigris et lakeFS (stockage objet). | | Ligne principale protégée | La protection de branche de Forgejo, Gitea ou GitHub ; ou les branches protégées de lakeFS. | | Habilitations | Un serveur d’autorisation OAuth (par exemple Keycloak) avec échange de jetons, et un serveur de ressources qui vérifie le préfixe de chemin et l’action ; ou un service de signature de quelques centaines de lignes. | | Enregistrements | Une table SQLite en ajout seul plus un hachage quotidien ; des trailers Git dans les commits ; un export OpenTelemetry. | | Validations | Une revue de PR plus une notification push ; la CLI `nas gate approve`. | | Mémoire | Du Markdown sous `memory/` plus SQLite FTS5 ; ajoutez un magasin vectoriel plus tard. | | Étiquettes | Marquer le répertoire d’import `external` ; garder la contamination de session de chaque exécution dans la passerelle. | | Interfaces | Un montage NFS, SMB ou FUSE ; Git sur SSH ou HTTPS ; une passerelle S3 ; un petit serveur MCP. | Ce que dit ce tableau : **L0 et L1 n’exigent aucune invention nouvelle.** Ce qui est nouveau, c’est le contrat qui les combine et les tests qui le vérifient ; voir la [spécification](https://agentnas.com/fr/spec/). ## Exploitation - **Sauvegardes :** 3-2-1 ; les instantanés et les sauvegardes appartiennent au principal propriétaire et aucune habilitation ne peut y toucher ; faites un exercice de restauration chaque trimestre et gardez-en une trace. - **Mises à jour :** les passerelles sont sans état et peuvent être mises à jour progressivement ; tout changement de format de Store doit s’accompagner d’un plan de migration et de retour arrière ; la couche Memory peut être reconstruite en bloc. - **Supervision :** taux d’émission et de refus des habilitations ; longueur de la file des validations et taux d’approbation (un taux d’approbation qui reste au-dessus de 95 % indique que les validations sont trop fréquentes et qu’il faut les regrouper ou resserrer la politique) ; nombre et âge des branches ; fraîcheur des index ; vérification de la chaîne d’enregistrements ; quotas. - **Capacité :** les branches ont un TTL et des quotas ; la corbeille a une durée de rétention ; les données dérivées ont un budget. ## La salle de contrôle L’interface destinée aux personnes peut être une page web, une CLI ou un chatbot. Elle n’est pas indispensable : L0 à L1 peuvent fonctionner entièrement avec une CLI et une plateforme Git existante. - **Chronologie d’activité :** agrégée par exécution : qui a fait quoi, et ce qu’il a lu. - **Boîte des validations :** les actions en attente d’approbation, présentées sous forme de Gate Cards. - **Annuaire des rôles :** le Home de chaque rôle, ses habilitations, ses budgets et ses exécutions récentes. - **Navigateur de mémoire :** notes et sources, quarantaine des notes non relues, propositions de maintenance. - **Branches et PR :** branches non fusionnées et corbeille. - **Console d’oubli :** demandes, aperçu du lignage et rapports. Les personnes peuvent aussi regarder directement via SMB ou WebDAV : `/humans//Agent Activity/` est une vue d’activité en lecture seule faite de fichiers ordinaires. --- URL canonique : https://agentnas.com/fr/architecture/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Interfaces > Agent NAS utilise des fichiers pour le plan de données et des outils pour le plan de contrôle : les octets circulent par montage, Git et S3 ; l’autorisation, l’approbation, la mémoire, la recherche et l’explication passent par MCP, HTTP et une CLI. Chaque interface est une projection des mêmes données, et les différences de sémantique s’expriment par des erreurs explicites au lieu d’être gommées. ## Principes 1. **Des fichiers pour le plan de données, des outils pour le plan de contrôle.** Les octets circulent par montage, Git et S3 ; l’autorisation, l’approbation, la mémoire, la recherche et l’explication passent par MCP, HTTP et une CLI. 2. **Les passerelles sont sans état.** L’autorisation a lieu en un seul point de la couche Trust. 3. **Chaque interface est une projection.** Les différences de sémantique s’expriment par des correspondances d’erreurs explicites (par exemple, « validation en attente » devient un `EACCES` accompagné d’un fichier explicatif), et S3 ne fait pas semblant d’avoir des branches. 4. **Une surface d’outils étroite.** Pas plus de 10 outils MCP face aux agents ; les actions pour les personnes et les opérateurs vivent dans une interface d’opérateur distincte. 5. **Les adaptateurs isolent l’évolution des protocoles.** Les changements de version de MCP et d’A2A n’affectent que les adaptateurs. ## Matrice des interfaces | Interface | Plan | Destinée à | Correspondance | Niveau | | --- | --- | --- | --- | --- | | Montage (FUSE, NFS, SMB) | Données | Agents, personnes, tout programme | Une vue de branche ; correspondance des erreurs ci-dessous | L0 | | Git (SSH, HTTPS) | Données | Agents, personnes, CI | Une branche d’exécution est une branche Git ; une Agent PR est une demande de fusion | L0 | | Compatible S3 | Données | Pipelines de données, traitements par lots | Un bucket correspond à la vue de branche d’un arbre ; un identifiant de version est un commit | L0 (optionnel) | | WebDAV | Données | Personnes (Finder, Explorateur) | Une vue d’activité en lecture seule | L0 (optionnel) | | CLI `nas` | Contrôle | Personnes, scripts | Une correspondance un pour un avec l’API HTTP | L0 | | API HTTP | Contrôle | Orchestrateurs, salle de contrôle | Tout en `POST` avec du JSON ; champs en `snake_case` | L1 | | MCP | Contrôle | Agents | Neuf outils (ci-dessous) | L1, L2 | | A2A | Contrôle | Autres agents | Une tâche correspond à `inbox/` et `outbox/` | L4 (optionnel) | ## La surface d’outils MCP Seuls neuf outils s’adressent aux agents : | Outil | Ce qu’il fait | Action d’habilitation requise | Remarque | | --- | --- | --- | --- | | `nas_list` | Liste un répertoire, avec les étiquettes et l’état de relecture | `list` | Les chemins hors de l’habilitation sont invisibles. | | `nas_read` | Lecture avec budget : vue, plage, budget | `read` | [Budgeted Reads](https://agentnas.com/fr/concepts/budgeted-reads/) | | `nas_search` | Recherche (texte intégral, éventuellement vectorielle), renvoie des extraits et des pointeurs | `read` | La quarantaine est exclue par défaut. | | `nas_write` | Écrit un fichier dans la branche, avec un `intent` facultatif | `write` | La plupart des runtimes utilisent directement le montage et n’en ont pas besoin. | | `nas_branch` | Crée, pose un point de contrôle, restaure et liste les branches | `write` | [Agent Branch](https://agentnas.com/fr/concepts/agent-branch/) | | `nas_propose` | Crée une Agent PR | `propose` | Peut déclencher une validation. | | `nas_lease` | Demande une habilitation fille plus étroite ; interroge l’habilitation actuelle et les budgets ; demande une autorité plus large (via une validation) | Aucune | [Capability Lease](https://agentnas.com/fr/concepts/capability-lease/) | | `nas_remember` | Écrit une note, avec des sources et un genre | `write` | [Agent Memory](https://agentnas.com/fr/concepts/agent-memory/) | | `nas_recall` | Rappelle des notes : avec budget, sources et état de relecture | `read` | [Agent Memory](https://agentnas.com/fr/concepts/agent-memory/) | > **Actions réservées aux personnes et aux opérateurs.** `explain`, `gate approve/deny`, `forget`, `trash restore`, `label admin`, `lease revoke` et `policy edit` ne sont **pas exposées** aux agents. Ces actions changent les garanties elles-mêmes et ne doivent pas pouvoir être appelées par la partie qu’elles contraignent. Un agent peut en **demander** certaines (autorité plus large, oubli) mais ne peut pas les exécuter. ## Sémantique du montage - Un montage lie **une branche et une habilitation** ; à l’expiration de l’habilitation, le montage passe en lecture seule puis est démonté. - Commits automatiques (avec temporisation, par exemple après 5 secondes de calme) ; `fsync` déclenche un commit. - Les chemins hors de l’habilitation **n’apparaissent pas dans les listings de répertoires :** cela réduit les fuites d’information et la surface d’attaque de l’injection de prompt. - Adapté au sandbox : pas de root nécessaire ; FUSE ou NFS, l’un des deux, sans module noyau ; les montages en lecture seule sont possibles. | Situation | Erreur POSIX | Remarque | | --- | --- | --- | | Un chemin hors de l’habilitation | `ENOENT` (`EACCES` quand il est visible mais refusé) | Le refus est enregistré. | | Quota ou budget épuisé | `EDQUOT` | Permet à l’exécution de s’autolimiter. | | Validation en attente | `EACCES`, avec une explication dans `/.nas/pending` | Évite que l’agent réessaie indéfiniment. | | Habilitation expirée | `ESTALE`, puis lecture seule | La branche est conservée jusqu’à l’expiration de son propre TTL. | ## Git - Les branches d’exécution se nomment `/` ; `main` est protégée, et un hook `pre-receive` côté serveur rejette les pushs directs. - `nas propose` crée une Agent PR. - Les commits portent automatiquement des trailers tels que `Run:`, `Lease:` et `Principal:`. ## S3 - Un bucket correspond à la vue de branche d’un arbre ; l’identifiant de version d’un objet est un commit. - Les sémantiques qui manquent à S3, comme les branches, s’expriment par un préfixe de bucket ou un en-tête de requête (`x-nas-branch`). C’est une **projection dégradée :** les pipelines de données peuvent lire et écrire, mais n’ont pas l’expérience complète des branches. - Les habilitations sont transmises sous forme d’identifiants temporaires de type STS. ## A2A (optionnel) - Les tâches entrantes arrivent sous forme de fichiers de tâche dans `inbox/` ; les livrables vont dans `outbox/`. - L’Agent Card déclare les compétences du rôle et les habilitations dont il a besoin. - **Le NAS n’est pas un participant A2A ;** c’est le runtime qui agit pour le rôle qui l’est. Le NAS ne fait que stocker les tâches et les livrables, les paquets de passation et les habilitations. ## Conventions de l’API HTTP - **Chaque endpoint utilise `POST`, avec les paramètres dans un corps JSON ;** les champs des réponses sont toujours en `snake_case`. - Les chemins sont versionnés : `/v1/...`. - Idempotence : les opérations d’écriture acceptent une `idempotency_key`. - Pagination : `cursor` plus `limit`. - Les budgets et les limites de débit sont renvoyés dans les en-têtes de réponse (octets restants, requêtes restantes) pour que les runtimes puissent s’autolimiter. Une requête de lecture avec budget et sa réponse ressemblent à peu près à ceci : *Lecture avec budget* ```http POST /v1/files/read { "path": "/agents/cleo/memory/notes/customer-acme.md", "view": "outline", "budget_tokens": 400 } 200 OK { "view": "outline", "tokens": 212, "generated": false, "truncated": false, "content": "# Acme\n## Renewal (L12-L18)\n## Contacts (L19-L31)\n## Open issues (L32-L40)", "evidence": [ { "pointer": "nas://home-box/agents/cleo/memory/notes/customer-acme.md@9f2c1de#L1-L40" } ] } ``` Les erreurs utilisent une structure uniforme : *Réponse d’erreur* ```json { "error": { "code": "gate_required", "message": "This merge requires human approval.", "retryable": false, "request_id": "req_01JB7W2X4N", "details": { "gate_id": "gt_2Mx4" } } } ``` ## Découverte - Les points d’entrée lisibles par les machines sont les mêmes que sur ce site : `/.well-known/ai-catalog.json`, la fiche de serveur MCP et `llms.txt`. - Un point d’accès qui résout et vérifie les pointeurs de preuve `nas://`. - MCP `server/discover`. --- URL canonique : https://agentnas.com/fr/interfaces/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Sécurité > Agent NAS n’arrête pas l’injection de prompt ; il limite ce qui se passe après. Une habilitation étroite borne ce qu’une exécution peut toucher, les branches rendent les erreurs annulables, la Rule of Two empêche une session qui a lu du contenu non fiable de détenir aussi des données sensibles et un canal de sortie, et un enregistrement traçable est conservé. ## 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](https://ai.meta.com/blog/practical-ai-agent-security/) 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](https://agentnas.com/fr/concepts/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 1. Ce n’est **pas** une défense contre l’injection de prompt. Il en limite les conséquences et les rend visibles. 2. Des permissions légitimes à l’intérieur d’une habilitation peuvent toujours être détournées. 3. 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. 4. Les canaux cachés et les canaux auxiliaires sont hors du périmètre. 5. Si la TCB est compromise, les garanties tombent. 6. Les gens se trompent : les validations réduisent ce risque mais ne peuvent pas le supprimer. 7. La contamination est prudente et apporte de la friction et des faux positifs ; elle demande des réglages et des raisons de refus visibles. 8. 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](https://agentnas.com/fr/concepts/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. --- URL canonique : https://agentnas.com/fr/security/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Cas d’usage > Chaque scénario part de quelque chose que les gens font déjà, et montre quelle étape Agent NAS change, quel niveau de conformité il demande, et ce que vous pouvez construire dès aujourd’hui. ## Un agent qui travaille pendant la nuit Avant de dormir, vous confiez une tâche à un agent : mettre en ordre les notes de version. Il travaille sur sa propre branche ; le matin, vous voyez sur votre téléphone une Gate Card : 4 fichiers, le vrai diff et les sources lues. Vous approuvez et la fusion a lieu ; vous refusez et la branche est jetée, la ligne principale restant intacte. - **Concepts utilisés :** [Agent Branch](https://agentnas.com/fr/concepts/agent-branch/), [Capability Lease](https://agentnas.com/fr/concepts/capability-lease/), [Human Gate](https://agentnas.com/fr/concepts/human-gate/). - **Conformité :** L0 à L1. - **Réalisable dès aujourd’hui :** un worktree Git, un `main` protégé et une notification push. ## Changer de framework, garder la mémoire Vous faites passer un agent d’un runtime à un autre. Son Home est un répertoire qui suit des conventions ouvertes : `AGENTS.md`, `skills/`, `memory/notes/`. Le nouveau runtime lit le même répertoire ; tout ce qui se convertit avec perte est marqué non relu à l’import. - **Concepts utilisés :** [Agent Home](https://agentnas.com/fr/concepts/agent-home/), [Agent Memory](https://agentnas.com/fr/concepts/agent-memory/). - **Conformité :** L0 à L2. - **Réalisable dès aujourd’hui :** un répertoire Git avec un `AGENTS.md`. ## Une équipe, plusieurs agents, un seul fonds de connaissances Trois agents écrivent dans la même base de connaissances. Chacun travaille sur sa propre branche et les fusions sont relues ; les notes écrites par une exécution qui a lu une page web externe vont en quarantaine et ne sont pas chargées automatiquement par les autres agents. Ce qui est partagé, ce sont les notes, pas les index. - **Concepts utilisés :** [Trust Labels](https://agentnas.com/fr/concepts/trust-labels/), [Agent Memory](https://agentnas.com/fr/concepts/agent-memory/), [Agent Branch](https://agentnas.com/fr/concepts/agent-branch/). - **Conformité :** L0 à L3. - **Réalisable dès aujourd’hui :** une ligne principale protégée, une marque `external` sur le répertoire d’import, et une règle qui ne charge automatiquement que les notes relues. ## Revue d’incident Après une fusion, vous trouvez une page qui semble fausse. `explain(commit)` vous dit quelle exécution, quelle habilitation et quelle validation l’ont décidée ; le manifeste de lecture montre que cette exécution a lu une page web externe. Vous suivez la provenance jusqu’aux notes touchées, vous revenez en arrière et vous les mettez en quarantaine. - **Concepts utilisés :** [Flight Recorder](https://agentnas.com/fr/concepts/flight-recorder/), [Agent Branch](https://agentnas.com/fr/concepts/agent-branch/). - **Conformité :** L1. - **Réalisable dès aujourd’hui :** des trailers Git dans les commits plus une table SQLite en ajout seul. ## Un client demande à être oublié Les données du client ont été marquées de la classe de rétention `sensitive` à l’écriture. Quand la demande arrive, Cascade Forget suit le lignage jusqu’aux résumés, aux embeddings et aux notes qui les citent, détruit ce domaine de clés et délivre un rapport : ce qui a été fait, et ce qui n’a pas pu l’être (copies hors du NAS, journaux du fournisseur de modèle, poids du modèle). - **Concepts utilisés :** [Cascade Forget](https://agentnas.com/fr/concepts/cascade-forget/), [Agent Memory](https://agentnas.com/fr/concepts/agent-memory/). - **Conformité :** L3. - **Réalisable dès aujourd’hui :** classes de rétention, suppression logique, et enregistrement des entrées de chaque dérivé. ## Ajouter une porte à un boîtier que vous possédez déjà Vous avez déjà un NAS. La forme Overlay place une passerelle devant et ne gère qu’un seul répertoire. Les agents vont et viennent par un montage ou la vue S3 ; les sauvegardes et les instantanés du propriétaire restent hors de leur portée. - **Concepts utilisés :** [Capability Lease](https://agentnas.com/fr/concepts/capability-lease/), [Agent Branch](https://agentnas.com/fr/concepts/agent-branch/). - **Conformité :** L0 à L1. - **Réalisable dès aujourd’hui :** NFS ou SMB plus une petite passerelle qui vérifie les jetons par rapport à un préfixe de chemin et à une action. ## Quand ne pas utiliser Agent NAS | Votre situation | Une approche plus simple | | --- | --- | | Un seul agent, et des données que vous referiez sans peine | Un dépôt Git avec un `AGENTS.md`. | | Vous voulez seulement qu’un agent aide à gérer votre NAS | L’agent de gestion du fabricant. | | Vous n’avez besoin que de jeux de données forkables | lakeFS ou Tigris. | | Vous n’avez besoin que de récupération de mémoire | N’importe quelle bibliothèque de mémoire. | | Vous avez besoin d’un calcul isolé | Un sandbox. | --- URL canonique : https://agentnas.com/fr/use-cases/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Comparaison > Agent NAS n’a pas vocation à remplacer ces approches. La plupart des travaux voisins sont bons dans leur domaine et peuvent en devenir une pièce. Nous essayons d’être honnêtes sur ce qui est emprunté et sur ce qui est réellement nouveau. ## Le paysage | Catégorie | Exemples | Ce qu’elle fait déjà | Où elle s’arrête | | --- | --- | --- | --- | | Agents de gestion des fabricants de NAS | QNAP QuAgent, Synology DSM Agent, TrueNAS MCP | Gèrent le boîtier en langage naturel ; réutilisent les permissions de l’utilisateur ; demandent une double confirmation pour les opérations dangereuses ; journaux. | Visent à « gérer », pas à « travailler dans les données » ; pas d’habilitations par exécution, de branches ni de contrat de mémoire. | | Systèmes de fichiers pour agents et Git | Turso AgentFS, Letta Context Repositories, Cloudflare Artifacts, Redis Agent Filesystem | Placent fichiers, état et audit des appels d’outils dans un stockage portable ; mémoire versionnée par Git ; Git pour les agents. | Chacun est lié à un runtime ou à une plateforme ; autorisation, approbation, contamination et oubli restent pour l’essentiel à l’extérieur. | | Stockage objet forkable et gestion de versions de données | Tigris Agent Kit, lakeFS | Forks en copy-on-write, points de contrôle, branches protégées, identifiants à portée limitée, hooks avant fusion. | Visent les data lakes et le stockage objet dans le cloud ; pas de mémoire ni de sémantique d’habilitation, et pas d’expérience d’approbation humaine. | | Frameworks de mémoire | Letta, Mem0, Zep/Graphiti, architecture de mémoire d’OpenClaw | Récupération, consolidation, graphes temporels ; OpenClaw a déjà des étiquettes de provenance et une quarantaine. | Le plus souvent liés à un framework ; l’index et la vérité ne sont pas séparés ; migration et suppression difficiles. | | Sandboxes et runtimes | E2B, Daytona, Vercel Sandbox | Calcul isolé et instantanés. | Le stockage n’est pas leur objet ; l’état disparaît avec le sandbox. | | Stockage généraliste | S3 et S3 Files, NFS, SMB, Git | Durable, mûr, avec un écosystème complet. | Ne connaît ni « exécution », ni « habilitation », ni « contamination ». | **Le vide.** Chaque brique a été construite par quelqu’un. Ce que nous ne voyons pas, c’est un contrat **auto-hébergé, ouvert et testable** qui les combine, avec l’exécution comme unité, qui lie ensemble branches, habilitations, approbation, enregistrements, mémoire et oubli, et auquel sont attachés des tests de conformité. Nous ne prétendons pas que personne n’a fait l’une de ces choses ; c’est précisément pour cela que nous empruntons autant. ## Comment il se situe par rapport aux approches voisines | Approche | Bonne pour | Relation avec Agent NAS | | --- | --- | --- | | QNAP QuAgent, Synology DSM Agent, TrueNAS MCP | Gérer un NAS en langage naturel | Complémentaires ; leurs boîtiers peuvent servir de fondation à un Overlay. | | Turso AgentFS, Redis Agent Filesystem, LayerFS | Systèmes de fichiers pour agents | Peuvent servir de moteurs Store ; Agent NAS ajoute le contrat par-dessus. | | Letta Context Repositories | Mémoire adossée à Git | Agent Home emprunte ses idées de disposition ; Letta peut être un runtime pour Agent Memory. | | Cloudflare Artifacts, Tigris, lakeFS | Stockage forkable et versionné | Peuvent être utilisés directement comme moteurs Store. | | Mem0, Zep/Graphiti | Récupération et consolidation de la mémoire | Peuvent être des indexeurs, c’est-à-dire des producteurs de dérivés. | | Architecture de mémoire d’OpenClaw | Étiquettes de provenance et quarantaine | Un précurseur ; nous mettons les mêmes idées dans la couche de stockage partagée. | | S3, S3 Files, NFS, SMB | Stockage généraliste | Peuvent servir de Store ; ils ne connaissent ni les exécutions, ni les habilitations, ni la contamination. | | E2B, Daytona, Vercel Sandbox | Calcul isolé | Complémentaires ; ils doivent être utilisés ensemble. | ## Ce que nous avons emprunté - À **Git et lakeFS :** les branches, les branches protégées, les hooks avant fusion. - À **Letta et Cursor :** les fichiers sont l’interface que les agents connaissent le mieux, et le contexte doit être dévoilé progressivement. - À **OpenClaw et à la recherche sur la sécurité de la mémoire :** la provenance ne peut pas être falsifiée, et la mémoire non fiable est mise en quarantaine. - À **la Rule of Two de Meta, CaMeL et Fides :** limiter les conséquences en dehors du modèle. - À **OAuth (RFC 8693, RFC 9396), Biscuit et UCAN :** l’échange de jetons et l’autorisation à atténuation. - À **OpenTelemetry et Certificate Transparency :** des traces exportables et une falsification détectable. - À **la recherche d’Anthropic sur le mode automatique :** garder peu d’approbations, et les placer sur les plans et les fusions. ## Ce qui est réellement nouveau Nous essayons d’être honnêtes. La liste est courte : 1. Prendre l’**exécution** comme unité, en liant ensemble branche, habilitation, budget et enregistrement. 2. Le **manifeste de lecture** et la contamination de session : appliquer la Rule of Two à la frontière du stockage. 3. Des écritures de mémoire qui portent **provenance et contamination**, et la frontière de confiance du « chargement automatique seulement si relu ». 4. Les **classes de rétention :** faire de « récupérable » ou « oubliable » un choix explicite. 5. **Une échelle de conformité avec des tests d’acceptation exécutables.** > **Un jugement qui reste à prouver.** Tout le reste, y compris les branches, les jetons, les journaux et la récupération, est une combinaison de techniques existantes. Nous croyons que les combiner en un contrat ouvert et testable a une valeur propre, mais c’est un **jugement qui reste à prouver**, pas un fait établi. --- URL canonique : https://agentnas.com/fr/compare/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Spécification > Le brouillon de spécification v0.2 définit cinq niveaux de conformité cumulatifs, de L0 Files à L4 Sync. Chaque niveau correspond à un ensemble de concepts et à un ensemble de tests d’acceptation exécutables ; une affirmation de « compatibilité » sans `conformance.json` n’est pas acceptée. > **Brouillon.** Il n’existe pas encore d’implémentation de référence ni de suite de conformité exécutable. Les tests d’acceptation ci-dessous font partie de la spécification : leur rôle est de rendre vérifiable le mot « compatible ». ## Composants de la spécification | Composant | Contenu | Version cible | | --- | --- | --- | | Core | Les six substantifs, le contrat Store, les branches et les arbres protégés, les fusions, la suppression logique. | Brouillon v0.3 | | Lease & Record | Le format des habilitations (un profil `authorization_details`), le format des enregistrements et des manifestes de lecture, `explain`. | Brouillon v0.3 | | Interfaces | La sémantique du montage, les projections Git et S3, l’API HTTP, la surface d’outils MCP. | Brouillon v0.4 | | Memory | Les conventions de notes, les dérivés et les recettes, les lectures avec budget, les pointeurs de preuve. | Brouillon v0.4 | | Guard | Les étiquettes, la contamination de session, le profil de politiques, les Gate Cards, le rapport d’oubli. | Brouillon v0.5 | | Sync | Les paquets de passation, les seuils d’étiquettes, les marqueurs de suppression. | Plus tard | | Conformance Suite | Des tests d’acceptation exécutables pour chaque niveau. | Au rythme de chaque version | ## Niveaux de conformité Les niveaux sont cumulatifs : pour revendiquer L2, il faut aussi satisfaire L0 et L1. | Niveau | Nom | Concepts couverts | En une ligne | | --- | --- | --- | --- | | L0 | Files | Agent Home, Agent Branch | Un répertoire avec historique. | | L1 | Authority | Flight Recorder, Capability Lease, Human Gate | Qui a fait quoi, et avec quelle autorité. | | L2 | Memory | Agent Memory, Budgeted Reads | Une mémoire que l’on peut lire et déplacer. | | L3 | Guard | Trust Labels, Cascade Forget | Limiter les conséquences. | | L4 | Sync | Aucun (optionnel) | Plusieurs nœuds. | ## L0 Files : un répertoire avec historique 1. Modifier des fichiers dans une branche d’exécution laisse la ligne principale protégée inchangée. 2. Une écriture directe dans un arbre protégé est refusée, même avec des identifiants valides. 3. Après la suppression d’un fichier dans un arbre protégé, il peut être restauré depuis la corbeille. 4. Un export suivi d’un import redonne un arbre et un historique identiques octet pour octet. 5. Au moins deux vues standard sont proposées : montage et Git, ou l’une des deux plus S3. ## L1 Authority : qui a fait quoi, et avec quelle autorité 1. Une requête sans habilitation est refusée, et le refus est enregistré. 2. La demande d’une habilitation fille plus large que sa mère est refusée. 3. Après l’expiration d’une habilitation, le montage passe en lecture seule ; la révocation prend effet dans le délai que l’implémentation déclare. 4. Aucune habilitation ne peut supprimer un instantané. 5. Tout commit peut être expliqué par `explain` jusqu’à une exécution, une habilitation et un manifeste de lecture. 6. La vérification de la chaîne d’enregistrements réussit ; après la falsification d’un enregistrement, elle échoue. 7. Lors d’une fusion dans un arbre protégé, la Gate Card montre un diff calculé par le NAS, et l’approbation est liée à une empreinte : modifiez le diff et l’approbation est nulle. ## L2 Memory : une mémoire que l’on peut lire et déplacer 1. Après suppression et reconstruction de tous les index, les tests de rappel de référence réussissent. 2. Les notes peuvent être lues sans la couche Memory. 3. Chaque dérivé porte une recette et ses entrées. 4. Une lecture avec budget se dégrade quand le budget est trop petit, et déclare la vue qu’elle a réellement renvoyée. 5. Les pointeurs de preuve sont vérifiables : après des changements de commits, un pointeur désigne toujours le contenu d’origine. ## L3 Guard : limiter les conséquences 1. Sous une habilitation avec B et C, lorsqu’une session qui a lu du contenu `external` déclenche une action de classe C, elle est refusée ou confiée à une validation. 2. Un dérivé hérite de l’union des étiquettes de ses entrées. 3. Les notes écrites par une session contaminée ne sont pas chargées automatiquement. 4. Une demande d’oubli produit un rapport qui inclut « ce qui n’est pas couvert » ; une conservation juridique (legal hold) peut bloquer l’oubli. 5. L’évaluation des politiques n’appelle pas de LLM : le moteur de politiques n’effectue aucun appel sortant vers un modèle, ce qui permet de l’auditer. ## L4 Sync : plusieurs nœuds 1. Après synchronisation de deux nœuds, les arbres sont identiques. 2. Les objets très sensibles ne sont pas envoyés vers un nœud d’habilitation inférieure. 3. Les marqueurs de suppression liés à l’oubli se propagent vers le pair. 4. Un paquet de passation peut être exécuté chez le pair, et les habilitations ne font que se restreindre. ## Le format de déclaration Une implémentation doit publier un `conformance.json` indiquant le niveau auquel elle se conforme, le résultat de chaque test et les écarts connus. Une affirmation de « compatibilité » sans ce fichier n’est pas acceptée. *conformance.json* ```json { "implementation": "example-nas", "version": "0.1.0", "spec": "0.2", "level": "L1", "tests": { "L0.1": "pass", "L0.2": "pass", "L0.3": "pass", "L0.4": "pass", "L0.5": "pass", "L1.1": "pass", "L1.2": "pass", "L1.3": "pass", "L1.4": "pass", "L1.5": "pass", "L1.6": "pass", "L1.7": "pass" }, "deviations": ["L1.3: revocation takes effect within 60 seconds"] } ``` ## Versions et compatibilité - Versionnement sémantique. Aucune compatibilité n’est garantie pendant 0.x. - Les nouveaux champs sont rétrocompatibles. - Un champ obsolète garde une période d’avertissement d’au moins une version. ## Ce que la spécification ne couvre pas encore Les détails de version des protocoles de transport, un langage de politiques précis, l’algorithme de signature des jetons, des moteurs de stockage précis et les interfaces utilisateur. --- URL canonique : https://agentnas.com/fr/spec/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Feuille de route > La feuille de route est ordonnée en maintenant, ensuite, plus tard et non prévu, sans promesses année par année : un calendrier de trois ans écrit en 2026 serait très probablement réécrit par les faits dès la première année. ## Maintenant, ensuite, plus tard - **Maintenant (T4 2026)** · En cours · **Concept, brouillon de spécification et site web**: Le concept et le brouillon de spécification v0.2, et le site web en 8 langues. Recueil de retours : interroger 3 à 5 vrais utilisateurs qui combinent déjà `AGENTS.md` et Git, pour tester les paris B1 à B7. - **Ensuite (objectif : premier semestre 2027)** · À suivre · **Implémentation de référence v0 et spécification v0.3**: Implémentation de référence v0 (Lite et Overlay) : backends Git et instantanés de système de fichiers, émission d’habilitations, enregistrements et manifestes de lecture, une CLI et une suite de conformité pour L0 à L1 ; spécification v0.3 (Core, Lease & Record). Un scénario démontrable : un agent travaille la nuit sur une branche, et le matin vous approuvez la fusion sur une Gate Card. - **Plus tard (selon les retours)** · Plus tard · **Memory, Guard, la salle de contrôle et Sync**: La couche Memory et la surface d’outils MCP (L2) ; Guard : étiquettes, contamination et oubli en cascade (L3) ; la salle de contrôle ; les formes Team et Cloud ; Sync (L4). > **Non contraignant.** Ceci est une intention, pas une promesse. Ce qui définit « compatible », ce sont les niveaux de conformité, pas le calendrier. ## Le point de contrôle (ce qui prouverait que nous avons tort) Le critère pour terminer « ensuite » n’est **pas** une liste de fonctionnalités. C’est : fonctionner pendant une semaine dans au moins trois flux de travail réels ; un taux d’approbation des validations inférieur à 95 % ; et au moins un vrai problème détecté. Si nous n’y arrivons pas, nous revenons en arrière et nous changeons les concepts au lieu d’empiler des fonctionnalités. ## Non prévu - Notre propre moteur de stockage. - Notre propre base de données vectorielle. - L’hébergement de modèles. - Une place de marché de compétences. - Des jetons et des blockchains. - Du matériel dédié. ## Questions laissées ouvertes à dessein - Comment le champ libre `purpose` d’une habilitation évolue-t-il vers une intention structurée que les machines peuvent vérifier ? - Comment les outils de fusion sémantique sont-ils enregistrés et jugés fiables ? - La granularité des étiquettes doit-elle être le fichier ou le paragraphe ? - Dans un contexte multi-locataire, comment gouverner le vocabulaire des étiquettes ? - Comment décrire à l’extérieur le délai de propagation d’une révocation entre nœuds ? - Comment mesurer la qualité de la mémoire ? Quel est le critère de non-régression quand le modèle ou les embeddings changent ? - Pour un fait déduit de plusieurs sources, comment Cascade Forget définit-il le périmètre touché ? - À fort débit, comment arbitrer le coût de stockage et la granularité des manifestes de lecture ? - Quelle est la meilleure interface pour une revue par lots et par niveaux ? Comment mesurer et régler les seuils de fusion automatique ? - Comment distribuer et révoquer les racines de confiance entre organisations ? --- URL canonique : https://agentnas.com/fr/roadmap/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Principes de conception > Huit thèses guident chaque arbitrage d’Agent NAS ; sept paris disent ce sur quoi il mise et ce qui se passe si le pari est perdu. Une conception qui espère tenir des années doit dire quand elle aura tort. ## 1. L’unité d’accès est l’exécution, pas le compte La pratique actuelle consiste à donner à un agent un jeton de longue durée ou un compte humain : le jeton de l’incident d’avril 2026 était « fait pour gérer des domaines, mais pouvait tout faire ». Une exécution a un début, une fin, un but et un responsable, ce qui en fait une unité naturelle d’autorisation et de responsabilité. *Exclut :* les clés partagées, les jetons de longue durée et les comptes humains empruntés. ## 2. Annuler coûte moins cher que prévenir La prévention (approbations, classifieurs, règles dans les prompts) fuira toujours : les classifieurs laissent passer des choses, les gens font pire, et les modèles enfreignent les principes écrits dans leurs prompts. Rendre les erreurs **annulables** (branches, suppression logique, instantanés) est bien plus facile que de rendre chaque action correcte, et plus facile à vérifier. Corollaire : **le chemin de reprise doit se trouver hors du rayon d’impact de ce qu’il protège** ; les instantanés sont donc détenus par le propriétaire et échappent au pouvoir de toute habilitation. *Exclut :* considérer « une ligne dans le prompt qui demande confirmation » comme un contrôle. ## 3. L’autorité se prête par tâche, elle ne s’accorde pas par identité Une exécution reçoit une habilitation étroite, limitée dans le temps et assortie de budgets ; les clés de longue durée restent chez l’orchestrateur ou le propriétaire, et le modèle ne les voit jamais. *Exclut :* les permissions permanentes, larges et de longue durée. ## 4. Les notes sont la vérité, l’intelligence est un cache La mémoire devrait être des fichiers que les gens peuvent lire et modifier ; les index, les embeddings et les résumés sont des dérivés jetables et reconstructibles. Ainsi l’algorithme de récupération peut changer sans perdre la mémoire, et l’empoisonnement comme la suppression deviennent maîtrisables. *Exclut :* les magasins de mémoire opaques qu’on ne peut ni inspecter ni déplacer. ## 5. La provenance est la colonne vertébrale Chaque souvenir, chaque dérivé et chaque fusion peut répondre à « d’où cela vient-il, et qu’est-ce qui l’a influencé ? ». La provenance est la base de l’audit, mais aussi du contrôle de l’empoisonnement, des étiquettes de confiance et de l’oubli. *Exclut :* la mémoire sans provenance. ## 6. La politique est déterministe, et les modèles ne peuvent que resserrer Les décisions d’autorisation sont prises par du code, pas par l’« avis » d’un modèle. Un classifieur ou un LLM peut suggérer que « cette étape demande une approbation », mais ne peut jamais approuver. *Exclut :* laisser un modèle décider lui-même si une action peut passer. ## 7. Garder le stockage ennuyeux, mettre l’innovation dans le contrat Pas de nouveau moteur ; les fichiers d’abord, parce que l’interface que les modèles connaissent le mieux est le fichier ; les protocoles changeront, les six substantifs non. *Exclut :* inventer un nouveau moteur de stockage au nom de l’IA. ## 8. Ce qui est rare, ce sont les tokens et l’attention humaine Les lectures ont un budget ; les approbations sont peu nombreuses et précises, et se placent là où une personne peut vraiment juger : sur les plans et les fusions, pas à chaque action. *Exclut :* renvoyer des fichiers entiers par défaut ; une fenêtre contextuelle pour chaque action. ## Sept paris et ce qui les réfuterait Une conception qui espère tenir des années doit dire sur quoi elle parie et quand elle aurait tort. | Pari | Fondement | Si le pari est perdu | | --- | --- | --- | | B1 Les agents continueront d’utiliser le système de fichiers et Git comme principal support de travail | Plusieurs runtimes grand public sont déjà passés aux fichiers. | S’ils passent à des « API de mémoire » dédiées, Agent Home se dégrade en format d’export ; les autres concepts ne dépendent pas des fichiers et tiennent toujours. | | B2 « Une exécution » reste l’unité naturelle d’autorisation et de responsabilité | Les orchestrateurs lancent généralement des sandboxes par tâche ou par session. | Si des processus autonomes de longue durée apparaissent, les habilitations deviennent des renouvellements continus avec budgets, et le concept demeure. | | B3 L’injection de prompt ne sera pas éradiquée au niveau du modèle dans un avenir prévisible | Les termes mêmes de Meta ; les taux d’échec des classifieurs ; plusieurs études d’attaques. | Si elle l’est, les Trust Labels deviennent une couche bon marché de défense en profondeur. | | B4 L’attention humaine reste rare | Les données publiées par Anthropic. | Si l’automatisation complète devient assez fiable, une Human Gate cède la place à une politique d’autorisation préalable, et l’audit demeure. | | B5 La couche de stockage est le bon endroit pour imposer la provenance et la contamination | La recherche sur la sécurité de la mémoire insiste sur la provenance à l’écriture ; OpenClaw l’a fait à l’intérieur d’un seul runtime. | Si chaque runtime le fait bien lui-même, le NAS n’a plus qu’à stocker les étiquettes, et son rôle s’amincit. | | B6 La mémoire partagée entre runtimes et agents deviendra un vrai besoin | La collaboration multi-agents ; le coût de migration d’un framework. | Si la mémoire reste une fonction privée de chaque framework, la valeur d’Agent Memory tient surtout à la portabilité pour les particuliers et les petites équipes. | | B7 Les protocoles changeront, mais « des fichiers et des outils » comme deux ports resteront stables | Les migrations de version de MCP ; A2A 1.0. | Remplacer les adaptateurs ; c’est pourquoi les adaptateurs isolent les protocoles. | ## Ce que nous attendons de stable, et ce qui changera | Attendu stable | Attendu changeant | | --- | --- | | Les six substantifs | Les protocoles et transports précis | | La convention de répertoire d’un Home | Les modèles d’embedding et les algorithmes de récupération | | Les quatre promesses | Les formats de jetons | | La garantie « exporter, c’est pouvoir partir » | Les frameworks d’agents et les interfaces homme-machine | --- URL canonique : https://agentnas.com/fr/principles/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # FAQ > Réponses aux questions qu’on pose en premier sur Agent NAS : ce que c’est, en quoi il diffère des outils de stockage et de mémoire existants, comment il traite la sécurité et la vie privée, et où en est le projet. ## Les bases ### Qu’est-ce qu’Agent NAS ? Agent NAS est un stockage en réseau conçu autour de l’exécution : chaque exécution d’un agent travaille dans une branche isolée et accède aux données par une habilitation étroite et de courte durée ; chaque modification peut être tracée et annulée ; et la mémoire, ce sont des fichiers ordinaires avec leur provenance. Il est servi par des montages, Git, S3 et MCP. ### Agent NAS est-il un produit que je peux acheter ou télécharger ? Pas encore. C’est pour l’instant un concept doté d’un brouillon de spécification (v0.2, novembre 2026). L0 et L1 peuvent être construits dès aujourd’hui avec des briques existantes ; l’objectif pour l’implémentation de référence v0 est le premier semestre 2027, et la suite figure dans la [feuille de route](https://agentnas.com/fr/roadmap/). ### En quoi diffère-t-il des agents d’IA que livrent les fabricants de NAS ? Les agents de fabricants comme QNAP, Synology et TrueNAS gèrent le boîtier. Agent NAS spécifie comment d’autres agents travaillent sur les données qu’il contient : branches, habilitations, mémoire et oubli. Les deux se complètent ; voir la [comparaison](https://agentnas.com/fr/compare/). ### En quoi diffère-t-il d’une base de données vectorielle ou d’un framework de mémoire ? Ce sont des outils de récupération et de consolidation, alors que, dans Agent NAS, la vérité ce sont des notes ordinaires avec leur provenance. Un magasin vectoriel ou un framework de mémoire peut se placer sous [Agent Memory](https://agentnas.com/fr/concepts/agent-memory/) comme indexeur, et l’index peut toujours être jeté puis reconstruit. ### Est-il open source ? La spécification et ce site sont sous licence CC BY 4.0. L’implémentation de référence doit être publiée en open source sous Apache-2.0. ## Conception et sécurité ### Pourquoi des fichiers et Git plutôt qu’une base de données ? Les agents convergent vers les fichiers : les instructions dans `AGENTS.md`, les compétences dans `SKILL.md`, la mémoire en Markdown, l’historique dans Git. N’importe quel outil et n’importe quel modèle peut lire des fichiers, ils se comparent facilement et s’emportent facilement. Les bases de données et les index sont toujours utilisés, mais comme couche dérivée que l’on peut reconstruire. ### Quel est le pire qui puisse arriver quand une exécution tourne mal ? Le pire, c’est de perdre une branche jetable : la ligne principale protégée ne change que par des fusions relues, les suppressions sont logiques et les instantanés sont hors de portée de toute habilitation. C’est vrai quand l’erreur se produit à l’intérieur du NAS ; un e-mail déjà envoyé ou une API externe déjà appelée, le NAS ne peut pas l’annuler. ### Quel rapport entre une habilitation et un jeton OAuth ? Une habilitation est un jeton d’accès OAuth : demandé par échange de jetons (RFC 8693) et décrivant chemins et actions avec les Rich Authorization Requests (RFC 9396). Ce qu’Agent NAS ajoute, c’est la convention au niveau de l’exécution, avec les branches, les budgets et les propriétés de la Rule of Two. Voir [Capability Lease](https://agentnas.com/fr/concepts/capability-lease/). ### Pourquoi « des notes plus un cache » pour la mémoire ? Pour qu’on puisse l’inspecter, la corriger, la déplacer et l’oublier. Les notes sont des fichiers ; les index, les embeddings et les résumés en sont calculés avec une recette documentée. Si vous changez de modèle d’embedding, le système recalcule en arrière-plan. Les notes écrites par une session contaminée vont d’abord en quarantaine et ne sont pas chargées automatiquement tant qu’elles ne sont pas relues. ### Agent NAS peut-il arrêter l’injection de prompt ? Non. Rien en dehors du modèle ne peut l’arrêter complètement. Agent NAS limite ce qu’un agent injecté peut faire : les [Trust Labels](https://agentnas.com/fr/concepts/trust-labels/) empêchent une session qui a lu du contenu externe de détenir aussi des données sensibles et un canal de sortie, et les actions à conséquences demandent une [Human Gate](https://agentnas.com/fr/concepts/human-gate/). Les limites assumées figurent sur la page [sécurité](https://agentnas.com/fr/security/). ### Comment traite-t-il le « droit à l’oubli » ? Par [Cascade Forget](https://agentnas.com/fr/concepts/cascade-forget/) : il supprime, en suivant le lignage, les résumés, les embeddings et les notes dérivés d’une source, traite l’historique selon la classe de rétention et détruit les clés de la classe `sensitive` (effacement cryptographique). Son rapport énumère explicitement ce qu’il ne peut pas couvrir : copies hors du NAS, journaux du fournisseur de modèle et poids du modèle. Il ne peut pas faire oublier quoi que ce soit à un modèle. ### Dois-je utiliser MCP ? Non. MCP n’est qu’une des interfaces du plan de contrôle ; les fichiers, Git et S3 n’en ont pas besoin, et la couche de protocole est conçue pour être remplaçable. ## Adoption et avenir ### Va-t-il remplacer mon NAS ou mon stockage cloud actuel ? Non. La forme de déploiement Overlay place une passerelle devant un NAS, un stockage objet ou un hébergeur Git existant et ne gère qu’un seul répertoire ou bucket à l’intérieur. Un stockage cloud peut aussi servir de Store. ### Quels frameworks et runtimes d’agents fonctionnent avec lui ? Tout runtime capable de monter un répertoire ou d’utiliser Git, S3 ou MCP. La disposition d’un Agent Home suit des conventions ouvertes (`AGENTS.md`, Agent Skills, Markdown avec frontmatter YAML) ; Claude Code, Cursor, Codex, OpenHands, LangGraph et les frameworks maison sont donc tous des candidats. ### Puis-je partir à tout moment ? Oui. Tout peut être exporté sous forme de fichiers ordinaires et d’historique Git. C’est l’une des quatre promesses, pas une fonctionnalité. ### Quand ne faut-il pas utiliser Agent NAS ? Quand vous avez un seul agent et des données que vous referiez sans peine : un dépôt Git avec un `AGENTS.md` suffit. D’autres cas figurent dans les [cas d’usage](https://agentnas.com/fr/use-cases/). ### Comment le citer ou y contribuer ? Chaque page indique son URL canonique et une citation suggérée. Pour contribuer, ouvrez une issue ou une discussion sur GitHub. La [page À propos](https://agentnas.com/fr/about/) donne les détails. --- URL canonique : https://agentnas.com/fr/faq/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Glossaire > Ce glossaire définit chaque terme qu’utilise Agent NAS : les neuf concepts nommés et le vocabulaire associé. Les noms des concepts sont des termes forgés et restent en anglais dans toutes les langues. ## Les neuf concepts - **[Agent Home (répertoire personnel)](https://agentnas.com/fr/concepts/agent-home/)**: **Un Agent Home** est un répertoire par rôle, avec historique : instructions, compétences, mémoire, journal et espace de travail, le tout en fichiers ordinaires. N’importe quel runtime peut y entrer, et vous pouvez tout emporter en partant. - **[Agent Branch (branche d’agent)](https://agentnas.com/fr/concepts/agent-branch/)**: **Une Agent Branch** permet à chaque exécution de travailler sur une branche en copy-on-write. Les modifications n’atteignent la ligne principale protégée que par une fusion relue (une Agent PR), et l’on peut poser un point de contrôle et restaurer à tout moment. - **[Flight Recorder (enregistreur de vol)](https://agentnas.com/fr/concepts/flight-recorder/)**: **Un Flight Recorder** est un enregistrement en ajout seul, chaîné par hachage, tenu pour chaque exécution : ce que l’exécution a lu (le manifeste de lecture), ce qu’elle a écrit, ce qui a été autorisé ou refusé, et qui a approuvé quoi. Il se trouve à côté des données et répond à une seule question : « qu’est-ce qui a pu influencer ce changement ? » - **[Capability Lease (habilitation de capacité)](https://agentnas.com/fr/concepts/capability-lease/)**: **Une Capability Lease** est une autorisation portant sur des données précises et des opérations précises, avec une expiration explicite et des budgets. Elle est délivrée à **une seule exécution** et c’est le seul moyen pour une exécution de toucher au NAS. Une habilitation fille ne peut qu’être plus étroite que sa mère. - **[Human Gate (validation humaine)](https://agentnas.com/fr/concepts/human-gate/)**: **Une Human Gate** est un point de contrôle déclenché par la politique : avant qu’une action **irréversible, tournée vers l’extérieur ou élevant les privilèges** ne prenne effet, une personne (ou un approbateur désigné) approuve une action concrète, entièrement affichée. Elle est conçue pour être rare, précise et difficile à valider par réflexe. - **[Trust Labels (étiquettes de confiance)](https://agentnas.com/fr/concepts/trust-labels/)**: **Les Trust Labels** sont deux très petits jeux d’étiquettes attachés aux données, **l’origine** (`owner`, `agent`, `external`) et **la sensibilité** (`public`, `private`, `secret`), plus **la contamination de session**. Le NAS applique la Rule of Two comme un invariant de session : une session ne peut pas réunir à la fois [A] a lu du contenu externe, [B] touche à des données sensibles et [C] modifie un état protégé ou communique vers l’extérieur. Compléter la troisième exige une [Human Gate](https://agentnas.com/fr/concepts/human-gate/). - **[Agent Memory (mémoire de l’agent)](https://agentnas.com/fr/concepts/agent-memory/)**: **Agent Memory** = **des notes que vous pouvez lire et modifier** + **des index que vous pouvez jeter à tout moment**. Chaque note cite ses sources ; les index (texte intégral, vectoriel, graphe, plan) ne sont que des dérivés des notes ; et les tâches de maintenance en arrière-plan ne font que **proposer** des modifications et ne réécrivent jamais le journal brut. - **[Budgeted Reads (lectures avec budget)](https://agentnas.com/fr/concepts/budgeted-reads/)**: **Budgeted Reads** désigne des lectures mesurées dans un budget de tokens : un même fichier peut être lu à différents niveaux de détail, du plan et de la section à la plage de lignes et au texte intégral. L’agent demande « la meilleure vue qui tient dans N tokens » et reçoit en retour des pointeurs de preuve vers la source exacte. - **[Cascade Forget (oubli en cascade)](https://agentnas.com/fr/concepts/cascade-forget/)**: **Cascade Forget** est une suppression qui suit le lignage : quand une source est supprimée, ou que quelqu’un demande à être oublié, le NAS retrouve tout ce qui en dérive, y compris résumés, embeddings, notes qui la citent, caches et liens de partage, le supprime ou le re-dérive sans cette source, et délivre un **rapport** : ce qui a été fait, et ce qui n’a pas pu l’être. ## Termes complémentaires - **Principal (sujet)**: Une entité qui peut être authentifiée et tenue pour responsable : une personne, un agent, un service ou un nœud. - **Run (exécution)**: Une exécution avec un début, une fin, un but et un responsable. Une exécution détient une habilitation racine et possède une branche. - **Protected tree (arbre protégé)**: Un arbre qui ne peut être mis à jour que par une fusion relue et n’accepte jamais d’écritures directes, par exemple `main`. - **Read manifest (manifeste de lecture)**: L’enregistrement agrégé des chemins, des commits, des plages et des hachages de contenu qu’une exécution a lus. Il ne contient pas le contenu. - **Evidence pointer (pointeur de preuve)**: Une référence vérifiable de la forme `nas:////@#L12-L18` vers des lignes précises d’un commit. - **Derived data (données dérivées)**: Des données calculées à partir des notes au moyen d’une recette, comme un index, un embedding ou un résumé. Elles peuvent être jetées et reconstruites. - **Recipe (recette)**: Tout ce qu’il faut pour produire un objet dérivé : le modèle et sa version, le découpeur (chunker) et les paramètres. - **Lineage (lignage)**: Le graphe de dépendances entre les objets dérivés et les entrées à partir desquelles ils ont été calculés. - **Session taint (contamination de session)**: L’union des étiquettes de tout ce qu’une session a lu. Elle ne fait que croître au sein d’une session et détermine ce que celle-ci peut faire ensuite. - **Rule of Two (règle de deux)**: Une heuristique de Meta : tant que l’injection de prompt n’est pas résolue de façon fiable, une session devrait avoir au plus deux des trois propriétés suivantes : [A] elle traite des entrées non fiables, [B] elle accède à des données sensibles, [C] elle modifie un état ou communique vers l’extérieur. - **Declassification (déclassification)**: Abaisser la sensibilité d’une donnée ou relever la confiance dans son origine. Uniquement par une Human Gate ou par une passation structurée validée par un schéma. - **Policy envelope (enveloppe de politiques)**: Une plage fixée à l’avance par le propriétaire, à l’intérieur de laquelle les habilitations sont émises automatiquement. Ce qui sort de cette plage passe par une Human Gate. - **Credential Broker (courtier d’identifiants)**: Un composant qui détient les secrets de longue durée et ne délivre des jetons aval de courte durée que pour des actions de sortie approuvées. Les modèles et les exécutions ne voient jamais les secrets de longue durée. - **Agent PR (demande de fusion d’agent)**: Une proposition structurée de fusion d’une branche dans une cible, avec le diff, la provenance, les résultats des vérifications et un résumé des étiquettes. - **Retention class (classe de rétention)**: L’une de `scratch`, `normal` ou `sensitive`, choisie à l’écriture. Elle détermine les sauvegardes, l’historique et la possibilité de détruire les données. - **Crypto-shredding (effacement cryptographique)**: Détruire une clé pour que toute copie chiffrée avec elle devienne illisible. - **Conformance level (niveau de conformité)**: Un niveau de L0 à L4. Chacun correspond à un ensemble de concepts et à un ensemble de tests d’acceptation exécutables. - **MCP**: Model Context Protocol : un protocole ouvert entre les agents et les outils ou sources de données. - **A2A**: Le protocole Agent2Agent : un protocole ouvert permettant aux agents de collaborer sur des tâches. --- URL canonique : https://agentnas.com/fr/glossary/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # À propos du projet > agentnas.com est la maison du concept Agent NAS et de son brouillon de spécification. C’est un projet ouvert qui vise à donner aux personnes et aux agents un vocabulaire commun, et un contrat testable que plusieurs implémentations indépendantes peuvent suivre. ## État En novembre 2026, Agent NAS est un concept accompagné d’un brouillon de spécification (v0.2). Il n’existe pas encore d’implémentation de référence ni de suite de conformité exécutable. La v0.2 est une révision de réalisme : treize concepts ont été ramenés à neuf, et chacun indique comment commencer petit et quelles sont ses limites assumées. Ce site web est la première chose publiée par le projet. Voir la [feuille de route](https://agentnas.com/fr/roadmap/) pour ce qui est prévu. ## Licence Le texte et les schémas de ce site et de la spécification sont sous licence [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) : vous pouvez les partager et les adapter en citant la source. L’implémentation de référence doit être publiée sous Apache-2.0. ## Comment citer Citez la page que vous avez utilisée, et reprenez sa définition mot pour mot quand vous le pouvez. Chaque page affiche en bas son URL canonique et une citation suggérée. Pour le projet dans son ensemble : *Citation* ```text Projet Agent NAS. « Agent NAS : stockage en réseau pour agents d’IA. » Spécification v0.2 (brouillon), novembre 2026. https://agentnas.com/fr/what-is-agent-nas/ ``` *BibTeX* ```bibtex @misc{agentnas2026, title = {Agent NAS : stockage en réseau pour agents d’IA}, author = {{Agent NAS project}}, year = {2026}, howpublished = {Spécification v0.2 (brouillon)}, url = {https://agentnas.com/fr/what-is-agent-nas/} } ``` ## Gouvernance - **La spécification est distincte des implémentations.** De nombreuses implémentations sont bienvenues ; ce qui définit « compatible », ce sont les tests de conformité et `conformance.json`, pas une marque. - **Processus.** Propositions publiques (issues et PR) ; les changements importants doivent exposer leur motivation, leurs preuves et leurs contre-exemples. - **Nom.** « Agent NAS » est un nom descriptif du concept ; revendiquer un niveau de conformité exige de publier un `conformance.json`. - **Le désaccord est bienvenu.** Les contestations de n’importe quelle thèse sont précieuses, en particulier les [sept paris](https://agentnas.com/fr/principles/). ## Participer Les corrections, critiques et notes d’implémentation sont les bienvenues. Ouvrez une issue ou une discussion dans le [dépôt du projet](https://github.com/xwzy/agentnas.com). Ce site ne publie pas d’adresse électronique ; les signalements de sécurité concernant la spécification passent par le même canal. ## Pour les agents et les robots d’indexation - Chaque page a un jumeau Markdown : ajoutez `index.md` à son adresse, ou envoyez `Accept: text/markdown`. - [/fr/llms.txt](https://agentnas.com/fr/llms.txt) est un index sélectionné, et [/fr/llms-full.txt](https://agentnas.com/fr/llms-full.txt) est le texte intégral. - Un serveur MCP pour cette documentation fonctionne à `https://agentnas.com/mcp`, décrit par sa [server card](https://agentnas.com/mcp/server-card). - Un point d’accès de recherche, `POST /api/search`, est décrit dans [/openapi.json](https://agentnas.com/openapi.json). - L’[AI Catalog](https://agentnas.com/.well-known/ai-catalog.json) et le [plan du site](https://agentnas.com/sitemap.xml) recensent tout. - Le contenu peut être indexé, cité et utilisé comme matière de réponses en toute liberté. Voir [/robots.txt](https://agentnas.com/robots.txt). --- URL canonique : https://agentnas.com/fr/about/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Agent Home (répertoire personnel) *Un répertoire par rôle, avec historique. Des fichiers ordinaires que vous emportez.* > **Un Agent Home** est un répertoire par rôle, avec historique : instructions, compétences, mémoire, journal et espace de travail, le tout en fichiers ordinaires. N’importe quel runtime peut y entrer, et vous pouvez tout emporter en partant. **AN-01** · Niveau de conformité : L0 Files · Groupe : Travail ## Le problème L’état d’un agent est dispersé entre des bases de données de frameworks, des API de mémoire hébergées chez des fournisseurs et des disques de sandbox qui peuvent disparaître à tout moment. Changez de framework ou de fournisseur et l’état est perdu ; quand quelque chose tourne mal, il n’y a pas d’endroit unique où voir ce que l’agent sait réellement. Dans le même temps, les agents grand public convergent vers les fichiers : `AGENTS.md`, Agent Skills, dépôts de mémoire adossés à Git. Ce qui manque n’est pas un nouveau format, mais un lieu pour les accueillir, avec **un propriétaire, un historique, des quotas et un export garanti**. ## Fonctionnement - **La disposition suit des conventions ouvertes.** `AGENTS.md`, le `SKILL.md` d’Agent Skills et du Markdown avec frontmatter YAML, comme dans l’esquisse ci-dessous. Nous n’inventons pas de format. - **Un Home appartient à un rôle, pas à une seule exécution.** Les exécutions l’utilisent par des [branches](https://agentnas.com/fr/concepts/agent-branch/) : les modifications atterrissent d’abord sur une branche et sont fusionnées dans le Home après relecture. - **Il a un historique.** Chaque modification est un commit. `nas export` ou `git clone` emporte tout le Home, y compris les métadonnées en texte brut de `.nas/`. - **Le contexte de démarrage, c’est simplement la lecture de quelques fichiers :** `AGENTS.md`, `memory/MEMORY.md` et un résumé de la boîte de réception. Il n’y a pas de protocole de réveil particulier ; un NAS peut proposer par commodité une vue `briefing` plafonnée en tokens, mais ce n’est pas obligatoire. - **Seules les notes relues se chargent automatiquement.** Seules les notes marquées `reviewed` entrent dans `MEMORY.md` et dans le contexte chargé automatiquement ; voir [Trust Labels](https://agentnas.com/fr/concepts/trust-labels/) et [Agent Memory](https://agentnas.com/fr/concepts/agent-memory/). - **Cycle de vie.** Création à partir d’un modèle, quotas, archivage et retrait, avec un héritier qui peut être désigné au moment du retrait. ## Commencer petit - Créez un répertoire avec `AGENTS.md`, `skills/` et `memory/`, et lancez `git init`. Faites pointer `CLAUDE.md` et les fichiers analogues vers `AGENTS.md` par des liens symboliques. - Lancez `git worktree add` avant chaque exécution pour qu’elle travaille dans son propre arbre de travail. - C’est L0 : sans aucun logiciel Agent NAS, vous avez déjà un Home avec historique que vous pouvez emporter. ## Esquisse d’interface À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3. *layout* ```text /agents/cleo/ # a role's Home: it belongs to the role, not to one run ├── AGENTS.md # instructions (open convention) ├── skills/ # Agent Skills: one directory per skill │ └── release-notes/SKILL.md ├── memory/ │ ├── MEMORY.md # reviewed core memory: auto-loaded, token-capped │ ├── notes/ # notes: Markdown + YAML frontmatter │ ├── journal/ # raw log: append-only │ └── quarantine/ # unreviewed notes: recallable, never auto-loaded ├── inbox/ # tasks and messages received ├── outbox/ # deliverables and replies ├── workspace/ # scratch space (retention class: scratch) └── .nas/ # plain-text metadata: role.yaml, limits.yaml, maintenance.yaml ``` ## Ce que demande la spécification - Un Home DOIT pouvoir être reconstruit à partir du seul Store ; sa lecture NE DOIT PAS dépendre de données dérivées. - Les métadonnées de `.nas/` DOIVENT être en texte brut et DOIVENT être exportées avec le Home. - Le contexte chargé automatiquement DOIT être plafonné en tokens et DOIT provenir uniquement de notes relues. - La disposition DEVRAIT suivre des conventions ouvertes : `AGENTS.md`, `SKILL.md`, Markdown avec frontmatter YAML. - Les exécutions DOIVENT utiliser un Home par des branches. ## Ce qui est emprunté, et ce qui est nouveau Tout ce qui précède est emprunté, et **très peu est nouveau** : la disposition et Git existent déjà. La seule nouveauté est de traiter le Home comme un objet de première classe, avec quotas, héritier et garantie d’export, et de poser la frontière de confiance selon laquelle seules les notes relues se chargent automatiquement. - [AGENTS.md](https://agents.md) - [Agent Skills](https://agentskills.io/specification) - [Letta Context Repositories](https://www.letta.com/blog/context-repositories/) - [Turso AgentFS](https://github.com/tursodatabase/agentfs) - [Cloudflare Artifacts](https://blog.cloudflare.com/artifacts-git-for-agents-beta/) ## Limites assumées - Les formats de mémoire natifs diffèrent d’un framework à l’autre ; les convertir vers les conventions du Home se fait donc avec perte. - Cela n’aide que si les runtimes acceptent de lire et d’écrire ces fichiers. - L’état caché côté fournisseur, comme une mémoire hébergée dans le cloud d’un fournisseur, ne peut pas être rapatrié. ## Questions ouvertes - Comment faire correspondre dans les deux sens les formats des différents frameworks avec le Home ? - Comment maîtriser la charge et la latence au démarrage pour un Home très volumineux ? ## Questions ### Un Agent Home est-il simplement un dépôt Git ? Pour l’essentiel, et c’est voulu : on peut simplement le `git clone`. La différence est qu’il a aussi un propriétaire (un rôle), des quotas, un héritier, une garantie d’export et la règle que seules les notes relues se chargent automatiquement, et que le NAS fait respecter ces points au lieu de les laisser à l’état de convention. ### Vais-je perdre la mémoire si je change de framework d’agent ? Non, tant que le nouveau runtime accepte de lire les fichiers. Un Home utilise des conventions ouvertes : `AGENTS.md`, `SKILL.md` et les notes Markdown ne dépendent d’aucun framework. Les éléments dont la conversion se fait avec perte doivent être marqués comme non relus à l’import. ### Dois-je installer Agent NAS pour utiliser un Home ? Non. Un répertoire Git avec un `AGENTS.md` est un Home L0. Ce qu’un NAS ajoute, ce sont des quotas, des fusions protégées, des habilitations et une piste d’audit, pas un format de fichier. ## Concepts liés - [Agent Branch (branche d’agent)](https://agentnas.com/fr/concepts/agent-branch/): Chaque exécution travaille sur une branche en copy-on-write. Seule une fusion relue atteint la ligne principale. - [Agent Memory (mémoire de l’agent)](https://agentnas.com/fr/concepts/agent-memory/): Des notes que vous pouvez lire et modifier font la vérité. Les index sont un cache que vous pouvez jeter. - [Capability Lease (habilitation de capacité)](https://agentnas.com/fr/concepts/capability-lease/): Une autorisation étroite pour une exécution, avec une expiration et des budgets. Les habilitations filles ne peuvent être que plus étroites. --- URL canonique : https://agentnas.com/fr/concepts/agent-home/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Agent Branch (branche d’agent) *Chaque exécution travaille sur une branche en copy-on-write. Seule une fusion relue atteint la ligne principale.* > **Une Agent Branch** permet à chaque exécution de travailler sur une branche en copy-on-write. Les modifications n’atteignent la ligne principale protégée que par une fusion relue (une Agent PR), et l’on peut poser un point de contrôle et restaurer à tout moment. **AN-02** · Niveau de conformité : L0 Files · Groupe : Travail ## Le problème Les agents font des erreurs à la vitesse des machines, et les données partagées n’offrent aucun moyen d’« essayer, voir le diff, relire, annuler ». Les agents en parallèle se marchent aussi dessus. Lors d’un incident d’avril 2026, un agent a utilisé un jeton trop large pour supprimer en 9 secondes un volume de production et les sauvegardes situées sur le même volume. S’il n’avait pu écrire que sur une branche, si les suppressions avaient été logiques et si les instantanés avaient été hors de son autorité, les dégâts auraient été bien moindres. ## Fonctionnement - **Les branches sont bon marché** (selon le moteur, idéalement proches de O(1)). Une habilitation accorde l’écriture **à l’intérieur de la branche** et `propose` vers la cible. - **Arbres protégés.** La ligne principale ne peut être mise à jour que par une fusion : même un identifiant qui a fuité ne peut pas y écrire directement. - **Agent PR.** Le diff, l’intention, la provenance (un résumé du manifeste de lecture), les résultats des vérifications et un résumé des étiquettes. Si les vérifications passent et que la politique l’autorise, la fusion est automatique ; sinon elle passe par une [Human Gate](https://agentnas.com/fr/concepts/human-gate/). - **Suppression logique.** Les suppressions dans un arbre protégé vont dans une corbeille, conservées 7 jours par défaut ; les instantanés appartiennent au propriétaire et sont **hors de l’autorité de toute habilitation**. - **Points de contrôle.** Des instantanés nommés ; `restore` ramène les fichiers à un point de contrôle. - **Fusion.** Le texte utilise une fusion à trois voies et les autres fichiers fusionnent fichier par fichier. En cas de conflit, elle s’arrête et **n’écrase jamais en silence** ; les données structurées demandent un outil de fusion enregistré, ou une personne. - **TTL et quota,** pour éviter les bombes de branches. - **Tentatives en parallèle.** Ouvrez N branches pour une même tâche, fusionnez la meilleure et recyclez les autres. ## Commencer petit - Des branches et worktrees Git, plus un **`main` protégé** sur Forgejo, Gitea ou GitHub. - Pour les gros répertoires, utilisez des instantanés et clones btrfs ou ZFS ; pour le stockage objet, des forks Tigris ou lakeFS. - Réussissez d’abord « les suppressions vont dans la corbeille » et « les instantanés appartiennent au propriétaire ». Ce sont les mesures les moins chères et celles qui évitent le plus de dégâts. ## Esquisse d’interface À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3. *nas cli* ```bash nas branch create cleo/release-notes --from main --ttl 48h nas checkpoint create before-refactor nas propose --into main --checks links,schema nas restore before-refactor nas trash list # recycle area, kept 7 days by default nas trash restore ``` ## Ce que demande la spécification - Un arbre protégé DOIT n’être modifiable que par une fusion ; aucun identifiant ne peut y écrire directement. - Une fusion DOIT produire un commit qui porte la provenance (exécution, habilitation, principal). - Aucune habilitation NE PEUT permettre de supprimer un instantané ou une sauvegarde. - Une suppression dans un arbre protégé DOIT être logique et récupérable dans la fenêtre configurée (7 jours par défaut). - Un conflit NE DOIT PAS être résolu en silence ; la fusion DOIT s’arrêter et le signaler. - Une branche DOIT avoir un TTL et un quota. ## Ce qui est emprunté, et ce qui est nouveau Tout ce qui précède est une pratique établie. **Ce qui est nouveau :** lier la branche à une **exécution et à une habilitation**, de sorte que la branche soit l’unité d’autorisation et la fusion l’unité de relecture. Les branches et les instantanés eux-mêmes ne sont pas nouveaux. - [Git worktree](https://git-scm.com/docs/git-worktree) - [lakeFS for agents](https://lakefs.io/agentic-ai/) - [Tigris Agent Kit](https://www.tigrisdata.com/docs/ai/agent-kit/) - [Cloudflare Artifacts](https://blog.cloudflare.com/artifacts-git-for-agents-beta/) ## Limites assumées - Une branche ne protège que les données dans le NAS. Elle **n’annule pas les effets de bord externes** : un e-mail déjà envoyé, une API déjà appelée. - Les gros fichiers binaires et les fichiers de base de données sont difficiles à fusionner. - La fatigue de relecture peut quand même survenir ; les chemins à faible risque peuvent donc être fusionnés automatiquement, et le taux d’approbation est mesuré. ## Questions ouvertes - Comment les outils de fusion sémantique sont-ils enregistrés et jugés fiables ? - Comment devrait fonctionner l’interaction autour des conflits binaires ? ## Questions ### En quoi est-ce différent d’une branche Git ? Sur le plan mécanique, ce n’est pas magique : on peut le construire sur Git. La différence est qu’il lie la branche à une exécution et à une habilitation, de sorte que « ne peut écrire que sur sa propre branche » devient une règle d’autorisation et que la fusion devient l’unique point de relecture. ### Une branche empêche-t-elle tous les accidents ? Non. Elle ne protège que les données dans le NAS : un e-mail déjà envoyé ou une API externe déjà appelée ne sont pas annulés par un retour arrière de branche. De telles actions doivent passer par `egress` dans l’habilitation et par une Human Gate. ### Chaque fusion exige-t-elle l’approbation d’une personne ? Non. Une fusion dont les vérifications passent, dont l’exécution n’a lu aucun contenu externe et qui n’implique ni suppression ni partage peut passer automatiquement. Une personne n’est nécessaire que dans quelques cas ; voir [Human Gate](https://agentnas.com/fr/concepts/human-gate/). ## Concepts liés - [Human Gate (validation humaine)](https://agentnas.com/fr/concepts/human-gate/): N’apparaît qu’avant les actions irréversibles, tournées vers l’extérieur ou qui élèvent les privilèges, et montre le vrai diff. - [Agent Home (répertoire personnel)](https://agentnas.com/fr/concepts/agent-home/): Un répertoire par rôle, avec historique. Des fichiers ordinaires que vous emportez. - [Flight Recorder (enregistreur de vol)](https://agentnas.com/fr/concepts/flight-recorder/): Un enregistrement par exécution, chaîné par hachage, qui inclut ce que l’exécution a lu. --- URL canonique : https://agentnas.com/fr/concepts/agent-branch/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Flight Recorder (enregistreur de vol) *Un enregistrement par exécution, chaîné par hachage, qui inclut ce que l’exécution a lu.* > **Un Flight Recorder** est un enregistrement en ajout seul, chaîné par hachage, tenu pour chaque exécution : ce que l’exécution a lu (le manifeste de lecture), ce qu’elle a écrit, ce qui a été autorisé ou refusé, et qui a approuvé quoi. Il se trouve à côté des données et répond à une seule question : « qu’est-ce qui a pu influencer ce changement ? » **AN-03** · Niveau de conformité : L1 Authority · Groupe : Travail ## Le problème Lors d’un post-mortem, les journaux sont dispersés ; il n’y a aucun lien entre une « lecture » et l’action qui l’a suivie ; et les journaux peuvent être modifiés par le même administrateur, voire par le même agent. Plus fondamentalement : quand une fusion ou un souvenir est soupçonné d’être contaminé, il n’y a aucun moyen de répondre à « qu’a lu cette exécution ? » ## Fonctionnement - **Deux sortes de contenu.** Les *événements* sont enregistrés un par un : commits, émission et révocation d’habilitations, demandes et décisions de validation, refus de politique, dérivations, oubli. Le *manifeste de lecture* est agrégé par exécution : quels chemins@commit, quelles plages et quels hachages de contenu ont été lus. Il n’enregistre pas chaque appel de lecture, et il n’enregistre jamais le contenu. - **Chaque commit porte des métadonnées de provenance :** `principal`, `on_behalf_of`, `run`, `lease`, `purpose` et une référence au manifeste de lecture. - **Une chaîne de hachage** (par jour), avec des signatures et un ancrage externe facultatifs (un second nœud, un bucket avec verrouillage d’objets). L’objectif est que « **la falsification soit détectable** », et non qu’elle soit impossible. - **Export :** spans OpenTelemetry GenAI, JSON Lines, ou vers un SIEM. - **Vie privée :** métadonnées seulement par défaut, pas de contenu ; la rétention des enregistrements est indépendante de la suppression du contenu ; les enregistrements eux-mêmes sont à accès contrôlé. - **`explain(commit)` :** renvoie l’exécution, l’habilitation, les décisions de validation, le manifeste de lecture et les entrées derrière ce commit. - **Enregistrer d’abord, agir ensuite :** une opération à conséquences doit d’abord écrire un enregistrement d’intention. ## Commencer petit - Une table SQLite en ajout seul plus un hachage quotidien. - Des trailers Git comme `Run:` et `Lease:` dans chaque message de commit. - Exporter des spans OpenTelemetry vers la pile d’observabilité que vous avez déjà. ## Esquisse d’interface À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3. *record.json* ```json { "seq": 18211, "time": "2026-11-12T09:14:22Z", "kind": "commit", "run": "run_91ab", "principal": "agt_cleo", "on_behalf_of": "usr_wei", "lease": "lse_7Qk3", "purpose": "Draft the Q4 release notes", "subject": { "path": "/shared/launch/notes.md", "commit": "91ce3a7" }, "read_manifest": "rm_5d2e", "decision": { "effect": "allow", "rule": "r-17" }, "taint": { "external": true, "sensitivity": "private" }, "prev_hash": "sha256:b3a0..." } ``` ## Ce que demande la spécification - Une opération à conséquences DOIT écrire un enregistrement d’intention avant de prendre effet ; si l’écriture échoue, l’opération DOIT échouer. - Chaque exécution DOIT avoir un manifeste de lecture consignant les chemins, commits et plages lus (pas le contenu). - Les enregistrements DOIVENT être chaînés par hachage et DOIVENT être vérifiables avec une commande publiée. - `explain(commit)` DOIT renvoyer l’exécution, l’habilitation, les décisions de validation et une référence au manifeste de lecture. - La rétention des enregistrements DOIT être indépendante de la suppression du contenu. ## Ce qui est emprunté, et ce qui est nouveau Tout ce qui précède, ce sont des briques établies. **Ce qui est nouveau, c’est le manifeste de lecture :** il fait de la « lecture » un ensemble d’entrées traçable, de sorte que « une fusion contaminée » et « une mémoire empoisonnée » peuvent être examinées après coup. - [OpenTelemetry GenAI conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/) - [Certificate Transparency](https://certificate.transparency.dev) - [Sigstore Rekor](https://docs.sigstore.dev/logging/overview/) - [Git trailers](https://git-scm.com/docs/git-interpret-trailers) ## Limites assumées - Sans ancrage externe, un administrateur root peut quand même détruire le journal. - Les enregistrements eux-mêmes contiennent des métadonnées sensibles et doivent être contrôlés. - La granularité du manifeste de lecture est un compromis entre coût de stockage et traçabilité. ## Questions ouvertes - Comment maîtriser le coût de stockage des manifestes de lecture à fort débit ? - Comment fusionner et vérifier les enregistrements de plusieurs nœuds ? ## Questions ### Enregistre-t-il le contenu que l’agent a lu ? Pas par défaut. Un enregistrement contient des chemins, des commits, des plages et des hachages de contenu : de quoi pointer vers les données d’origine sans copier de contenu sensible dans un journal. Le contenu reste dans le Store, protégé par des habilitations et des étiquettes. ### Que veut dire « à détection d’altération » ici ? Nous promettons seulement que **la falsification est détectable** : les enregistrements sont chaînés par hachage, donc en modifier un casse la vérification de la chaîne ; avec un ancrage externe (un second nœud ou un bucket avec verrouillage d’objets), cela tient aussi face à un administrateur root. Sans ancrage, un administrateur peut quand même détruire tout le journal. ### Pourquoi enregistrer les lectures ? Parce que le risque vient souvent de la lecture : une session qui a lu une page web peut ensuite écrire une note contaminée. Le manifeste de lecture permet de répondre après coup à « qu’est-ce qui a influencé ce changement ? » ## Concepts liés - [Capability Lease (habilitation de capacité)](https://agentnas.com/fr/concepts/capability-lease/): Une autorisation étroite pour une exécution, avec une expiration et des budgets. Les habilitations filles ne peuvent être que plus étroites. - [Trust Labels (étiquettes de confiance)](https://agentnas.com/fr/concepts/trust-labels/): Deux petites étiquettes plus la contamination de session appliquent la Rule of Two. - [Cascade Forget (oubli en cascade)](https://agentnas.com/fr/concepts/cascade-forget/): Supprimer les dérivés en suivant le lignage, traiter l’historique selon la classe de rétention, et signaler ce qui n’a pas pu être fait. --- URL canonique : https://agentnas.com/fr/concepts/flight-recorder/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Capability Lease (habilitation de capacité) *Une autorisation étroite pour une exécution, avec une expiration et des budgets. Les habilitations filles ne peuvent être que plus étroites.* > **Une Capability Lease** est une autorisation portant sur des données précises et des opérations précises, avec une expiration explicite et des budgets. Elle est délivrée à **une seule exécution** et c’est le seul moyen pour une exécution de toucher au NAS. Une habilitation fille ne peut qu’être plus étroite que sa mère. **AN-04** · Niveau de conformité : L1 Authority · Groupe : Autorité ## Le problème Le RBAC et les ACL supposent des utilisateurs stables avec des permissions larges et durables. Un agent a besoin de permissions taillées pour la tâche, qui s’arrêtent quand la tâche se termine. Pire, des identifiants de longue durée se trouvent souvent à portée de l’agent : lors de l’incident d’avril 2026, le jeton se trouvait dans un fichier sans rapport, créé pour gérer des domaines mais capable de tout faire. ## Fonctionnement - **Qui détient la clé.** Les identifiants de longue durée restent chez l’orchestrateur ou le propriétaire ; une exécution reçoit une habilitation, pas une clé. Le modèle ne voit jamais un identifiant de longue durée. - **Une habilitation est un jeton d’accès.** Ses `authorization_details` ([RFC 9396](https://www.rfc-editor.org/rfc/rfc9396)) décrivent les chemins, les actions et la branche ; elle est demandée par le propriétaire ou l’orchestrateur par [échange de jetons (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693), la revendication `act` enregistre la chaîne de délégation, et le NAS conserve un état pour la révocation et le comptage des budgets. - **Seulement restreindre.** Une habilitation fille doit être un sous-ensemble de sa mère, ce que le NAS vérifie au moment de l’émission. - **Budgets.** Octets lus et écrits, nombres de requêtes et, facultativement, octets sortants et plafond de dépense, comptés à la passerelle. Ils servent de **disjoncteur**, pas de facturation exacte. - **Enveloppe de politiques.** Le propriétaire fixe une plage à l’avance ; les habilitations à l’intérieur sont émises automatiquement et tout ce qui est en dehors passe par une [Human Gate](https://agentnas.com/fr/concepts/human-gate/). Un accès de longue durée s’exprime par une enveloppe, pas par une habilitation de longue durée. - **B et C sont déclarés explicitement.** Une habilitation indique la sensibilité la plus élevée qu’elle peut lire et si elle peut écrire dans des arbres protégés ou envoyer des données vers l’extérieur. Ce sont des entrées pour les [Trust Labels](https://agentnas.com/fr/concepts/trust-labels/). - **Révocation.** Un TTL court (4 heures par défaut, 24 au plus) plus une révocation immédiate, qui se propage aux habilitations filles. - **`purpose` est enregistré, pas imposé :** un texte libre ne peut pas être vérifié par une machine. ## Commencer petit - Écrivez une commande `nas lease create` : pour chaque rôle, émettez un jeton avec un préfixe de chemin, des actions et un TTL, remettez-le au sandbox dans une variable d’environnement, et faites imposer préfixe et actions par le NAS. - Cela suffit déjà à arrêter la première moitié de ce genre d’incident : le jeton ne peut rien faire en dehors de l’habilitation. - Les budgets, les chaînes de délégation et les enveloppes de politiques peuvent venir plus tard. ## Esquisse d’interface À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3. *lease.json* ```json { "lease_id": "lse_7Qk3", "run": "run_91ab", "principal": "agt_cleo", "on_behalf_of": "usr_wei", "parent": null, "purpose": "Draft the Q4 release notes", "paths": ["/shared/launch/**", "/agents/cleo/workspace/**"], "actions": ["read", "write", "propose"], "branch": "cleo/run_91ab", "sensitivity_max": "private", "egress": false, "requires_gate": ["merge", "delete", "share"], "budgets": { "bytes_read": 200000000, "bytes_written": 5000000, "requests": 5000 }, "expires_at": "2026-11-12T16:00:00Z" } ``` ## Ce que demande la spécification - Une habilitation DOIT avoir une expiration et NE DOIT PAS être renouvelée au-delà du TTL maximal ; un renouvellement exige une nouvelle émission. - Une habilitation fille DOIT être un sous-ensemble de sa mère, et le NAS DOIT le vérifier à l’émission. - La révocation d’une habilitation DOIT se propager à toutes ses habilitations filles. - Un accès de longue durée DOIT s’exprimer par une enveloppe de politiques et NE DOIT PAS devenir une habilitation de longue durée. - Une habilitation DOIT déclarer son plafond de sensibilité et si elle autorise la sortie de données et les écritures protégées. - Les identifiants de longue durée NE DOIVENT PAS être exposés à un modèle ni à une exécution. ## Ce qui est emprunté, et ce qui est nouveau Tout ce qui précède, ce sont des briques établies. **Ce qui est nouveau :** prendre la **forme d’une exécution et d’une tâche** comme unité et réunir la branche, les budgets et les propriétés de la Rule of Two dans une seule habilitation. Les jetons et les modèles de capacités ne sont pas nouveaux. - [OAuth Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693) - [OAuth Rich Authorization Requests (RFC 9396)](https://www.rfc-editor.org/rfc/rfc9396) - [Biscuit](https://github.com/biscuit-auth/biscuit) - [UCAN](https://ucan.xyz/specification/) - [IETF attenuating agent tokens draft](https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/) ## Limites assumées - Elle ne couvre que les opérations dans le NAS et ne peut pas régir ce qu’un agent fait ailleurs. - `purpose` ne peut pas être imposé, et les budgets sont approximatifs. - Une habilitation ne peut pas empêcher le mauvais usage **dans le cadre d’une autorité légitime** ; c’est le travail des branches et des validations. ## Questions ouvertes - Comment faire passer `purpose` d’un texte libre à une intention structurée qu’une machine peut vérifier ? - Comment comptabiliser les budgets en cas de fédération ? ## Questions ### En quoi une habilitation diffère-t-elle d’une clé d’API ? Une clé d’API est un secret partagé de longue durée, et son détenteur peut faire tout ce que le compte peut faire. Une habilitation est liée à une exécution, limite les chemins, les actions et la durée, et ne peut qu’être restreinte ; elle cesse de fonctionner à l’expiration et peut être révoquée à tout moment. ### Pourquoi ne pas simplement utiliser OAuth ? C’est OAuth : une habilitation est un jeton d’accès, demandé par échange de jetons (RFC 8693) et décrit avec des Rich Authorization Requests (RFC 9396). Agent NAS n’ajoute que ce qu’OAuth ne spécifie pas : l’exécution comme unité, et la réunion de la branche, des budgets et des propriétés de la Rule of Two dans une même autorisation. ### Que devient une exécution quand son habilitation expire ? Le montage passe en lecture seule puis est démonté ; les nouvelles requêtes sont refusées et enregistrées. La branche est conservée jusqu’à l’expiration de son propre TTL, de sorte que le travail terminé n’est pas perdu et peut encore être fusionné après relecture. ## Concepts liés - [Human Gate (validation humaine)](https://agentnas.com/fr/concepts/human-gate/): N’apparaît qu’avant les actions irréversibles, tournées vers l’extérieur ou qui élèvent les privilèges, et montre le vrai diff. - [Trust Labels (étiquettes de confiance)](https://agentnas.com/fr/concepts/trust-labels/): Deux petites étiquettes plus la contamination de session appliquent la Rule of Two. - [Flight Recorder (enregistreur de vol)](https://agentnas.com/fr/concepts/flight-recorder/): Un enregistrement par exécution, chaîné par hachage, qui inclut ce que l’exécution a lu. --- URL canonique : https://agentnas.com/fr/concepts/capability-lease/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Human Gate (validation humaine) *N’apparaît qu’avant les actions irréversibles, tournées vers l’extérieur ou qui élèvent les privilèges, et montre le vrai diff.* > **Une Human Gate** est un point de contrôle déclenché par la politique : avant qu’une action **irréversible, tournée vers l’extérieur ou élevant les privilèges** ne prenne effet, une personne (ou un approbateur désigné) approuve une action concrète, entièrement affichée. Elle est conçue pour être rare, précise et difficile à valider par réflexe. **AN-05** · Niveau de conformité : L1 Authority · Groupe : Autorité ## Le problème Le « humain dans la boucle » d’aujourd’hui est soit un flot interminable de demandes, soit rien du tout. Anthropic indique que les utilisateurs de Claude Code approuvent 93 % à 97 % des demandes d’autorisation ; dans son expérience contrôlée, les participants n’ont repéré que 13,6 % des commandes dangereuses introduites à dessein, et faisaient moins bien à mesure que les sessions s’allongeaient. C’est une recherche de fournisseur menée pour promouvoir le mode automatique, et elle mesure la détection de demandes introduites à dessein plutôt que des taux d’incidents en production, mais la tendance est claire. Les mêmes données contiennent un autre chiffre : les utilisateurs rejettent 39 % des plans mais seulement 3 % des demandes d’autorisation individuelles. Ce que les gens jugent sérieusement, ce sont les plans et les fusions, pas chaque appel d’outil. ## Fonctionnement - **Elle n’apparaît que dans peu d’endroits :** fusion dans un arbre protégé, suppression dans un arbre protégé, partage ou publication vers l’extérieur, sortie de données, élargissement d’une habilitation et abaissement d’une étiquette. Les écritures sur une branche n’exigent aucune approbation. - **La granularité est un plan ou une fusion.** Relire une PR, pas cinquante demandes. - **La Gate Card est produite par le NAS :** le vrai diff, un résumé du manifeste de lecture, l’habilitation et la contamination de session, jamais le récit de l’agent lui-même. Options : approuver, approuver en restreignant, refuser ; un délai dépassé vaut refus par défaut. - **Une approbation est liée à l’empreinte de l’action :** elle lie le hachage du diff et l’habilitation et ne peut pas être rejouée. - **Remise :** push, messagerie, e-mail ou CLI ; elle peut être déléguée ; les passkeys sont une authentification forte facultative. - **Escalade seulement.** Un classifieur de risque facultatif (y compris un LLM) peut seulement **escalader** une action vers une validation et jamais en **approuver** une. Un modèle ne peut que resserrer, jamais relâcher. - **La fatigue est mesurée :** taux d’approbation et délai d’approbation ; quand le taux d’approbation est anormalement élevé, cela suggère de regrouper les validations ou de resserrer la politique. ## Commencer petit - Un `main` protégé plus une revue de PR (n’importe quelle plateforme Git convient) et une notification push. - Ou une CLI : `nas gate approve `. - Faites d’abord afficher le « vrai diff » par la Gate Card ; ne vous précipitez pas vers des interfaces sophistiquées. ## Esquisse d’interface À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3. *gate-card.json* ```json { "gate_id": "gt_2Mx4", "run": "run_91ab", "action": { "op": "merge", "from": "cleo/run_91ab", "into": "main", "files_changed": 4, "diff_sha256": "7d2a..." }, "why": "Release notes are ready for review", "risk": { "session_taint": ["external"], "sources": ["web:example.com/changelog"], "destructive": false, "egress": false }, "options": ["approve", "approve_narrowed", "deny"], "default": "deny", "expires_at": "2026-11-12T12:00:00Z" } ``` ## Ce que demande la spécification - Une Gate Card DOIT montrer le vrai diff calculé par le NAS, pas la description qu’en donne l’agent. - Une approbation DOIT être liée à l’empreinte de l’action et à l’habilitation et NE DOIT PAS pouvoir être rejouée. - Le résultat par défaut d’un délai dépassé DOIT être le refus. - Un classifieur ou un LLM NE DOIT PAS accorder d’approbation ; il PEUT escalader une action vers une validation. - La fusion dans un arbre protégé, la suppression dans un arbre protégé, le partage externe, la sortie de données, l’élargissement d’une habilitation et l’abaissement d’une étiquette DOIVENT passer par une validation. - Le NAS DEVRAIT rapporter le taux d’approbation et le délai d’approbation. ## Ce qui est emprunté, et ce qui est nouveau Tout ce qui précède est une pratique établie. **Ce qui est nouveau :** ancrer l’approbation sur **la fusion au niveau de la couche de stockage** et faire produire le contenu par le NAS (pas par l’agent). L’approbation et les PR ne sont pas nouvelles en elles-mêmes. - [How we built Claude Code auto mode](https://www.anthropic.com/research/claude-code-auto-mode) - [Anthropic: approval data behind auto mode](https://claude.com/resources/articles/auto-mode-default-in-claude-code) - [CaMeL](https://arxiv.org/abs/2503.18813) - [WebAuthn](https://www.w3.org/TR/webauthn-3/) - [OpenID CIBA](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) ## Limites assumées - Une personne peut quand même approuver la mauvaise action ; la revue par lots provoque aussi de la fatigue. - Les canaux de notification peuvent être victimes d’hameçonnage. - Une approbation ne peut pas arrêter quelque chose **en dehors de ce qui a été approuvé** ; c’est le travail de l’habilitation. ## Questions ouvertes - Quelle est la meilleure interface pour une revue par lots et par niveaux ? - Comment mesurer et régler le seuil de fusion automatique ? ## Questions ### N’est-ce pas simplement une boîte de dialogue « confirmer » de plus ? Délibérément non. Une boîte de dialogue se déclenche à chaque appel d’outil et les gens finissent vite par cliquer sur « approuver ». Une validation n’apparaît qu’avant quelques actions irréversibles ou tournées vers l’extérieur, montre le vrai diff calculé par le NAS, et l’approbation lie le hachage du diff : si le diff change, l’approbation est nulle. ### Un LLM peut-il décider de laisser passer une action ? Il peut suggérer qu’« une personne devrait regarder cette étape » ; il ne peut pas approuver. La décision de laisser passer doit être une règle déterministe ou l’approbation d’une personne. Ainsi, la sécurité ne dépend du jugement d’aucun modèle. ### Que se passe-t-il à l’expiration du délai ? Refus par défaut. L’exécution reçoit un refus clair et peut emprunter une autre voie, ou laisser la proposition sur sa branche pour qu’une personne s’en occupe. ## Concepts liés - [Capability Lease (habilitation de capacité)](https://agentnas.com/fr/concepts/capability-lease/): Une autorisation étroite pour une exécution, avec une expiration et des budgets. Les habilitations filles ne peuvent être que plus étroites. - [Trust Labels (étiquettes de confiance)](https://agentnas.com/fr/concepts/trust-labels/): Deux petites étiquettes plus la contamination de session appliquent la Rule of Two. - [Agent Branch (branche d’agent)](https://agentnas.com/fr/concepts/agent-branch/): Chaque exécution travaille sur une branche en copy-on-write. Seule une fusion relue atteint la ligne principale. --- URL canonique : https://agentnas.com/fr/concepts/human-gate/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Trust Labels (étiquettes de confiance) *Deux petites étiquettes plus la contamination de session appliquent la Rule of Two.* > **Les Trust Labels** sont deux très petits jeux d’étiquettes attachés aux données, **l’origine** (`owner`, `agent`, `external`) et **la sensibilité** (`public`, `private`, `secret`), plus **la contamination de session**. Le NAS applique la Rule of Two comme un invariant de session : une session ne peut pas réunir à la fois [A] a lu du contenu externe, [B] touche à des données sensibles et [C] modifie un état protégé ou communique vers l’extérieur. Compléter la troisième exige une [Human Gate](https://agentnas.com/fr/concepts/human-gate/). **AN-06** · Niveau de conformité : L3 Guard · Groupe : Autorité ## Le problème L’injection de prompt fonctionne parce qu’un modèle ne distingue pas les « instructions » des « données ». Les défenses au niveau du modèle (classifieurs, durcissement des prompts) fuient, et les attaquants peuvent s’adapter. Fin octobre 2025, Meta a proposé l’[Agents Rule of Two](https://ai.meta.com/blog/practical-ai-agent-security/) : tant que l’injection n’est pas résolue de façon fiable, une session devrait avoir au plus deux des trois propriétés. L’approche la plus fiable consiste à borner les conséquences **en dehors** du modèle. Le stockage est précisément l’endroit où passent toutes les lectures et écritures, et c’est donc un endroit naturel pour transformer cette règle en invariant testable. ## Fonctionnement - **Étiquettes.** Trois origines, trois sensibilités et un indicateur `reviewed` (posé par l’approbation d’une validation). Les points d’import (pages web, e-mails, téléversements) valent `external` par défaut ; quand un détecteur de secrets trouve des identifiants, il les étiquette automatiquement `secret`. - **Contamination de session.** Le résumé de tout ce qu’une exécution a lu (d’après le manifeste de lecture) ; au sein d’une session elle ne fait que croître, et une nouvelle session repart propre. - **L’invariant.** A = la session a lu `external` ; B = l’habilitation peut lire `private` ou plus (seuil configurable) ; C = l’habilitation peut proposer une fusion dans un arbre protégé, partager, supprimer ou envoyer des données vers l’extérieur. Quand les trois sont réunis dans une même session, l’appel qui déclenche C est refusé ou envoyé à une validation. - **En pratique :** sous une habilitation qui a à la fois B et C, dès qu’une session a lu du contenu externe, toute action de type C ultérieure exige une personne. Pour éviter cette friction, faites le travail de « lecture de contenu externe » dans une session distincte sans B, et ne transmettez les résultats que par une passation structurée. - **Propagation.** Les dérivations faites par le NAS lui-même (index, résumés) héritent de façon déterministe de l’union des étiquettes de leurs entrées ; les fichiers qu’une exécution écrit héritent de la contamination de session de l’exécution (le choix prudent). - **Déclassification.** Uniquement par une Human Gate, ou par une **passation structurée :** la sortie de la session contaminée est restreinte à des champs validés par un schéma JSON (énumérations, identifiants, chaînes bornées), et c’est seulement après validation qu’une session privilégiée peut la lire. On ne peut faire confiance qu’à ce qui peut être validé de façon déterministe. - **L’application se fait à la passerelle et au montage** (qui connaissent l’habilitation et la session), pas à l’intérieur du modèle. ## Commencer petit - Ne faites que deux choses : étiquetez `external` les fichiers du répertoire d’import, et par défaut n’accordez à une exécution qui a lu `external` ni sortie de données ni fusion protégée sans validation. - Écrivez la politique sous forme de règles déterministes en Cedar ou Rego, et donnez des raisons lisibles en cas de refus. - Faites tourner en mode « journal seulement » pendant une semaine pour voir ce qu’il bloquerait par erreur, puis activez l’application. ## Esquisse d’interface À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3. *policy.yaml* ```yaml # Deterministic policy (Cedar- or Rego-style rules can express the same thing) session_invariant: rule_of_two properties: A: session.read_origin includes "external" B: lease.sensitivity_max >= "private" C: lease allows propose_protected | share | delete | egress on_would_complete_ABC: gate # never "allow" rules: - id: r-merge-1 when: session.A and op == "merge" and target.protected then: gate - id: r-secret-1 when: session.read_sensitivity == "secret" and op == "egress" then: deny ``` ## Ce que demande la spécification - Chaque point d’import DOIT attribuer une étiquette par défaut ; le contenu externe DOIT être étiqueté `external`. - Au sein d’une session, la contamination DOIT uniquement croître. - L’évaluation des politiques DOIT être déterministe et NE DOIT PAS appeler un LLM. - Un appel qui permettrait à une session de réunir A+B+C DOIT être refusé ou envoyé à une validation. - La déclassification DOIT passer par une validation ou par une passation structurée validée par un schéma. - Les données dérivées DOIVENT hériter de l’union des étiquettes de leurs entrées. ## Ce qui est emprunté, et ce qui est nouveau Tout ce qui précède relève de réflexions établies. **Ce qui est nouveau :** mettre en œuvre la contamination de session à la **frontière du stockage** avec le manifeste de lecture, et appliquer les étiquettes aux écritures de mémoire et aux données dérivées. Nous gardons délibérément le treillis d’étiquettes à 3×3, car les treillis fins mènent en pratique à une explosion d’étiquettes. OpenClaw fait déjà des étiquettes d’origine et de l’isolation à l’intérieur d’un seul runtime ; notre seule différence est de placer cela dans un stockage partagé. - [Agents Rule of Two (Meta)](https://ai.meta.com/blog/practical-ai-agent-security/) - [The lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) - [CaMeL](https://arxiv.org/abs/2503.18813) - [Fides](https://arxiv.org/abs/2505.23643) - [Design Patterns for Securing LLM Agents against Prompt Injections](https://arxiv.org/abs/2506.08837) - [OpenClaw memory architecture](https://docs.openclaw.ai/concepts/memory-architecture) ## Limites assumées - Ce n’est **pas** une défense contre l’injection de prompt ; il en limite les conséquences. - Le NAS ne voit pas les outils extérieurs (un navigateur, la messagerie) ; il a donc besoin de la coopération du runtime. - La contamination est prudente et apporte de la friction et des faux positifs ; un texte libre hors des schémas structurés peut encore porter les mots d’un attaquant. - Les canaux cachés ne peuvent pas être éliminés. ## Questions ouvertes - La granularité d’une étiquette doit-elle être le fichier ou le paragraphe ? - Comment gouverner le vocabulaire des étiquettes entre locataires ? - Comment réduire les faux positifs ? ## Questions ### La Rule of Two arrête-t-elle l’injection de prompt ? Elle n’empêche pas l’injection de se produire. Elle rend une session injectée **incapable de réunir les trois** propriétés « a lu du contenu non fiable, touche à des données sensibles, peut modifier un état protégé ou envoyer des données vers l’extérieur », ce qui borne les conséquences. Meta souligne elle-même qu’il s’agit d’une heuristique de réduction du risque qui ne remplace pas le moindre privilège. ### Pourquoi seulement trois origines et trois sensibilités ? Parce que les treillis d’étiquettes fins ont tendance à gonfler et à être désactivés en pratique. 3×3 suffit pour dire « qui l’a écrit, avec quelle sensibilité » et rend la raison d’un refus facile à comprendre. Des partitions plus fines peuvent se faire avec les chemins et les habilitations. ### La contamination de session laissera-t-elle l’agent sans rien pouvoir faire ? Elle ne restreint que trois sortes d’actions : modifier un arbre protégé, partager ou supprimer, et envoyer des données vers l’extérieur. Les lectures et écritures dans une branche ne sont pas touchées. Pour éviter la friction, placez le travail de lecture de contenu externe dans une session sans données sensibles et ne renvoyez que des résultats validés par un schéma. ## Concepts liés - [Human Gate (validation humaine)](https://agentnas.com/fr/concepts/human-gate/): N’apparaît qu’avant les actions irréversibles, tournées vers l’extérieur ou qui élèvent les privilèges, et montre le vrai diff. - [Agent Memory (mémoire de l’agent)](https://agentnas.com/fr/concepts/agent-memory/): Des notes que vous pouvez lire et modifier font la vérité. Les index sont un cache que vous pouvez jeter. - [Capability Lease (habilitation de capacité)](https://agentnas.com/fr/concepts/capability-lease/): Une autorisation étroite pour une exécution, avec une expiration et des budgets. Les habilitations filles ne peuvent être que plus étroites. --- URL canonique : https://agentnas.com/fr/concepts/trust-labels/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Agent Memory (mémoire de l’agent) *Des notes que vous pouvez lire et modifier font la vérité. Les index sont un cache que vous pouvez jeter.* > **Agent Memory** = **des notes que vous pouvez lire et modifier** + **des index que vous pouvez jeter à tout moment**. Chaque note cite ses sources ; les index (texte intégral, vectoriel, graphe, plan) ne sont que des dérivés des notes ; et les tâches de maintenance en arrière-plan ne font que **proposer** des modifications et ne réécrivent jamais le journal brut. **AN-07** · Niveau de conformité : L2 Memory · Groupe : Connaissance ## Le problème Les frameworks de mémoire mettent la mémoire dans des bases de données opaques : on ne peut ni l’inspecter, ni la comparer, ni la migrer, ni la corriger, la supprimer de façon fiable est difficile, et l’index et le modèle d’embedding sont verrouillés. Et la mémoire est elle-même une surface d’attaque : dans une [étude de 2026](https://arxiv.org/abs/2606.04329), l’empoisonnement de la mémoire persistante a atteint un taux de réussite moyen de l’attaque de 50,46 % sur deux agents, et [une autre étude](https://arxiv.org/abs/2607.05189) a utilisé un seul e-mail soigneusement conçu pour réussir contre des backends de mémoire à la fois en système de fichiers et vectoriels. Par ailleurs, « quelle architecture de mémoire est la meilleure » est loin d’être tranché : les benchmarks se contredisent. Une conception qui ne parie sur aucun algorithme de récupération précis est celle qui peut survivre à trois ans de changements. ## Fonctionnement - **Les notes sont la vérité.** Du Markdown avec frontmatter YAML : `kind` (épisodique, sémantique, procédural, préférence), `subject`, `sources`, `confidence`, `valid_from`, `valid_to`, `supersedes`, `origin`, `reviewed`. - **Mettre à jour, ne pas écraser.** Un nouveau fait `supersedes` l’ancien ; le temps de validité et le temps d’enregistrement sont séparés, parce que les faits changent et que les benchmarks courants testent à peine cela. - **Les index sont un cache.** BM25 (par exemple SQLite FTS5), vecteurs (plusieurs peuvent coexister) et graphe facultatif ; chaque dérivé porte sa **recette** et ses **entrées**. Changer de modèle d’embedding est un recalcul en arrière-plan, et l’ancien index est conservé jusqu’à ce que le nouveau réussisse les tests de rappel de référence. - **Deux sortes de dérivation.** Les dérivations déterministes (découpage, BM25, embeddings d’un modèle fixe) sont reproductibles ; les dérivations génératives (résumés par LLM, faits extraits) ne peuvent qu’être « régénérées et comparées » : elles sont donc marquées `generated: true` et ne servent jamais d’unique copie. - **Chemin d’écriture.** `nas_remember` écrit une note (avec ses sources) sur la branche courante, et la contamination est héritée. Une note issue d’une session de contamination `external` va en **quarantaine**, marquée non relue : elle peut être rappelée mais **n’est pas chargée automatiquement** et n’entre pas dans `MEMORY.md`. - **Chemin de lecture.** `nas_recall` = recherche, candidats, une vue avec budget plus des pointeurs de preuve, et il montre la source et l’état de relecture de chaque note. - **Tâches de maintenance** (la nuit ou au repos) : dédupliquer, consolider des épisodes en faits sémantiques, signaler les contradictions, retirer les faits périmés, reconstruire les index. Les tâches produisent des propositions sur une branche pour qu’une personne ou un agent les relise ; elles **ne suppriment jamais le journal brut** ; le « taux de regret » (la part des propositions qui sont annulées) est mesuré. - **Tests de rappel de référence.** Pour chaque Home, un ensemble de paires « question, note attendue » qui s’exécutent automatiquement quand le modèle ou l’indexeur change. ## Commencer petit - `memory/notes/*.md` avec frontmatter, et SQLite FTS5 pour la recherche. - Faites passer dix questions de référence en CI. - Les index vectoriels et les tâches de maintenance peuvent venir plus tard ; réussissez d’abord la « provenance » et « seules les notes relues se chargent automatiquement ». ## Esquisse d’interface À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3. *memory/notes/customer-acme.md* ```markdown --- id: mem_4kq2 kind: semantic subject: customer/acme valid_from: 2026-10-02 valid_to: null confidence: 0.8 origin: agent reviewed: true sources: - nas://home-box/agents/cleo/journal/2026-10-02.md@9f2c1de#L12-L18 supersedes: [mem_1xa9] --- Acme renewed for 24 months; the champion moved from Dana to Luis. ``` ## Ce que demande la spécification - Les notes DOIVENT être lisibles sans la couche Memory (ce sont des fichiers ordinaires dans le Store). - Chaque dérivé DOIT porter sa recette et ses entrées ; un index DOIT être jetable et reconstructible. - Les notes écrites par une session contaminée NE DOIVENT PAS être chargées automatiquement avant d’avoir été relues. - Un nouveau fait DOIT remplacer un ancien avec `supersedes` au lieu de l’écraser. - Les tâches de maintenance DOIVENT travailler sur une branche et seulement proposer ; elles NE DOIVENT PAS supprimer le journal brut. - Chaque Home DEVRAIT porter des tests de rappel de référence et les exécuter chaque fois que le modèle ou l’indexeur change. ## Ce qui est emprunté, et ce qui est nouveau Tout ce qui précède relève de réflexions établies, et l’architecture de mémoire d’OpenClaw fait déjà des étiquettes de provenance, une quarantaine par niveau et la propagation de la contamination pendant la consolidation. **Ce qui est nouveau :** OpenClaw le fait **à l’intérieur d’un seul runtime** ; nous proposons de le faire **dans un stockage partagé** pour que tout runtime en profite, et de rétrograder l’index en cache jetable pour que l’algorithme de récupération puisse changer sans perdre la mémoire. - [Letta Context Repositories](https://www.letta.com/blog/context-repositories/) - [Letta: is a filesystem all you need?](https://www.letta.com/blog/benchmarking-ai-agent-memory/) - [OpenClaw memory architecture](https://docs.openclaw.ai/concepts/memory-architecture) - [Long-term memory security survey](https://arxiv.org/abs/2604.16548) - [Graphiti](https://github.com/getzep/graphiti) - [MemGPT](https://arxiv.org/abs/2310.08560) ## Limites assumées - Les dérivés génératifs ne peuvent jamais être reproduits à l’identique. - Une tâche de maintenance peut « durcir » une erreur en fait, c’est pourquoi elle ne fait que proposer et ne modifie jamais directement. - Quelle architecture de mémoire est la meilleure reste une question non tranchée. ## Questions ouvertes - Quand un agent doit-il écrire lui-même la mémoire, et quand une tâche de maintenance ? - Quel est le critère de non-régression d’une version de modèle à l’autre ? ## Questions ### Pourquoi des fichiers plutôt qu’une base de données vectorielle ? Les fichiers sont la vérité qu’on peut lire, modifier, comparer et emporter ; un index vectoriel est un cache dérivé qui peut coexister en plusieurs versions et être reconstruit à tout moment. Le benchmark de Letta a montré qu’un agent avec seulement `grep` et des outils de fichiers est compétitif, mais les benchmarks se contredisent : la conception ne parie donc pas sur un algorithme de récupération. ### Comment prévient-on l’empoisonnement de la mémoire ? On ne peut pas garantir que rien de mauvais ne sera jamais écrit, mais on peut borner les conséquences : le contenu venu de l’extérieur porte l’étiquette `external` ; les notes écrites par une session contaminée vont en quarantaine et ne sont pas chargées automatiquement ; les fusions sont relues ; et quand quelque chose tourne mal, on peut suivre la chaîne de provenance jusqu’aux notes touchées et revenir en arrière. ### Dois-je migrer la mémoire quand je change de modèle d’embedding ? Non. Les notes ne changent pas ; seuls les index sont recalculés en arrière-plan avec la nouvelle recette, et l’ancien index est conservé jusqu’à ce que le nouveau réussisse les tests de rappel de référence. ## Concepts liés - [Budgeted Reads (lectures avec budget)](https://agentnas.com/fr/concepts/budgeted-reads/): Lire un fichier sous forme de plan, de section, de plage de lignes ou en entier, avec dégradation pour tenir dans le budget. - [Cascade Forget (oubli en cascade)](https://agentnas.com/fr/concepts/cascade-forget/): Supprimer les dérivés en suivant le lignage, traiter l’historique selon la classe de rétention, et signaler ce qui n’a pas pu être fait. - [Trust Labels (étiquettes de confiance)](https://agentnas.com/fr/concepts/trust-labels/): Deux petites étiquettes plus la contamination de session appliquent la Rule of Two. --- URL canonique : https://agentnas.com/fr/concepts/agent-memory/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Budgeted Reads (lectures avec budget) *Lire un fichier sous forme de plan, de section, de plage de lignes ou en entier, avec dégradation pour tenir dans le budget.* > **Budgeted Reads** désigne des lectures mesurées dans un budget de tokens : un même fichier peut être lu à différents niveaux de détail, du plan et de la section à la plage de lignes et au texte intégral. L’agent demande « la meilleure vue qui tient dans N tokens » et reçoit en retour des pointeurs de preuve vers la source exacte. **AN-08** · Niveau de conformité : L2 Memory · Groupe : Connaissance ## Le problème Les agents brûlent leur contexte sur des fichiers entiers et des lectures répétées, et le découpage naïf de RAG perd la structure. Les modèles sont déjà bons avec `grep`, `tail` et la lecture par lignes : Cursor écrit dans des fichiers les sorties d’outils trop longues pour que les agents les lisent à la demande, et dans les exécutions qui ont appelé un outil MCP, la [découverte dynamique](https://cursor.com/blog/dynamic-context-discovery) des descriptions d’outils a réduit le total de tokens de 46,9 %. Le problème n’est donc pas de « construire un autre système de récupération », mais de donner à la lecture au-dessus des fichiers un contrat **avec budget et vérifiable**. ## Fonctionnement - **Les fichiers d’abord.** Les lectures standard (y compris par plages de lignes) sont toujours disponibles ; Budgeted Reads est une extension facultative par-dessus et ne remplace pas le système de fichiers. - **Plans déterministes (gratuits) :** l’arbre des titres de Markdown, les symboles de code (tree-sitter), les clés de JSON et YAML, les en-têtes et le nombre de lignes de CSV. Aucun LLM n’est nécessaire. - **Budget et dégradation.** Une requête porte `budget_tokens` ; si cela ne tient pas, elle se dégrade vers une vue plus grossière **au lieu de tronquer en silence** ; la réponse indique la vue réelle, le nombre de tokens et si elle est `generated`. - **La recherche renvoie des extraits et des pointeurs,** pas des fichiers entiers. - **Pointeurs de preuve :** `nas:////@#L12-L18`, stables et vérifiables par rapport à un commit ; `dereference` renvoie le contenu exact. - **Ce qui a changé depuis la dernière fois :** renvoie le diff entre deux commits au lieu du fichier entier. - **Une couche facultative de résumés par LLM :** en tant que cache, marquée `generated: true` et avec un marqueur de péremption. ## Commencer petit - N’ajoutez rien d’autre que `nas_read` : laissez l’agent lire à l’ancienne, avec `rg` et `sed -n`. - Ajoutez ensuite un petit outil de plan pour Markdown et le code. - Commencez les pointeurs de preuve sous la forme « chemin@commit#ligne » ; aucun nouveau service n’est nécessaire. ## Esquisse d’interface À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3. *POST /v1/files/read* ```http POST /v1/files/read { "path": "/agents/cleo/memory/notes/customer-acme.md", "view": "outline", "budget_tokens": 400 } 200 OK { "view": "outline", "tokens": 212, "generated": false, "truncated": false, "content": "# Acme\n## Renewal (L12-L18)\n## Contacts (L19-L31)\n## Open issues (L32-L40)", "evidence": [ { "pointer": "nas://home-box/agents/cleo/memory/notes/customer-acme.md@9f2c1de#L1-L40" } ] } ``` ## Ce que demande la spécification - Une réponse DOIT indiquer la vue réellement renvoyée et son nombre de tokens ; les vues génératives DOIVENT être marquées. - Quand le budget est trop petit, le NAS DOIT se dégrader vers une vue plus grossière et NE DOIT PAS tronquer en silence. - Les lectures de fichiers standard (y compris par plages) DOIVENT rester disponibles. - Les pointeurs de preuve DOIVENT être vérifiables par rapport à un commit. - Par défaut, la recherche DOIT renvoyer des extraits et des pointeurs plutôt que des fichiers entiers. ## Ce qui est emprunté, et ce qui est nouveau La divulgation progressive et grep ne sont pas nouveaux en soi. **Ce qui est nouveau :** faire du budget et des pointeurs de preuve un **contrat de lecture au niveau du stockage**, de sorte que les réponses puissent être vérifiées : on peut remonter d’une phrase aux lignes du commit dont elle provient. - [Cursor: dynamic context discovery](https://cursor.com/blog/dynamic-context-discovery) - [Agent Skills (progressive disclosure)](https://agentskills.io/specification) - [Letta Context Repositories](https://www.letta.com/blog/context-repositories/) - [RAPTOR](https://arxiv.org/abs/2401.18059) ## Limites assumées - Les tokenizers diffèrent d’un modèle à l’autre ; les comptes de tokens sont donc des estimations. - Cela ne fonctionne que si les clients l’adoptent. - Les résumés se périment et peuvent être faux ; ils ne sont donc qu’un cache et toujours marqués. ## Questions ouvertes - Comment traiter l’erreur de budget entre les tokenizers de différents modèles ? - Comment évaluer la qualité des résumés ? ## Questions ### En quoi est-ce différent de RAG ? RAG renvoie les extraits les plus proches d’une question. Budgeted Reads laisse un lecteur choisir le niveau de détail pour un objet qu’il connaît déjà, se dégrade honnêtement quand le budget est court et donne des pointeurs vérifiables. Les deux se combinent : les résultats de recherche peuvent aussi revenir sous forme de vues avec budget. ### Dois-je l’utiliser pour lire des fichiers ? Non. Les montages et Git donnent toujours des fichiers ordinaires ; Budgeted Reads est une lecture facultative pour les agents attentifs aux tokens. ### Un pointeur de preuve peut-il empêcher les « citations inventées » ? Il rend les citations vérifiables : un pointeur désigne des lignes précises d’un commit et son hachage de contenu peut être vérifié. Il n’empêche pas un modèle d’inventer, mais il transforme « le passage qu’il cite existe-t-il vraiment ? » en contrôle automatique. ## Concepts liés - [Agent Memory (mémoire de l’agent)](https://agentnas.com/fr/concepts/agent-memory/): Des notes que vous pouvez lire et modifier font la vérité. Les index sont un cache que vous pouvez jeter. - [Agent Home (répertoire personnel)](https://agentnas.com/fr/concepts/agent-home/): Un répertoire par rôle, avec historique. Des fichiers ordinaires que vous emportez. - [Flight Recorder (enregistreur de vol)](https://agentnas.com/fr/concepts/flight-recorder/): Un enregistrement par exécution, chaîné par hachage, qui inclut ce que l’exécution a lu. --- URL canonique : https://agentnas.com/fr/concepts/budgeted-reads/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0 --- # Cascade Forget (oubli en cascade) *Supprimer les dérivés en suivant le lignage, traiter l’historique selon la classe de rétention, et signaler ce qui n’a pas pu être fait.* > **Cascade Forget** est une suppression qui suit le lignage : quand une source est supprimée, ou que quelqu’un demande à être oublié, le NAS retrouve tout ce qui en dérive, y compris résumés, embeddings, notes qui la citent, caches et liens de partage, le supprime ou le re-dérive sans cette source, et délivre un **rapport** : ce qui a été fait, et ce qui n’a pas pu l’être. **AN-09** · Niveau de conformité : L3 Guard · Groupe : Connaissance ## Le problème Supprimer un fichier ne supprime ni ses embeddings, ni ses résumés, ni les faits que la mémoire en a déduits ; les instantanés et les sauvegardes subsistent ; et le contenu reste dans l’historique des versions. « Récupérable » et « oubliable » sont les deux bouts d’un même axe, et la plupart des systèmes ne confient pas ce choix à une personne. Si l’on ne pense à l’oubli qu’après l’écriture, c’est généralement trop tard. ## Fonctionnement - **Lignage.** Chaque dérivé enregistre ses entrées ; un index inverse répond à « tout ce qui dépend de X » ; le champ `sources` d’une note est aussi du lignage. - **Classe de rétention, décidée à l’écriture** (car on ne peut pas réécrire l’historique ensuite) : `scratch` (TTL court, hors sauvegardes, nettoyable à la fin de l’exécution), `normal` (versionné, récupérable) et `sensitive` (son propre domaine de clés, qui peut être détruit en détruisant la clé). - **La tension entre reprise et oubli.** Récupérable dans la fenêtre de suppression logique ; supprimé définitivement seulement après ; une demande d’oubli peut sauter la fenêtre. - **Processus.** Une demande (émise par une personne ou un opérateur ; un agent peut seulement demander, pas exécuter), parcours du lignage, suppression des dérivés et re-dérivation des faits d’origine mixte, réécriture de l’historique des chemins concernés et nettoyage des instantanés pour la classe `normal`, destruction des clés pour la classe `sensitive`, et enfin le rapport. - **Le rapport :** le nombre de fichiers supprimés, de dérivés retirés, si l’historique a été réécrit, les clés détruites, les instantanés pas encore expirés, et une **liste explicite de ce qu’il ne couvre pas :** copies hors du NAS, journaux du fournisseur de modèle et poids du modèle. - Il passe toujours par une [Human Gate](https://agentnas.com/fr/concepts/human-gate/) (ou une politique d’autorisation préalable) ; une **conservation juridique (legal hold)** bloque l’oubli et est enregistrée. ## Commencer petit - Commencez par les classes de rétention et la suppression logique, et enregistrez les entrées de chaque dérivé. - Atteignez d’abord « quand un fichier source est supprimé, lister et supprimer tous ses dérivés ». - Gardez l’effacement cryptographique pour la classe `sensitive` ; il n’est pas nécessaire de le faire partout au début. ## Esquisse d’interface À titre d’illustration seulement. Les noms de champs peuvent changer avant la spécification v0.3. *forget-report.json* ```json { "forget_id": "fgt_3b7c", "selector": { "paths": ["/shared/crm/acme/**"], "subject": "customer/acme" }, "retention_class": "sensitive", "report": { "files_removed": 142, "derived_removed": { "embeddings": 3621, "summaries": 210, "notes_rewritten": 6 }, "history": "rewritten (3 commits)", "keys_destroyed": ["key_acme"], "snapshots_pending": ["nightly-2026-11-10 (expires 2026-11-17)"], "not_covered": ["copies outside the NAS", "model provider logs", "model weights"] }, "state": "pending_expiry" } ``` ## Ce que demande la spécification - L’oubli DOIT se propager en suivant le lignage, de la source à chaque dérivé. - La classe de rétention DOIT être attribuée à l’écriture (`normal` par défaut). - Un rapport d’oubli DOIT énumérer ce qu’il ne couvre pas : copies hors du NAS, journaux du fournisseur et poids du modèle. - Une conservation juridique DOIT bloquer l’oubli et DOIT être enregistrée. - Un agent PEUT demander l’oubli mais NE DOIT PAS l’exécuter. - Un rapport NE DOIT PAS prétendre qu’un modèle a « oublié » quoi que ce soit. ## Ce qui est emprunté, et ce qui est nouveau Tout ce qui précède est établi. **Ce qui est nouveau :** traiter la **classe de rétention** comme une propriété explicite du stockage, et admettre que « récupérable » et « oubliable » sont un compromis sur un même axe. - [OpenLineage](https://openlineage.io) - [GDPR Article 17](https://gdpr-info.eu/art-17-gdpr/) - [Long-term memory security survey (forget and rollback)](https://arxiv.org/abs/2604.16548) ## Limites assumées - Les sauvegardes, les copies hors du NAS et les journaux des fournisseurs de modèles sont hors du périmètre. - Pour les faits déduits de plusieurs sources, le « périmètre touché » est difficile à définir. - Réécrire l’historique est coûteux et comporte des risques. ## Questions ouvertes - Comment définir le périmètre touché par un fait d’origine mixte ? - Quel doit être le processus quand une conservation juridique entre en conflit avec une demande d’oubli ? ## Questions ### Peut-il faire oublier un modèle ? Non, et il ne prétendra pas le faire. Ce qu’il peut faire, c’est supprimer des fichiers et des dérivés dans le NAS et, pour la classe `sensitive`, l’historique et les clés ; les journaux des fournisseurs de modèles et les poids des modèles sont hors du périmètre, et le rapport le dit explicitement. ### Pourquoi choisir une classe de rétention à l’écriture ? Parce que l’historique est difficile à réécrire ensuite : ce qui est déjà entré dans les sauvegardes et l’historique ne peut qu’être réécrit ou attendre d’expirer. Décider à l’écriture si une donnée est `scratch`, `normal` ou `sensitive` est la condition préalable pour pouvoir supprimer proprement plus tard. ### Un agent peut-il demander tout seul d’oublier quelque chose ? Il peut émettre une demande mais pas l’exécuter. L’oubli est irréversible et doit passer par une personne ou une politique d’autorisation préalable, et une conservation juridique peut le bloquer. ## Concepts liés - [Agent Memory (mémoire de l’agent)](https://agentnas.com/fr/concepts/agent-memory/): Des notes que vous pouvez lire et modifier font la vérité. Les index sont un cache que vous pouvez jeter. - [Flight Recorder (enregistreur de vol)](https://agentnas.com/fr/concepts/flight-recorder/): Un enregistrement par exécution, chaîné par hachage, qui inclut ce que l’exécution a lu. - [Agent Branch (branche d’agent)](https://agentnas.com/fr/concepts/agent-branch/): Chaque exécution travaille sur une branche en copy-on-write. Seule une fusion relue atteint la ligne principale. --- URL canonique : https://agentnas.com/fr/concepts/cascade-forget/ Mis à jour le: 2026-11-11 · Brouillon de spécification v0.2 · CC BY 4.0