Traitement des données et sécurité

Remettez cette page à une revue de sécurité. Elle décrit ce qui quitte une machine qui exécute le client, ce qui y reste, combien de temps chaque enregistrement est conservé, et comment l’accès à la console est contrôlé.

OpenLatch contrôle un agent qui se comporte mal : un agent qui tourne en boucle ou dépense du budget pour un travail que personne n’a demandé, un agent qui a subi une injection par son contexte et agit en conséquence par ses outils, et un agent qui enfreint une politique tout en se comportant par ailleurs comme prévu. Ces défaillances produisent de vrais incidents, et c’est ce que la boucle de contrôle intercepte avant que l’action ne s’exécute. OpenLatch ne revendique aucune résistance face à un agent conçu pour le contourner.

Principes

Principe	Ce qu’il signifie
La décision est prise sur la machine	Chaque verdict est calculé sur la machine, avant que l’action ne s’exécute. La console n’est pas sur le chemin de décision
OpenLatch n’est sur aucun chemin réseau	Le client n’est pas une passerelle et n’inspecte aucun trafic de votre organisation. Vos agents atteignent leurs points d’accès de modèles exactement comme avant
Données minimales	Les valeurs sont masquées et les chaînes tronquées avant que quoi que ce soit ne quitte la machine, et des métadonnées sont envoyées partout où le contenu n’est pas nécessaire
Aucun identifiant ne quitte la machine	Les clés qu’utilisent vos agents restent sur la machine. Les mots de passe de proxy sont conservés par le système d’exploitation, jamais dans un fichier de configuration ni dans un journal

Inventaire des données

Lisez d’abord la deuxième colonne.

Donnée	Quitte la machine	Masquage et limites	Où elle est conservée	Conservation
Métadonnées d’action (nom d’outil, session, verdict, horodatage)	Oui	Aucun masquage. Les métadonnées ne portent pas de texte libre	Console	180 jours
Commandes shell et arguments d’outils	Oui	Identifiants masqués par des marqueurs étiquetés. Chaque chaîne plafonnée à 4 Ko	Console, et sous forme hachée dans les agrégats d’usage	180 jours ; agrégats 30 jours
Chemins de fichiers	Oui	Masqués de la même façon, et hachés avec une clé propre à l’organisation dans les agrégats d’usage	Console, et sous forme hachée dans les agrégats d’usage	180 jours ; agrégats 30 jours
Contenu des fichiers	Configurable	Filtré par défaut, ou empreinte seule. Capture en ligne plafonnée à 64 Ko	Console	180 jours
Prompts	Métadonnées seules	Occurrence, horodatage, session et longueur. Le texte du prompt n’est pas envoyé sauf si votre organisation l’active	Console	180 jours
Requêtes et réponses de modèles	Non	Le contenu n’est jamais envoyé. Le nombre de jetons, le modèle utilisé et la répartition du cache sont enregistrés	Console	90 jours
Identité de l’utilisateur	Oui	Utilisateur du système d’exploitation et e-mail git, pour attribuer une action à une personne	Console	180 jours, avec l’enregistrement
Identité de la machine	Oui	Système d’exploitation, architecture, adresses IP locale et publique, versions logicielles, un identifiant d’installation	Console	180 jours, avec l’enregistrement
Identifiant de compte de modèle	Oui	Un identifiant de compte, ou un marqueur indiquant qu’une clé partagée est utilisée. Jamais un jeton ni une clé	Console	180 jours, avec l’enregistrement
Politiques	Descendant uniquement	Envoyées à la machine, jamais remontées depuis elle	Sur la machine	Jusqu’à ce qu’un ensemble plus récent les remplace
Verdicts et anomalies	Oui	Aucun masquage	Console	180 jours

Figure 1. Flux de données et frontières de confiance : les enregistrements masqués remontent, les politiques descendent, et le trafic de modèles ne passe jamais par OpenLatch.

