Sécurité
Aucun droit sur votre cluster. Des droits par projet. Des agents sous contrôle.
graal Data Platform et graal Agentic Platform sont conçues pour la revue de votre RSSI : installation sans privilège, identités fédérées, trace de chaque action, et aucune donnée envoyée à l’éditeur.
Isolation
Ce que graal demande à votre cluster
Un audit de vos habilitations n’a pas à croire notre documentation sur parole : le rendu du chart se relit, objet par objet.
Aucun droit sur le cluster
Aucune ressource personnalisée, aucun rôle global : les deux plateformes travaillent avec les seuls droits que votre équipe plateforme leur accorde.
Voir la spécification techniquePods restreints, sans exception
Tous les pods, y compris ceux de vos traitements et les bacs à sable des agents, tournent en PSA restricted : utilisateur non privilégié, capacités Linux retirées, profil seccomp par défaut.
Un réseau fermé par traitement
Chaque run reçoit sa politique réseau : il ne joint ni un autre projet ni une autre organisation, et ses sorties se limitent aux destinations autorisées.
Des images sous contrôle
Les traitements ne tirent que des images de registres autorisés, épinglées par empreinte : aucune image arbitraire ne démarre.
Identité
Qui peut quoi, sur quoi
Les rôles et leurs titulaires se lisent dans la console, et se retirent au même endroit.
Les rôles d’une organisation : ce que chacun peut faire, et sur quoi.
Interface réelle de la console graal, non retouchée ; données de démonstration fictives (locataire energie-demo — personnes, projets et jetons inventés).
Votre SSO, votre annuaire
Fédération OIDC ou SAML, annuaire LDAP ou Active Directory, authentification multifacteur imposable. Les deux plateformes se raccordent au même SSO.
Le projet est l’unité de droits
Rôles par ressource, groupes de votre annuaire, affectations révocables en un clic.
Une organisation, un annuaire
Chaque organisation a son propre domaine d’authentification : l’isolation est une frontière d’identité, pas une colonne dans une table.
Data Platform et agents IA
Des agents qui pilotent vos données, sous vos règles
Un agent IA est un porteur de droits comme un autre : il s’authentifie, il est limité à un projet, il est tracé et il se révoque. Il pilote la Data Platform par son serveur MCP.
Le panneau Agents : le compte de service connecté, ses droits, et chacun de ses appels d’outils, en direct.
Interface réelle de la console graal, non retouchée ; données de démonstration fictives (locataire energie-demo — personnes, projets et jetons inventés).
Un compte de service par projet
L’agent agit sous sa propre identité, jamais sous celle de la personne qui l’a créé.
Validation humaine
Les actions sensibles attendent l’accord d’une personne habilitée, autre que le créateur de l’agent.
Politiques par agent
Opérations permises, projets, coût maximal et plages horaires, agent par agent.
Aucun outil destructif activé par défaut
Un agent crée, lance et planifie ; supprimer reste un choix explicite de votre part.
Visible et révocable
Chaque appel s’affiche en direct dans la console ; retirer un droit prend effet à la requête suivante.
Le modèle de votre choix
Hébergé chez vous ou chez le fournisseur que vous retenez : un modèle externe ne reçoit que ce que les outils lui renvoient.
Agentic Platform
Ce qui arrête un agent, ce sont des mécanismes
Un agent exécute du code que personne n’a relu, avec un modèle qui peut se tromper ou être manipulé par un texte piégé. L’Agentic Platform part de ce constat : aucune consigne donnée au modèle ne protège, ce sont des mécanismes qui retiennent l’agent.
| Ce que l’on redoute | Ce qui l’arrête |
|---|---|
| L’agent écrit hors de la zone autorisée | La demande d’écriture est refusée ; après le run, les fichiers modifiés sont comparés à la zone déclarée et ramenés à leur état d’origine s’ils en sortent. La garantie « zone respectée » refuse le passage, y compris quand elle ne peut pas lire les modifications. |
| L’agent exfiltre des données | Le réseau du bac à sable est fermé par défaut. La seule sortie est un relais par projet, dont la liste de domaines est celle de la politique du projet, en HTTPS uniquement. |
| L’agent utilise un identifiant | Il n’en détient aucun pour un outil ou un système tiers : la plateforme appelle l’outil à sa place, avec ses propres clés, et l’agent ne voit ni l’adresse, ni le vrai nom de l’outil. Le pod ne reçoit que des jetons à courte durée de vie, émis pour son run (jeton de run, clé de modèle plafonnée, jeton de dépôt limité au dépôt). |
| L’agent pousse un secret, ou affirme avoir testé | Les garanties lisent les modifications, pas le récit de l’agent : un secret dans les modifications refuse le passage, et l’exécuteur du run lance lui-même les tests et remplace les preuves que l’agent déclare. |
| L’agent dépense sans limite | Chaque run reçoit sa propre clé de modèle, plafonnée à ce qui reste du budget de l’étape, de l’agent, du ticket et du projet. Au plafond, la passerelle refuse l’appel suivant ; les appels d’outils comptent dans le même registre que les appels de modèle. |
| L’agent s’échappe de son conteneur | Le pod est non privilégié, sans capacité Linux, avec un profil seccomp et sans jeton de compte de service ; une règle d’admission refuse tout pod qui n’a pas ce contexte. gVisor ou Kata Containers s’y ajoutent là où votre politique les impose. |
| L’agent touche la production | Une mise en production passe par trois verrous indépendants : la file de fusion, le train de livraison (fenêtre, validation, gel avec motif, retour arrière) et les garde-fous déclaratifs de votre outil de déploiement. |
| Un texte piégé donne des ordres à l’agent | Les tickets, les documents et la mémoire sont marqués comme données, jamais comme instructions, et ne confèrent aucun pouvoir : même suivi par l’agent, un texte piégé se heurte aux mécanismes de cette liste. |
| L’agent écrit chez un tiers sans accord | Par défaut, une écriture vers un système tiers est une action en attente : elle n’est jouée qu’après la décision d’une personne habilitée, autre que celle qui la propose, ré-authentifiée depuis peu. Ni un jeton d’API ni un client MCP ne décide. |
| L’agent obtient plus de droits que la personne qu’il sert | Un agent qui agit pour une personne détient l’intersection de leurs droits. Découvrir un outil ne l’ouvre jamais : un outil que le projet n’a pas déclaré répond comme s’il n’existait pas. |
Les garde-fous de l’agent lui-même arrêtent les cas courants et se règlent par politique. Ce qui tient quand ils échouent, ce sont les murs : le bac à sable, le réseau fermé, l’absence d’identifiant et la vérification des modifications après le run.
Secrets
Chiffrés en base, livrés en mémoire
Un traitement doit joindre une base de données ; le mot de passe qui le permet ne doit ni se lire en clair, ni voyager.
Chiffrés en base
Scellés en AES-256-GCM, avec une clé par organisation dérivée d’une clé racine par HKDF-SHA256. Le nom du secret sert de donnée authentifiée : déplacé, il ne se déchiffre plus.
Livrés en mémoire
Un traitement reçoit ses secrets au démarrage, en mémoire : ils n’apparaissent ni dans la spécification des pods ni dans les journaux.
Désignés, jamais recopiés
Connecteurs et pipelines désignent un secret par son nom : le code exporté ne contient aucun mot de passe.
Des clés qui s’éteignent avec le run
La clé de modèle d’un run est révoquée à sa fin, quelle qu’en soit l’issue ; son jeton expire peu après la durée maximale du run et son secret disparaît avec lui. Aucun n’est écrit dans la base.
Audit
Chaque action laisse une trace
Le même journal pour les personnes et pour les agents, relisible et exportable.
- Qui a fait quoi, sur quelle ressource, avec quel résultat, personne ou agent
- L’adresse d’origine de chaque requête
- Les connexions, les refus d’accès et les révocations
- Les validations accordées ou refusées : qui a décidé, quand, et combien de minutes après s’être authentifié
- Pour chaque run d’agent : l’agent, les outils appelés, le verdict de chaque garantie et le coût par modèle et par outil
- Les appels des clients MCP, nommés par agent
- Un journal exportable vers votre SIEM
- Les coûts et les quotas, projet par projet
Rien ne sort
Ce que graal n’envoie pas, et ce qu’il livre
Les plateformes n’ont besoin d’aucun service extérieur pour fonctionner.
Aucune télémétrie
graal n’envoie rien à l’éditeur : ni statistique d’usage, ni rapport d’erreur, ni donnée de vos projets.
Aucun service tiers
Ni SaaS, ni polices, ni captcha externes : les plateformes fonctionnent dans un réseau fermé. Le modèle qui anime un agent est celui que vous choisissez : hébergé chez vous, rien ne sort.
Une chaîne logicielle vérifiable
Images signées, épinglées par empreinte, et nomenclature logicielle (SBOM) livrée avec chaque version.
Un code que vos équipes peuvent relire
Le code des deux plateformes est open source, sous licence Apache 2.0.
Signalement
Signaler une vulnérabilité
Écrivez à security@graal.systems. Nous accusons réception, corrigeons, et vous tenons informé jusqu’à la publication.
Passez graal devant vos équipes sécurité
Rendu des charts, liste des droits demandés, modèle d’habilitation et réponses à vos questionnaires : sur demande.