Sécurité
La sécurité, telle que le code l’applique.
Un agent a des accès, il agit, il se trompe. NakamaOS le traite comme un employé à risque : il ne fait que ce que vous autorisez, chaque action est journalisée, et ce qui part attend votre validation. Voici les cinq règles, et ce qui les tient.
Les cinq règles
-
1
Accès minimum
Ce qui lit passe ; ce qui écrit, envoie ou publie attend une permission.
Ce que ça empêcheQu’un texte lu par l’agent — une page, un mail, un ticket — déclenche une écriture ou un envoi que personne n’a vu passer. Le contrôle d’accès défaillant reste la première catégorie de risque applicatif recensée, agents ou pas.
Le détail technique
Un outil qui ne fait que lire — lire un fichier, chercher, faire une recherche web — s’exécute sans demande. La recherche web et la lecture d’une page passent donc sans demande : c’est un chemin de sortie connu ; sa fermeture est un ticket ouvert, la date sera dans le journal. Tout autre outil s’arrête et attend une réponse : refuser, autoriser une fois, pour la session, ou toujours. Ce contrôle est dans le code qui exécute l’appel, pas dans une phrase de la consigne. La permission se donne outil par outil et vaut pour tous les agents : un persona est une fiche de poste posée en tête du message, pas un jeu de droits. Dans le navigateur, lire la page est libre ; ouvrir une page, cliquer ou taper demande la permission, parce qu’une page lue peut contenir une instruction. Une commande ne passe sans demande que si elle est simple : programme autorisé, aucun métacaractère, aucun interpréteur, aucun chemin hors du dossier de travail. Le dossier des permissions, des clés et de la session est fermé aux agents, en lecture comme en écriture. Des permissions distinctes par persona seraient le prochain cran ; nous dirons ici le jour où il est posé.
Références : OWASP Top 10:2025 ; CWE-284 : Improper Access Control ; OWASP Top 10 for Agentic Applications
-
2
Revue
Ce qu’un agent produit est validé avant d’entrer en production : code, réponse client, document.
Ce que ça empêcheQu’un défaut introduit par un agent — ou une dépendance introduite par un agent — arrive en production sans que personne ne l’ait regardé.
Le détail technique
Pour un agent de code, la sortie est une pull request avec son rapport, validée avant fusion : à partir de la branche stable, rien n’y entre sans validation ligne à ligne. Cette règle est écrite dans les instructions du dépôt et tenue par la validation, pas par le moteur. Une réponse client, un article, un document passent par la même porte, et ce qui est publié porte le nom de qui a rédigé et de qui a validé. Les changements qui touchent l’authentification, les droits ou les données sont validés en priorité, quelle que soit leur taille. Une dépendance ajoutée par un agent est épinglée à une version et justifiée dans la demande : un agent qui installe une bibliothèque agit sur votre chaîne d’approvisionnement.
Références : Secure Software Development Framework 1.1 (SP 800-218) ; SLSA — Supply-chain Levels for Software Artifacts, v1.1 ; OWASP Top 10:2025
-
3
Registre
Chaque action est tracée, consultable, copiable telle quelle.
Ce que ça empêcheQu’un incident soit constaté sans pouvoir dire ce qui a été touché, par qui et quand — et qu’il faille croire l’agent sur parole.
Le détail technique
Chaque conversation est enregistrée événement par événement : les messages, les appels d’outils, les demandes de permission et les réponses. Les missions et leurs échecs vont dans un journal d’activité, et chaque classement de sensibilité dans un journal de routage. Ces journaux sont écrits par le moteur qui exécute l’appel, pas par l’agent : un agent ne raconte pas son action, il la subit. Les refus comptent autant que les réussites — une permission refusée laisse une trace, et ce sont ces lignes-là qu’on relit en premier. Ce sont des fichiers texte, une ligne par événement, lisibles et copiables tels quels — pas un écran qu’il faut nous demander.
Références : OWASP Top 10:2025 ; Directive (UE) 2022/2555 (NIS2) ; MITRE ATT&CK
-
4
Le niveau confidentiel
Au niveau confidentiel, les appels secondaires partent sur un modèle local ; la conversation principale reste sur le modèle choisi.
Ce que ça empêcheLa fuite d’information sensible par le chemin le plus banal : un document versé dans un contexte qui part chez un tiers.
Le détail technique
La donnée est classée par son origine — le dossier, l’étiquette du document — ou par un niveau choisi explicitement. Le routage lit ce niveau : au niveau confidentiel, les appels secondaires — le classement, le travail délégué à un second modèle — partent sur un modèle qui tourne sur la machine. Chaque décision de routage est écrite dans un registre consultable : pour chaque tour, le niveau retenu et la raison. Ce que cette règle ne couvre pas, et nous préférons le dire : la conversation principale suit le modèle choisi pour l’installation, sous votre contrat et avec votre clé, et le routage peut être désactivé dans les réglages — le registre montre alors qu’il l’est ; chez nous, il l’est encore. Le niveau confidentiel ne concerne que les appels secondaires : la page « Où vont vos données » nomme chaque flux.
Références : OWASP Top 10 for LLM Applications ; Recommandations de sécurité pour un système d’IA générative ; Règlement (UE) 2022/2554 (DORA)
-
5
Validé avant de partir
Ce qui envoie, publie, paie ou fusionne attend une validation. L’agent prépare.
Ce que ça empêcheQu’une suite d’appels automatiques produise un engagement que personne n’a voulu, et que l’autorité d’un agent soit empruntée par un autre.
Le détail technique
Les actions qui engagent — envoyer, publier, payer, répondre sur un contrat — s’arrêtent dans le code et attendent une personne : ce point de passage est dans le moteur, pas dans la consigne. La fusion d’une pull request est tenue par la règle écrite dans le dépôt et la validation, pas par le moteur. Une personne peut accorder une fois pour toutes une permission à un outil précis — c’est son droit, et c’est écrit dans un fichier qu’on peut relire. Ce qui reste impossible, c’est qu’un agent se l’accorde lui-même : le fichier des permissions lui est fermé par le code, parce qu’une seule écriture dedans suffirait à faire sauter tout le reste. Une mission programmée prépare et n’expédie pas ; elle a un déclencheur, un périmètre d’outils et un délai au bout duquel elle s’arrête.
Références : Règlement (UE) 2024/1689 sur l’intelligence artificielle ; AI Risk Management Framework 1.0 (NIST AI 100-1) ; CWE-441 : Unintended Proxy or Intermediary (« Confused Deputy »)
Le modèle de menace d’un agent
Un agent n’est pas un programme de plus. Il a des accès : des jetons, une boîte, un dépôt. Il a des outils qui agissent — écrire, envoyer, appeler, exécuter. Il a une mémoire qui survit à la tâche. Et il décide seul de l’ordre des opérations. C’est la définition d’un employé, sans le contrat de travail ni le jugement.
Ce que ça implique tient en une phrase : le contrôle se met dans le code, pas dans la consigne. Le modèle peut être trompé ; le périmètre, lui, ne négocie pas.
| Risque | Ce que ça donne concrètement | Ce qu’on oppose |
|---|---|---|
| Injection d’instruction | Un texte lu par l’agent — ticket, page, courriel, fichier — contient un ordre. L’agent change d’objectif en cours de tâche. | Toute entrée est une donnée, jamais un ordre. Dans le navigateur, lire est libre ; ouvrir, cliquer ou taper demande la permission. Toute action qui écrit ou envoie s’arrête et attend une personne. |
| Empoisonnement des données et de la mémoire | Une information fausse entre dans la mémoire ou la base de connaissances, et se rejoue à chaque tâche suivante. | Mémoire en écriture contrôlée, sources datées et attribuées, expiration, validation humaine de ce qui sert de référence. |
| Fuite par l’outil | Un outil légitime recopie un extrait sensible là où il ne devrait pas : un journal, un ticket, un message, un contexte envoyé dehors. | Classification à la source ; au niveau confidentiel, les appels secondaires sur un modèle local ; journal du routage ; aucun secret dans le contexte du modèle. |
| Confusion de délégué | Un agent exécute pour un demandeur une action que ce demandeur n’avait pas le droit de faire — parce que l’agent, lui, l’a. | Les permissions sont celles que la personne a données, outil par outil, et aucun agent ne peut se les accorder. En mode réponse directe, un agent ne peut pas en lancer un autre : l’appel est refusé par le code. |
| Dépassement de périmètre | Une chaîne d’appels qui commence dans le périmètre se termine en dehors : un envoi, un achat, une écriture non prévus. | Permission par défaut sur tout ce qui écrit ou envoie ; pour une mission, un jeu d’outils réduit, un délai de 8 minutes par défaut et aucune permission obtenable ; validation sur ce qui engage. |
| Chaîne d’approvisionnement | Une dépendance, un modèle ou un serveur d’outils tiers change sous les pieds de l’agent. | Versions épinglées, provenance vérifiée des artefacts, tout ajout passe par une demande validée, pas d’installation à l’exécution. |
| Action irréversible sans humain | Un paiement parti, un code fusionné, un message publié que personne n’a validé. | Point de passage humain dans le code pour ce qui envoie, publie ou paie ; pour la fusion, la règle écrite dans le dépôt et la validation ; fichier des permissions fermé aux agents, journal de chaque conversation. |
Lire l’analyse complète
Ce qui lui arrive n’a rien d’exotique. Il lit un ticket, une page, un courriel, un fichier — et ce texte contient une instruction écrite pour lui. Il appelle un outil qui fait un peu plus que ce que son nom annonce. Il enchaîne dix appels, et le dixième sort du périmètre que les neuf premiers respectaient. Aucune de ces trois situations ne suppose un attaquant sophistiqué. Il suffit d’écrire dans un endroit que l’agent lit.
D’où la première conséquence : une consigne n’est pas un contrôle. Le modèle reçoit l’instruction du système et la donnée qu’il lit dans le même canal, du texte. Tout ce qui repose sur « l’agent a pour instruction de ne pas… » est une politique de sécurité écrite dans le champ le plus facile à influencer. Si une interdiction compte, elle est appliquée par le code qui exécute l’appel, en dehors du modèle.
Le deuxième pli est l’identité. Un agent agit pour quelqu’un, avec des droits qui ne sont pas ceux de ce quelqu’un. Dès qu’un agent en appelle un autre, la question devient : de qui viennent les droits de l’appel ? La réponse doit être la même partout — du demandeur d’origine. C’est le cas classique du délégué confus, et il ne devient pas neuf parce qu’il y a un modèle au milieu.
Le troisième est la mémoire. Ce qu’un agent retient l’influence longtemps après la tâche où il l’a lu. Une donnée fausse ou hostile écrite une fois se rejoue à chaque tâche suivante, sans qu’aucune alerte ne se déclenche. On traite donc la mémoire comme une base de données : qui écrit, ce qui est daté, ce qui expire, ce qui se relit.
Ce que nous ne faisons jamais
- Nommer un client, coller du code client, publier une donnée personnelle.
- Publier quoi que ce soit qui aide un attaquant : pas de mode opératoire, pas de faille non corrigée, pas de détail d’architecture exploitable.
- Laisser un agent envoyer, publier, payer ou fusionner sans validation.
- Laisser un agent lire ou modifier ses propres permissions, ou mettre un secret en clair dans son contexte.
- Publier un chiffre sans sa source, ou taire un incident constaté.
Chez vous : installé, réglé, vérifié chaque mois
La version installée chez vous est NakamaOS complet, éprouvé chaque jour chez Nakama, réglé par un spécialiste de la sécurité applicative pour que les agents ne fassent que ce que vous autorisez, puis vérifié chaque mois.
Chaque mois : la version stable, les tests rejoués sur votre version, la configuration contrôlée — catalogue d’outils, autorisations permanentes, connecteurs, chiffrement du disque —, le diff des consignes et des missions. Le bulletin est préparé par les agents et validé ; il reste à vous.
Nous installons une entreprise à la fois, dans l’ordre de la liste d’attente.
Chaque composant de NakamaOS est figé et vérifié à chaque version. Si une faille est publiée, une consigne de coupure part sous un jour ouvré, et le correctif n’est jamais facturé en plus.
Trois questions de RSSI
Comment vous empêchez un agent de sortir nos données ?
Par trois barrières, dans cet ordre. La donnée est classée par son origine, donc l’agent ne décide pas lui-même de son niveau. Le routage lit ce niveau : au niveau confidentiel, les appels secondaires partent sur un modèle qui tourne sur la machine ; la conversation principale reste sur le modèle choisi, sous votre contrat et avec votre clé. Et tout ce qui écrit ou envoie demande une permission, qu’un agent ne peut pas s’accorder. Chaque décision de routage est écrite dans un registre, ce qui permet de vérifier après coup, ligne par ligne, quel appel est parti où. La réponse honnête tient en une phrase : le niveau confidentiel ne concerne que les appels secondaires, et la page « Où vont vos données » nomme chaque flux et chaque sous-traitant.
Que se passe-t-il quand un agent se trompe ?
Il se trompe, c’est prévu. Ce qu’il produit n’est pas de la production : c’est une proposition — une pull request, un brouillon, un ticket qualifié. L’erreur est donc rattrapée à la validation, et la validation est une personne, pas un second agent. Si elle passe quand même, le journal dit ce qui a été touché, quand et avec quel outil, ce qui ramène le périmètre de la reprise à des minutes plutôt qu’à des jours. Le rapport du mois compte ce qui a été refusé à la validation, quand c’est compté (pull requests refusées), et dit pourquoi.
Qu’est-ce que vous nous donnez pour notre propre audit ?
Les journaux d’abord : chaque conversation, événement par événement, horodatée, écrite par le moteur et non par l’agent, remise sous forme de fichiers que votre auditeur relit avec ses propres outils. Ensuite le fichier des permissions tel qu’il est effectivement appliqué, outil par outil, et la trace des routages, qui montre quel appel secondaire est parti vers quel modèle. Ensuite la chaîne de livraison : qui a proposé, qui a validé, qui a fusionné, pour chaque changement. Enfin le dossier d’installation, le bulletin du mois, et la correspondance entre nos règles et les cadres que votre auditeur utilise. Nous ne fournissons pas de certificat ; nous fournissons de quoi vérifier.
Signaler une faille
Une faille dans NakamaOS, dans ce site ou dans notre service en ligne de cybersécurité se signale à security@nakamaos.ai ; l’adresse est dans /.well-known/security.txt. Une réponse écrite, préparée par nos agents et validée ; pour une installation chez un client, une consigne de coupure sous un jour ouvré.
Ce qui donnerait un mode opératoire à un attaquant n’est jamais publié : une faille est décrite par sa classe, une fois corrigée, avec la date du correctif.
Les références
Les cadres sur lesquels ces règles s’appuient, et ce que chacun sert à trancher. Les liens partent chez leurs auteurs, pas chez nous.
- 1
OWASP Top 10:2025
OWASP Foundation, 2025
La liste de référence des risques applicatifs : le contrôle d’accès reste premier, la chaîne d’approvisionnement entre au troisième rang.
- 2
OWASP Top 10 for LLM Applications
OWASP Gen AI Security Project, 2026
La taxonomie des risques propres aux applications à modèle de langage : injection d’instruction, divulgation d’information sensible, empoisonnement.
- 3
OWASP Top 10 for Agentic Applications
OWASP Gen AI Security Project, 2026
Le cadre propre aux agents autonomes : planification, usage des outils, identité, mémoire, communication entre agents.
- 4
MITRE ATT&CK
MITRE, à jour
La grille sur laquelle on aligne ce qu’un journal doit permettre de détecter et de raconter après un incident.
- 5
MITRE ATLAS
MITRE, à jour
L’équivalent d’ATT&CK pour les systèmes d’IA : les techniques réellement observées contre des modèles et leurs chaînes d’outils.
- 6
AI Risk Management Framework 1.0 (NIST AI 100-1)
NIST, 2023
Le cadre de gestion du risque IA dont relève notre point de passage humain.
- 7
Secure Software Development Framework 1.1 (SP 800-218)
NIST, 2022
Les pratiques de développement sécurisé auxquelles se rattache la revue obligatoire avant mise en production.
- 8
CWE-284 : Improper Access Control
MITRE, à jour
La désignation précise du défaut que la règle « accès minimum » vise à rendre impossible.
- 9
CWE-1427 : Improper Neutralization of Input Used for LLM Prompting
MITRE, à jour
La formulation normalisée de l’injection d’instruction, rattachée à la famille injection plutôt qu’à une curiosité de l’IA.
- 10
CWE-441 : Unintended Proxy or Intermediary (« Confused Deputy »)
MITRE, à jour
Le nom du problème de délégation qui réapparaît dès qu’un agent en appelle un autre.
- 11
SLSA — Supply-chain Levels for Software Artifacts, v1.1
OpenSSF, 2025
Les niveaux de provenance auxquels on mesure le fait qu’un artefact vienne bien de la chaîne annoncée.
- 12
Règlement (UE) 2024/1689 sur l’intelligence artificielle
Union européenne, 2024
Le texte qui fonde l’obligation de contrôle humain et la classification des usages à haut risque.
- 13
Règlement (UE) 2024/2847 (Cyber Resilience Act)
Union européenne, 2024
Les exigences de sécurité produit et de gestion des vulnérabilités qui s’appliqueront au logiciel que nous livrons.
- 14
Directive (UE) 2022/2555 (NIS2)
Union européenne, 2022
Les obligations de gestion du risque et de notification d’incident que le journal doit permettre de tenir.
- 15
Règlement (UE) 2022/2554 (DORA)
Union européenne, 2022
Le cadre que nos clients du secteur financier nous opposent sur le risque lié aux prestataires informatiques tiers.
- 16
ISO/IEC 27001:2022 — Systèmes de management de la sécurité de l’information
ISO / IEC, 2022
La grille de lecture d’un auditeur sur la journalisation, la gestion des accès et la preuve documentaire.
- 17
ISO/IEC 42001:2023 — Système de management de l’intelligence artificielle
ISO / IEC, 2023
La norme à laquelle nous comparons notre organisation, sans la revendiquer.
- 18
Recommandations de sécurité pour un système d’IA générative
ANSSI, 2024
La référence française sur le cloisonnement des environnements d’inférence et la sécurisation d’une architecture d’IA générative.
Vos agents passeraient-ils cet examen ?
L’audit IA et agents commence par là : quels accès ont vos outils d’IA aujourd’hui, qui valide ce qu’ils produisent, et ce qui se passe quand ils se trompent. Une réponse écrite, préparée par nos agents et validée.