Des agents IA auto-hébergés, en production · installés en quinze minutes
Rikoo
ENFRES
 Installer

Sûr par construction, pas par consigne.

Un agent qui peut lire des documents, appeler des outils et répondre à des inconnus est une surface d'attaque d'un genre nouveau. Dire au modèle d'être prudent n'est pas un contrôle. Voici les contrôles.

Lire sur les guardrails Traitement des données
0
Donnée envoyée à l'éditeur
1
Bac à sable par exécution
Air-gap
Déploiement supporté
Append-only
Journal d'audit
Confinement

Ce qu'un agent peut atteindre, et ce qu'il ne peut pas.

  • Un bac à sable par exécution

    Les serveurs embarqués s'exécutent dans un espace de travail créé pour une seule exécution et détruit avec elle, sous une identité système dédiée. Il n'existe aucun chemin d'une exécution vers une autre, et le shell n'a aucun réseau.

  • Chaque appel sortant est gardé

    Tout ce qui quitte la plateforme passe une garde anti-SSRF qui refuse les adresses résolvant vers des réseaux internes. Le navigateur du bac à sable importe cette même garde plutôt qu'une copie.

  • Le contenu non fiable est encadré

    Les pièces jointes, les extraits retrouvés, les sorties d'outils et les descriptions de serveurs MCP sont encadrés comme des données avant d'atteindre le modèle. C'est la défense contre l'injection indirecte de prompt, et elle a une seule implémentation pour toute la plateforme.

  • Les secrets sont en écriture seule

    Les identifiants sont scellés sous une clé d'enveloppe et ne sont renvoyés par aucun point d'accès. Le serveur d'API ne les déchiffre jamais ; seul le worker le fait, uniquement dans la pile d'un appel sortant, et chaque accès est audité.

  • Le cloisonnement est structurel

    Chaque requête sur des données de locataire passe par un client qui exige une identité d'organisation. Les lectures inter-organisations ne sont pas une permission que l'on peut mal configurer : le chemin de code n'existe pas.

  • Rien de sensible dans les journaux

    Aucun secret ni contenu de conversation dans les journaux de diagnostic, et un fichier média n'entre jamais dans le journal d'exécution sous forme d'octets, seulement de pointeur. La même règle vaut pour les traces, où la capture de contenu est désactivée tant qu'un opérateur ne l'active pas.

Identité et accès

Des sessions que l'on ne peut pas voler dans le stockage

Les sessions du Studio sont opaques : un identifiant aléatoire stocké haché, dans un cookie limité à l'hôte et inaccessible au script. Aucun jeton dans le stockage du navigateur, et aucun identifiant de longue durée pour un humain.

  • Double expiration : huit heures d'inactivité, trente jours en absolu
  • Rotation à tout changement de privilège, et révocation immédiate
  • Hachage des mots de passe en Argon2id avec verrouillage progressif, et double facteur avec codes de secours
  • Authentification unique en OIDC et SAML, par organisation, avec domaines vérifiés (Enterprise)

Rôles et permissions

Des preuves, pas des promesses

Les invariants sont tenus par la compilation, pas par la relecture.

Les règles ci-dessus ne sont pas des conventions que l'équipe essaie de retenir. Chacune a un contrôle qui fait échouer la compilation quand elle est enfreinte : frontières de modules, interdiction du client de base de données brut, interdiction des appels sortants depuis le serveur d'API, interdiction d'un texte visible sans clé de traduction.

Les parties les plus risquées portent le plus de tests : panne et rejeu sur le moteur d'exécution sans double effet, étanchéité inter-collections et inter-organisations sur la recherche, une matrice de permissions pilotée par table, et une suppression qui ne laisse aucun orphelin en base ni dans le stockage objet.

Questions fréquentes

Ce qu'une revue de sécurité demande d'habitude.

Voyez-vous nos données ?

Non. La plateforme tourne sur votre infrastructure et ne nous remonte rien. Il n'y a aucune télémétrie d'usage, et une installation entièrement coupée du réseau est un déploiement supporté.

Où vivent nos identifiants ?

Dans le coffre de votre instance, chiffrés sous une clé racine que vous générez et que vous détenez. Nous ne l'avons jamais. Faites tourner un identifiant et l'ancienne valeur est remplacée ; rien n'est à ressaisir ailleurs.

Qu'est-ce qui empêche un agent de lire les documents d'une autre équipe ?

La recherche prend les collections attribuées en argument et filtre dessus dans la requête SQL elle-même. Les droits sont gelés à la création d'une exécution : élargir un agent en pleine conversation n'élargit pas une exécution en cours. Les deux frontières sont couvertes par des tests qui cherchent précisément à les franchir.

Que se passe-t-il si un document essaie de donner des instructions à l'agent ?

Il est encadré comme contenu non fiable avant d'atteindre le modèle, et des guardrails peuvent en plus bloquer ou escalader. C'est la principale défense contre l'injection de prompt indirecte. Elle réduit le risque ; personne ne devrait prétendre qu'elle l'élimine, et un agent exposé au public mérite les gabarits les plus stricts.

Peut-on obtenir une piste d'audit ?

Oui. Le journal d'audit consigne qui a fait quoi : une version publiée, un octroi modifié, un secret consulté, un membre invité, une clé révoquée. Il est en ajout seul, et la rétention étendue et l'export CSV relèvent d'Enterprise.

Avez-vous une certification ?

Pas à ce jour, et nous préférons le dire que de laisser croire l'inverse. Ce que nous pouvons donner à un évaluateur, c'est l'architecture, les invariants, les modèles de menace écrits pour chaque zone sensible, et le code source du cœur.

Envoyez-nous votre questionnaire de sécurité.

Nous répondons depuis l'architecture plutôt que depuis une brochure, et nous disons ce qui n'est pas couvert.

Nous contacter Lire les conditions de traitement des données