Ground – Beyond the lakehouse: the ontology as the data layer AI & humans can actually useS'inscrire →

Trust Centre

Vous gardez le contrôle

Scrydon est conçu pour que la sécurité soit le défaut, et non une option. Chaque requête externe franchit cinq portes avant d'atteindre un service, la plateforme est livrée fail-closed, et vos données, vos clés et votre IA restent dans votre périmètre.

Comment est-ce sécuriséConformité & preuves

Fail-closed par défaut

Si un contrôle ne peut être satisfait, l'accès est refusé. Le résultat sécurisé est le résultat standard.

Vos clés, votre périmètre

Les stratégies de clés LOCAL, BYOK et HYOK maintiennent le chiffrement — et la confiance — de votre côté.

Démontrable & auditable

L'audit immuable et les evidence packs par cadre rendent le contrôle démontrable, et pas seulement revendiqué.

La sécurité par l'architecture

Cinq portes, puis fail-closed

Ici, la défense en profondeur n'est pas un slogan. Chaque requête externe franchit cinq portes indépendantes avant d'atteindre le moindre service. Chaque porte est conçue pour refuser par défaut : une erreur de configuration ou une habilitation manquante bloque l'accès plutôt que de l'accorder silencieusement.
  1. 1

    Durcissement de l'entrée

    Les en-têtes d'identité falsifiés sont supprimés en périphérie. L'identité interne n'est jamais accordée depuis l'extérieur ; elle est établie à l'intérieur du périmètre.

  2. 2

    Autorisation

    Un point de décision de politique unique évalue chaque requête sous forme de policy-as-code (Rego), à la fois sur le plan applicatif et sur le plan des données.

  3. 3

    Service mesh mTLS

    Les services s'authentifient mutuellement en TLS mutuel. Aucun jeton bearer partagé, aucune confiance implicite entre workloads.

  4. 4

    Gestion des secrets

    Les identifiants sont chiffrés au repos, cantonnés à chaque habilitation et masqués dans les journaux. La lecture d'un secret sans habilitation valide échoue purement et simplement.

  5. 5

    DLP & journalisation d'audit

    Les sorties traversent le moteur de garde-fous et chaque opération privilégiée est inscrite dans une piste d'audit immuable et interrogeable.

Fail-closed par défaut.Les identités mTLS invalides sont rejetées, les contrôles d'autorisation en échec refusent l'accès, et les workflows s'exécutent sous des habilitations émises par le serveur — jamais sous des identités fournies par l'utilisateur.

Protection des données & DLP

Le moteur de garde-fous

La prévention des fuites de données est la cinquième porte. Avant que la sortie d'un modèle ne quitte la plateforme, elle traverse le moteur de garde-fous DLP, qui recherche les données à caractère personnel, signale les hallucinations potentielles et valide les motifs regex et les schémas JSON. Ce qui ne passe pas ne sort pas.
  • Détection des données personnelles : Les sorties des modèles sont analysées à la recherche de données à caractère personnel avant de quitter la plateforme.
  • Signalement des hallucinations : Les réponses sont confrontées à leur ancrage, afin que les affirmations non étayées puissent être signalées ou bloquées.
  • Contrôles regex & JSON : La validation par motif et par schéma impose la forme exacte de ce qui peut être renvoyé.
  • Contrôle de l'exfiltration : Les garde-fous se placent sur le chemin de sortie et empêchent les données sensibles de s'échapper dans une réponse.
Identité & accès

Identité Zero-Trust

L'accès est régi par un point de décision de politique unique qui évalue chaque requête sous forme de policy-as-code. L'identité est structurée en trois niveaux — rôles d'organisation, appartenance aux espaces de travail et habilitations d'équipe — et s'intègre à vos SSO et SCIM existants : arrivées, mobilités et départs sont traités automatiquement.

Découvrez la couche d'identité souveraine sous-jacente.

  • Zero-Trust par défaut : Les workflows s'exécutent sous des habilitations émises par le serveur, jamais sous des identités fournies par l'utilisateur.
  • SSO & SCIM : Connectez votre fournisseur d'identité pour l'authentification unique et le provisionnement et déprovisionnement automatisés des utilisateurs.
  • Modèle à trois niveaux : Rôles d'organisation, appartenance aux espaces de travail et habilitations d'équipe se composent en un accès au moindre privilège.
  • Isolation multi-tenant : Les tenants sont isolés par conception : une organisation ne peut jamais atteindre les données d'une autre.
Vos clés, votre périmètre

Le chiffrement à vos conditions

Vous choisissez jusqu'où va la confiance. Scrydon prend en charge trois stratégies de clés, et les fournisseurs d'IA externes sont toujours opt-in — la plateforme peut fonctionner en air-gap du cloud public, entièrement dans votre périmètre, jusqu'à ce que vous en décidiez autrement.

LOCAL

Chiffrement géré par la plateforme. Les identifiants sont chiffrés au repos et masqués dans chaque ligne de journal — la voie la plus rapide vers un défaut durci.

BYOK — apportez votre clé

Vous fournissez les clés de chiffrement. Scrydon les utilise pour protéger vos données, tandis que vous en conservez la propriété et la faculté de les révoquer.

HYOK — conservez votre clé

Les clés ne quittent jamais votre garde. La plateforme opère avec des clés que vous détenez, ce qui maintient le contrôle ultime fermement de votre côté de la ligne.

L'IA externe est opt-in.Aucune requête ne part vers un modèle tiers sans que vous l'ayez explicitement autorisé : la souveraineté est un réglage que vous contrôlez, et non une promesse à laquelle vous devez vous fier.

Audit & responsabilité

