Sécurité chez Skris

Skris est conçu pour fonctionner sur site, dans un cloud privé ou dans un VPC client. Il peut être exploité comme service ciblé sur VM ou serveur physique, sous forme de workloads Docker ou comme workload Kubernetes interne, derrière les contrôles existants d'ingress, de secrets, de réseau et d'observabilité de l'organisation.

Ce modèle permet au client de choisir le périmètre réseau, les sorties autorisées, le stockage, les régions, les fournisseurs et les accès opérationnels adaptés à son environnement.

Applications, collaborateurs, équipes et agents se connectent avec des clés Skris émises par l'organisation. Les clés API utilisateur sont stockées sous forme de hash, tandis que les identifiants des fournisseurs sont chiffrés et gérés centralement dans Skris au lieu d'être distribués aux outils utilisateurs.

Chaque requête gouvernée est évaluée avant d'atteindre un modèle cloud, privé ou local. Les règles d'accès, de débit, de tokens, de budget et de texte en ligne peuvent autoriser, avertir, masquer ou refuser.

Des instructions et transformations approuvées peuvent être appliquées avant le routage. Les alias de modèles contribuent à empêcher les clients de contourner les choix de fournisseurs et de modèles définis par les administrateurs.

Skris sépare le traitement en direct de la conservation facultative du contenu. La capture brute des prompts et réponses est désactivée par défaut ; l'organisation peut l'activer explicitement, de façon limitée, chiffrée et avec des règles de conservation lorsqu'un workflow l'exige.

Les événements opérationnels — périmètre d'identité, route, usage, coût et décision de politique — peuvent être enregistrés sans transformer Skris en entrepôt central du contenu des prompts.

Les administrateurs peuvent exploiter les traces opérationnelles pour comprendre les accès aux modèles, décisions de routage, résultats des politiques, consommation, coûts et performances. Les exports d'audit chaînés par hash sont conçus pour soutenir les revues internes et les besoins de preuve.

Le client reste responsable de définir les procédures d'accès, de supervision, d'export et de conservation adaptées à son déploiement.

La sécurité dépend du produit et de son environnement d'exécution. Skris fournit des points de contrôle ; le client reste responsable du durcissement de l'infrastructure, de l'intégration des identités, de la rotation des secrets, des règles réseau, sauvegardes, contrôles d'accès administrateur, configurations fournisseurs, systèmes de supervision et procédures de réponse aux incidents.

Les exigences précises d'architecture, de disponibilité, de conformité et d'assurance doivent être validées lors d'une revue technique. Cette page est une vue d'ensemble, et non une certification ou une garantie de conformité à un référentiel particulier.

Skris est en développement actif. Les fonctionnalités, modes de déploiement et éléments d'assurance peuvent évoluer avec le produit. Le comportement et les contrôles actuels doivent être confirmés sur la version évaluée par votre organisation.

Nous ne revendiquons actuellement aucune certification SOC 2 ou ISO 27001 sur ce site. Si une assurance indépendante ou des preuves formelles de conformité sont nécessaires, elles doivent être incluses dans les critères d'évaluation à discuter.

Si vous pensez avoir identifié une vulnérabilité dans un produit Skris ou sur ce site, envoyez une description claire, le composant concerné, l'impact potentiel et les étapes de reproduction à notre adresse de sécurité. N'accédez pas, ne modifiez pas, ne téléchargez pas et ne conservez pas de données qui ne vous appartiennent pas, et évitez toute action susceptible de perturber le service.

Nous examinerons les signalements responsables et coordonnerons les étapes suivantes. Consultez la Politique de divulgation des vulnérabilités avant tout test ou publication de détails.