Un agent capable de tout installer, tout appeler et tout écrire n’est sûr que si les barrières sont réelles. Dans Kortix, elles se trouvent sous l’agent, dans la plateforme, là où un prompt ne peut pas les contourner par la persuasion.
Une session n’est pas un onglet dans un environnement d’exécution partagé. C’est une machine indépendante, et la base de données n’autorise pas deux sessions à en partager une. Séparer deux de vos propres sessions repose sur le même mécanisme que séparer celles de deux clients différents.
dans une session
ne franchit jamais la frontière
Un outil a besoin d’un véritable identifiant pour effectuer un vrai travail ; la question honnête n’est donc pas de savoir si la machine en détient un, mais quelle machine détient quelle clé, qui l’a décidé et ce qui n’y entre jamais.
01
Chiffrée avec AES-256-GCM à l’aide d’une clé dérivée par projet.
02
Le rôle de la personne et l’autorisation déclarée par l’agent doivent tous deux l’autoriser.
03
Placée dans la session au démarrage, par son nom, sur tmpfs avec le mode 0600.
04
L’outil la lit depuis l’environnement. Elle n’est pas écrite dans le prompt.
05
Le fichier est effacé à l’arrêt et la machine est détruite avec lui.
La plupart des outils d’IA donnent à l’agent accès à tout ce que peut atteindre la personne qui l’a lancé. Kortix ne le fait pas. Une identité d’agent possède ses propres politiques, évaluées séparément, et ne peut donc pas hériter d’un accès à quelque chose que vous ne lui avez jamais accordé.
principal
type de ressource
Les autorisations s’attachent à un principal, pour une action, sur un type de ressource.
Rôles intégrés — sur tous les plans
account
project
Enterprise
Available on Enterprise, and on a self-hosted instance with an Enterprise license. The built-in roles above are free on every plan.
Un compte de service est une identité machine de premier ordre détenue par le compte, et non un token humain déguisé. Les politiques s’y attachent directement, et chaque requête est évaluée uniquement selon ses propres politiques — elle n’hérite jamais des accès de la personne qui l’a créée.
Une personne ou un groupe peut être limité à des agents et compétences nommés au sein d’un projet : le marketing peut utiliser cet agent et cette compétence, et rien d’autre. Tout ce qui n’est pas limité reste accessible à l’échelle du projet ; le ciblage est donc opt-in plutôt qu’une restriction à annuler.
L’approbation n’est pas un paramètre enfoui dans un panneau d’administration. C’est un bloc dans kortix.yaml, versionné avec le reste, qui indique quels appels d’outils s’exécutent, lesquels attendent une personne et lesquels sont refusés catégoriquement.
# reads run; writes and destructive calls stop for a humanpolicy: default_mode: risk policies: # a name-only rule cannot gate the target — conditions can - match: gmail.send_email action: require_approval conditions: - arg: to match: /@example\.com$/ # anything else through this tool is refused outright - match: gmail.send_email action: block # whole connectors can be gated with one glob - match: stripe.* action: require_approvalTrois actions
always_run, require_approval, block. Une règle correspond à un glob sur des chemins d’outils entièrement qualifiés ; une seule ligne peut donc couvrir un appel ou tout un connecteur.
Protéger la cible, pas seulement l’outil
« L’agent peut-il envoyer un email ? » n’est pas une mesure de protection. Les conditions correspondent aux arguments, donc la règle peut être « uniquement à ces adresses ». Un argument impossible à évaluer entraîne un refus par défaut.
Aucun « autoriser toujours » global
Chaque appel soumis à contrôle est approuvé séparément, avec ses arguments sous vos yeux. Il n’existe aucune autorisation valable pour toute la session derrière laquelle un appel ultérieur aux arguments différents pourrait se cacher — ce raccourci a été supprimé au niveau de l’application des règles, pas seulement de l’interface.
Définissez la valeur par défaut souhaitée
default_mode: risk fait exécuter les lectures et soumet les écritures et appels destructifs à une personne. Un projet sans bloc de politique conserve l’ancien comportement permissif ; définissez donc ce paramètre explicitement.
Un agent peut écrire autant qu’il le souhaite sur sa propre branche. Intégrer ce travail à main est une capacité distincte qu’il ne possède pas, sauf si vous la lui accordez délibérément — et cet accord est lui-même une modification qui doit être approuvée.
Chaque modification arrive sur la branche créée pour cette session. Rien de ce que fait l’agent n’est visible par une autre session ni par main.
Quand l’agent veut conserver quelque chose après la destruction de la machine, il commit et ouvre une demande de modification vers main. C’est l’unique porte d’entrée.
Une demande de modification est un diff. La réécriture de son propre prompt par un agent est examinée comme une modification de code — parce que c’en est une. Une demande dont le manifeste n’est pas valide ne peut absolument pas être fusionnée.
La fusion est une capacité distincte, refusée à tous les agents sauf si un administrateur l’accorde. Cette autorisation figure dans kortix.yaml : un agent ne peut donc pas étendre ses propres accès sans une demande de modification approuvée par quelqu’un d’autre.
Chaque action de compte et chaque action d’agent est enregistrée sur tous les plans. Le plan détermine qui peut lire, exporter ou diffuser cet historique — pas son existence.
Le même produit est proposé dans le cloud géré, sous forme de stack dans votre propre réseau ou en déploiement isolé. Il est open source : ce à quoi vous faites confiance est donc du code que vous pouvez lire.
Le service géré. Nous exploitons le plan de contrôle et le compute ; vous dirigez l’entreprise.
Une stack Docker Compose sur votre machine, à partir des mêmes images que celles utilisées par le cloud géré. Votre base de données et vos fichiers résident sur un disque que vous contrôlez.
A single-tenant deployment inside your own network. Isolated topologies are scoped with us rather than self-served.
Où nous en sommes réellement
Nous ne détenons ni ISO 27001 ni HIPAA, et ne prétendons pas le contraire. Lorsqu’un rapport sera disponible, cette ligne changera le jour même — pas avant.
N’ouvrez pas de ticket public pour une vulnérabilité. Écrivez au contact sécurité en indiquant la version ou le commit concernés, la procédure de reproduction et l’impact.
contact de sécurité
security@kortix.comNous citons les personnes qui le souhaitent, une fois le correctif déployé.
Commencez par une tâche et développez à partir de là.