Masquage, et ce qui reste sur la machine

Le masquage s’exécute dans le client, sur la machine, avant qu’un enregistrement ne soit mis en file d’envoi. Il parcourt le contenu et remplace les valeurs qui ressemblent à des identifiants par un marqueur étiqueté qui garde le préfixe public reconnaissable et supprime le secret, sous la forme [AWS_KEY:AKIA***]. Seules les valeurs de chaîne sont masquées ; les noms de champs ne le sont jamais. Le masquage s’exécute avant la troncature : couper une chaîne au plafond de 4 Ko ne peut pas révéler la fin d’un secret partiellement masqué. Il s’exécute après le verdict : le texte expurgé ne change jamais les politiques qui correspondent. Votre organisation peut ajouter ses propres formes d’identifiants à la configuration du client, et elles s’appliquent en plus des formes intégrées.

Conservation

Donnée	Durée	Configurable	Export
Enregistrements d’actions	180 jours	Non	—
Enregistrements de décisions et anomalies	180 jours	Non	CSV
Agrégats d’usage	30 jours	Non	Console
Archives hachées	90 jours	Non	Console
Enregistrements de coûts et de jetons	90 jours	Non	Console
Journal d’audit	90, 180, 365 ou 730 jours, ou une durée personnalisée	Oui, avec purge automatique	CSV ou JSON

Le journal d’audit est la seule durée que vous définissez vous-même, dans la console, avec purge automatique ; Configurer l’organisation montre où. Toutes les autres durées ci-dessus sont fixes. Les politiques présentes sur la machine n’ont pas de durée de conservation : elles sont remplacées quand le client récupère un ensemble plus récent, et supprimées quand le client est désinstallé avec --purge.

Hébergement

La console est un service hébergé aux États-Unis, dans la région US-East. Les données de chaque organisation sont séparées de celles de toutes les autres par la base de données elle-même : la sécurité au niveau des lignes est imposée sur chaque table de locataire, sans aucun rôle d’exécution qui la contourne. La liste des sous-traitants est disponible sur demande.

En transit, le client et la console communiquent en TLS validé avec le magasin de confiance du système d’exploitation, avec la possibilité d’approuver une autorité de certification supplémentaire là où votre parc termine TLS avec la sienne, et sans aucune option qui désactive la vérification. Au repos, les secrets stockés sont chiffrés.

Identité et accès

La console prend en charge l’authentification unique SAML 2.0 par organisation. Vous fournissez l’identifiant d’entité du fournisseur d’identité, son URL d’authentification, et un certificat de signature ou une URL de métadonnées, puis vous définissez les domaines de messagerie autorisés. Un test effectue l’échange et indique le résultat avant la mise en service de la connexion. Microsoft Entra ID, Okta, PingOne et Active Directory Federation Services se connectent ainsi.

Deux portes contrôlent qui rejoint l’organisation. Les domaines de messagerie autorisés limitent les adresses que la console accepte, et les invitations contrôlent qui est admis. Une connexion SAML propre à l’organisation est la seule source d’identité qui admet un membre sans invitation : une connexion via un réseau social ne permet jamais de contourner le provisionnement.

Rôle	Ce qu’il permet
owner	Tout ce que permet admin, plus la propriété de l’organisation elle-même
admin	Réglages d’identité, politiques, identifiants du client et réglages de conservation
editor	Politiques et remplacements de propriétaire d’agent
viewer	Lecture des agents, des exécutions, des décisions et du journal d’audit. Les personnes invitées commencent ici

Un identifiant client hérite du rôle de la personne qui l’a émis. Un identifiant émis par un editor ne peut pas modifier un réglage d’identité, et révoquer l’identifiant ou rétrograder la personne ferment la même porte.

Le journal d’audit est en ajout seul et chaîné par hachage : une ligne supprimée ou modifiée rompt la chaîne. Chaque changement de politique écrit une ligne qui nomme l’auteur, avec l’état avant et après. Le journal s’exporte en CSV ou JSON, sa durée de conservation est configurable avec purge automatique, et l’export lui-même écrit un événement d’audit.

