Sommaire7
L’essentiel
En trente secondes- EnjeuDes agents qui partagent une mémoire ne doivent pas lire le périmètre des autres ; une consigne dans le prompt ne suffit pas.
- MécanismeL’application vérifie le périmètre de chaque acteur avant toute requête Cypher, et la base Memgraph applique des rôles distincts dès l’initialisation.
- PreuveLe code public de la branche session-ux : règles d’accès, tests unitaires et tests de bout en bout contre une vraie base Memgraph.
- ImpactUne connaissance partagée qui ne fuit pas d’un périmètre à l’autre : la condition de départ pour des agents qui se souviennent.
- LimitesLe cloisonnement est fait par agent ; les périmètres par client et les tests offensifs restent à réaliser.
- Client
- MC Studio, recherche et développement
- Mon rôle
- Concepteur et unique développeur de la fonctionnalité
- Cadre
- Projet interne
- Équipe
- Seul · 1 personne
- Technologies
TypeScript
Docker- Memgraph
- Cypher
- Vitest
Le point de départ
Dès que plusieurs agents travaillent ensemble, ils ont besoin de mémoire : ce qui a été décidé, ce qui a été appris, ce qui reste à faire. Une mémoire commune pose aussitôt une autre question. Si un agent travaille pour une personne, une équipe ou un client, il ne doit pas pouvoir lire ce que les autres ont confié aux leurs. Demander au modèle de « ne pas regarder » ne suffit pas.
Ce que j’ai construit
Sur un fork d’OpenClaw, un projet open source d’agents1, j’ai ajouté une mémoire en graphe hébergée sur Memgraph, lancé en conteneur. Chaque acteur reçoit un périmètre : un agent lit et écrit dans le sien, l’opérateur dispose d’un périmètre d’administration. Avant chaque requête, l’application vérifie que le périmètre demandé est bien celui de l’acteur, et refuse sinon.
OpenClaw est un projet open source…
OpenClaw est un projet open source tiers. Seule la fonctionnalité de mémoire cloisonnée de cette branche est de moi, développée seul en février 2026.
La base de données applique la même logique de son côté : des rôles distincts pour l’administration, les agents et les équipes, créés dès l’initialisation avec leurs propres utilisateurs. Si une requête passait le premier contrôle par erreur, elle se heurterait au second. Agents et administrateurs disposent chacun d’une skill qui décrit l’usage de la mémoire.
Ce que montrent les preuves
Les règles d’accès sont couvertes par des tests unitaires : un agent accède à son périmètre et se voit refuser celui d’un autre. Des tests de bout en bout tournent contre une vraie base Memgraph, pour vérifier que l’ensemble tient hors des maquettes2. Le code est public et se relit sur la branche3.
Tests unitaires Vitest sur les règles…
Tests unitaires Vitest sur les règles d’accès ; tests de bout en bout lancés par un script et une configuration dédiés, contre Memgraph en conteneur.
Ma présentation de ce travail évoque…
Ma présentation de ce travail évoque aussi des journaux d’audit et des réponses qui citent leurs sources. Je ne les ai pas encore vérifiés dans la branche, donc je ne les revendique pas ici.
Ce que cela change
Pour une organisation qui veut des agents capables de se souvenir, c’est la condition de départ : une connaissance partagée qui ne fuit pas d’un périmètre à l’autre. La même logique, étendue aux clients ou aux missions, éviterait qu’un agent mobilise dans un dossier ce qu’il a appris dans un autre. C’est la direction que je propose quand une organisation veut des agents qui se souviennent, sans mélanger les dossiers.
Limites
C’est un démonstrateur personnel : il établit le mécanisme, sans utilisateur externe, et je n’en revendique que ce que le code montre.
- L’extension à des périmètres par client ou par mission est une piste, pas une réalisation.
- Les tests de sécurité offensifs, injection de prompt et tentatives d’exfiltration entre périmètres, sont prévus mais pas encore réalisés.
- C’est une branche de fork, non proposée au projet d’origine.
Partager et réutiliser
Le lien, le texte brut et des visuels prêts pour LinkedIn.