Un enregistrement immuable

Chaque opération privilégiée génère une entrée d'audit immuable et interrogeable — capturant l'acteur, son adresse IP et l'action réalisée, conservée selon votre politique. Parce que la piste est en ajout seul, la trace de ce qui s'est passé ne peut pas être discrètement réécrite : vous et vos auditeurs disposez d'une source de vérité unique et fiable.

La responsabilité est gouvernée de bout en bout par la gouvernance de l'IA, qui réunit politique, identité et audit dans un même plan de contrôle.

Standards ouverts

L'Agent Control Standard

La supervision des agents ne devrait pas être réinventée par chaque éditeur. L'Agent Control Standard (ACS) est un standard neutre, développé au grand jour, gouverné par consensus communautaire et hébergé chez OWASP : il définit comment un agent déclare une étape avant d'agir et comment un Guardian répond — autoriser, refuser, modifier, demander ou différer. Scrydon met en œuvre le contrat ACS v0.1.0 : chaque tour d'agent gouverné franchit cette frontière, signé, enregistré et fail-closed.

Scrydon met en œuvre ACS v0.1.0

Fail-closed, et non négociable à la baisse

Scrydon négocie une posture de refus en cas de défaillance et la renvoie comme un plancher qu'aucune contrepartie ne peut abaisser. Un dépassement de délai, une signature invalide, une réponse malformée ou une écriture d'état non confirmée arrête l'action au lieu de la laisser passer. Une exécution non gouvernée est enregistrée comme telle et n'est jamais assimilée à une autorisation.

Signé et protégé contre le rejeu

Chaque requête porte sa propre identité, un horodatage et un nonce, signés sur une enveloppe canonique avec une clé dérivée par session — le secret racine ne circule jamais sur le réseau. Les identités dupliquées, les nonces réutilisés, les requêtes hors de la fenêtre de dérive d'horloge convenue et tout appelant dont la vision de la session diverge de l'enregistrement durable sont refusés.

Un registre de décisions inaltérable

Les requêtes porteuses de contenu font avancer une chaîne par session à l'épreuve des altérations, et les refus sont inscrits au journal d'audit immuable en tant que constat de gouvernance — acheminé vers votre SIEM par la livraison signée déjà configurée. Les faits de clôture ne peuvent pas annuler rétroactivement un travail déjà achevé.

Ce que Scrydon ne revendique pas

Un profil de conformité n'est déclaré que lorsque le déploiement en cours dispose réellement des méthodes, algorithmes et destinations correspondants : les profils d'inspection d'inventaire et de cryptographie asymétrique sont refusés à la construction de la politique plutôt qu'annoncés. Le contrôle signé couvre aujourd'hui les agents hébergés par Scrydon ; un Guardian opéré par votre propre organisation exige une signature asymétrique que ce déploiement n'offre pas encore.

Lire les notes de mise en œuvre ACSLe standard lui-même : agentcontrolstandard.org

Le standard est sous licence Apache 2.0 et gouverné par consensus communautaire ; Scrydon en est un implémenteur, pas le propriétaire.

Conformité & preuves

Des contrôles qui correspondent aux cadres dont vous répondez

Les contrôles de Scrydon sont conçus pour correspondre aux cadres réglementaires et d'assurance auxquels les organisations européennes font face, et pour les prendre en charge. La plateforme produit des evidence packs par cadre, afin que vous puissiez démontrer le contrôle lors de vos propres audits et évaluations plutôt que de le reconstituer après coup.
ISO 27001ISO 42001Règlement IARGPD
SOC 2
SecNumCloudDORANIS2
NIST
CRA
AIUC-1

Consultez la vue d'ensemble de la conformité pour le détail de chaque correspondance. Scrydon décrit comment ses contrôles prennent en charge ces cadres et produit des evidence packs ; il ne revendique pas de certification formelle en votre nom.

FAQ

Questions fréquentes

Scrydon envoie-t-il mes données à des fournisseurs d'IA externes ?+
Non — sauf si vous en décidez ainsi. Le recours à des fournisseurs d'IA externes est strictement opt-in. Par défaut, la plateforme peut fonctionner entièrement à l'intérieur de votre périmètre, en air-gap des services de cloud public, et vous choisissez explicitement si et quand un modèle externe est autorisé.
Que signifie concrètement « fail-closed » ici ?+
Cela signifie que le résultat sécurisé est le résultat par défaut. Une identité mTLS invalide est rejetée, un contrôle d'autorisation en échec refuse l'accès plutôt que de l'accorder, et la lecture d'un secret sans habilitation valide échoue sans solution de repli. La sécurité ne dépend pas de quelqu'un qui penserait à l'activer.
Qui peut voir ce qui a été fait, et l'enregistrement peut-il être modifié ?+
Chaque opération privilégiée génère une entrée d'audit immuable et interrogeable, qui capture l'acteur, son adresse IP et l'action, conservée selon votre politique. La piste d'audit est en ajout seul : la trace de ce qui s'est passé ne peut pas être discrètement réécrite.
Scrydon est-il formellement certifié au regard de ces cadres ?+
Non — Scrydon ne revendique pas de certification formelle en votre nom. Ses contrôles sont conçus pour correspondre à des cadres tels qu'ISO 27001, ISO 42001, le règlement IA, le RGPD, SOC 2, SecNumCloud, NIST, le CRA et AIUC-1 et pour les prendre en charge, et la plateforme produit des evidence packs par cadre afin de fluidifier vos propres audits et évaluations. La certification et la conformité s'attachent à votre déploiement spécifique ; reportez-vous aux pages de conformité individuelles pour le détail de chaque correspondance.