Protéger le client et ses politiques

Les mises à jour du client sont vérifiées en intégrité avant tout remplacement : l’empreinte SHA-512 du téléchargement doit correspondre à celle que le registre de paquets publie pour cette version. Cette vérification détecte la corruption et la troncature ; elle ne protège pas contre un registre compromis.

Les politiques présentes sur la machine sont vérifiées avant utilisation, puis à chaque chargement, pas seulement quand elles sont récupérées. Un ensemble qui échoue à la vérification est écarté et signalé, et la machine fonctionne sans politique jusqu’à l’arrivée d’un ensemble plus récent. Cet état est inscrit sur chaque enregistrement plutôt que passé sous silence, et il en va de même quand aucune politique n’a jamais été récupérée : l’action est autorisée et l’enregistrement dit pourquoi. OpenLatch ne bloque jamais une action parce qu’une politique manque.

Les éléments secrets sont conservés par le magasin d’identifiants du système d’exploitation quand il en existe un, et sinon dans un fichier lisible par son seul propriétaire. Un identifiant passé en ligne de commande est refusé, car une ligne de commande est lisible par les autres processus de la machine.

Télémétrie produit et rapports de plantage

La télémétrie produit porte sur le logiciel OpenLatch, pas sur les agents de votre organisation. Elle contient des noms de commandes, des durées, l’agent, des codes d’erreur et des volumes, et jamais de texte de commande, de chemin de fichier, de contenu de fichier ni de prompt. Le consentement est demandé à l’installation, peut être modifié ensuite, et est désactivé par défaut en intégration continue. Les rapports de plantage contiennent un message d’échec nettoyé et rien d’autre, et sont envoyés sauf si vous les désactivez.

Les deux voyagent vers app.openlatch.ai avec le trafic dont le client a besoin pour fonctionner : une règle réseau ne peut pas les arrêter sans couper le client de la console. Les réglages sont donc sur le client : refusez la télémétrie à l’installation ou lancez openlatch system telemetry disable, et désactivez les rapports de plantage avec OPENLATCH_CRASH_REPORTING=0. Désactivés, le client se comporte exactement comme lorsqu’ils sont actifs. Confidentialité et télémétrie les explique plus en détail.

Signaler une vulnérabilité

Envoyez les signalements de sécurité à security@openlatch.ai. OpenLatch accuse réception d’un signalement sous deux jours ouvrés et traite la question avec la personne qui l’a signalée.

En bref

Les métadonnées d’action, les commandes et chemins de fichiers masqués, les verdicts et les anomalies quittent la machine. Le texte des prompts reste sur la machine sauf si votre organisation l’active, et les requêtes et réponses de modèles ne sont jamais envoyées.
Un seul répertoire contient la configuration et les enregistrements locaux, en texte clair, protégés par les permissions de fichiers de l’utilisateur et votre chiffrement de disque. Les identifiants sont conservés par le système d’exploitation, ou dans un fichier réservé à son propriétaire.
Les enregistrements d’actions et de décisions sont conservés 180 jours, les agrégats d’usage 30 jours, les archives hachées et les enregistrements de coûts 90 jours. Le journal d’audit est la seule durée que vous définissez, avec purge automatique, et il s’exporte en CSV ou JSON.
La console est hébergée aux États-Unis (US-East), et les données de chaque organisation sont isolées par la base de données. SAML 2.0 par organisation, quatre rôles d’owner à viewer, des identifiants client qui héritent du rôle de leur émetteur, et un journal d’audit en ajout seul, chaîné par hachage.
Les mises à jour sont vérifiées en intégrité avant d’être installées, et les politiques de la machine sont vérifiées avant utilisation et à chaque chargement. Une machine sans politique utilisable autorise l’action et le dit sur l’enregistrement.