Réponses sécurité et due diligence

Monarch est le produit que Galahad déploie : une couche applicative pilotée par une ontologie, qui lit à travers les systèmes qu’une organisation exploite déjà et met chaque écriture en attente d’approbation. Il s’installe dans votre propre infrastructure. Ce seul fait décide de la plupart des réponses ci-dessous, il vient donc en premier.

Où tourne le logiciel

Où tourne le logiciel, et qui l’exploite ?

Sur vos machines, dans votre infrastructure. Monarch s’installe comme un ensemble de conteneurs : le backend applicatif, le frontend, sa base PostgreSQL, un service de sauvegarde de base et un service d’export d’audit. Galahad n’exploite aucun hébergement de données client. L’instance tourne sous vos comptes, vos clés et votre juridiction, et c’est pourquoi l’homologation qui la gouverne est celle qui couvre l’environnement dans lequel vous l’installez.

Le déploiement est-il partagé avec d’autres clients ?

Non. Il est mono-tenant par construction : un déploiement, une ontologie, une base. L’isolation à l’intérieur de ce déploiement s’exprime en finalités avec des column-level grants au niveau de la base, non en politiques de row-level security. Si votre exigence est de séparer deux populations d’enregistrements l’une de l’autre, elle est satisfaite en déclarant deux finalités et en leur accordant des droits différents, et elle est appliquée par PostgreSQL.

Comment l’application est-elle exposée sur le réseau ?

Dans le profil entreprise, TLS termine sur un proxy authentifiant en bordure, avec l’écoute en clair explicitement désactivée et le service publié sur le 443. L’application elle-même se lie au loopback, donc aucun port applicatif ne répond en clair. Le conteneur d’API n’est jamais publié : il n’est joignable que sur le réseau de conteneurs interne, et la base ne publie rien.

Quels tiers se trouvent sur le chemin des données ?

Un seul, et seulement si vous le choisissez : le fournisseur de modèle que vous configurez. Deux autres chemins sortants existent et tous deux sont en opt in. La recherche web est désactivée par défaut. Un service de gestion de clés cloud (KMS) est disponible si vous le préférez à un magasin de clés local, et en mode souverain le builder de provider refuse un KMS cloud avant même qu’un SDK ne soit importé. Rien d’autre dans le système en fonctionnement n’est destinataire de vos données.

Ce qui atteint un modèle externe

Nos données atteignent-elles un fournisseur de modèle externe ?

Dans la configuration par défaut livrée, oui : le fournisseur par défaut est une API externe et elle appelle vers l’extérieur. Le mode souverain est une configuration supportée, et un flag plutôt qu’une posture. Avec les appels de modèle externes coupés dans la configuration de déploiement, la plateforme refuse de construire le moindre client externe. Elle n’acceptera qu’un endpoint loopback, RFC 1918 ou de domaine interne, elle refuse un KMS cloud avant même que la bibliothèque concernée ne soit chargée, et elle maintient la recherche web éteinte. Le choix se fait au déploiement, il est visible dans la configuration, et il est testable depuis votre propre réseau.

Peut-il tourner sans aucune clé de modèle externe ?

Oui. Le socle modèle est agnostique du provider et le déploiement tourne contre n’importe quel endpoint compatible OpenAI, y compris local, sans aucune clé externe présente nulle part dans l’environnement.

Quelles parties du système envoient des données à un modèle, et lesquelles non ?

La surface chat envoie la question et les lignes qu’elle récupère. Le chemin de décision connu n’appelle aucun modèle pendant l’exécution : une transformation de calcul enregistrée émet du SQL sur les tables de base et applique les règles en Python simple. Le seul appel de modèle sur ce chemin est le router qui sélectionne quelle décision exécuter. Sur cette surface, le modèle choisit quel code tourne ; il ne calcule pas les chiffres.

Comment vos données sont lues

Nos données sont-elles copiées hors de nos systèmes ?

Cela dépend du mode d’accès lié à chaque source, et le mode est enregistré par source parce que c’est la première chose qu’un audit demande.

Quels systèmes peuvent être lus en live, sans copie ?

PostgreSQL, à travers son propre foreign data wrapper. Le chemin live va de Postgres à Postgres : le provisionnement fixe ce wrapper, l’API d’administration refuse tout autre type, et le planner lit le catalogue système de la source pour construire la correspondance. Tout ce qui n’est pas PostgreSQL est lu via une copie gérée dans un schéma raw de la base de la plateforme. Installer l’extension foreign data wrapper est une action superuser unique de votre côté, par conception : rien dans le produit ne s’accorde ce privilège.

Une source sensible peut-elle être liée à un mode d’accès faible ?

Non, et le refus a lieu au chargement plutôt qu’à la requête. Une source marquée sensible ne peut être liée qu’à une foreign table live ou à une copie gérée. Liez-la à une intégration grossière d’autorisation ou de refus et le loader refuse la source, de sorte que cette erreur de configuration n’atteint jamais un système en fonctionnement.

Quelle est la fraîcheur d’une source copiée ?

Aussi fraîche que la dernière synchronisation que vous avez lancée. Le rafraîchissement du miroir est planifié par l’opérateur à dessein : la synchronisation est faite pour être pilotée depuis votre propre ordonnanceur et n’est jamais appelée en process par l’agent, et aucun ordonnanceur n’est livré dans le déploiement. Une foreign table live ne pose aucune question de fraîcheur, parce qu’elle lit la source à chaque requête.

Une fois une source mappée, est-elle gouvernée différemment des données internes ?

Non. Une table client mappée est gouvernée à l’identique d’une table native : mêmes finalités, mêmes grants, même audit.

Les documents sont-ils gouvernés comme les enregistrements ?

Oui. Un document peut être servi en texte extrait ou en fichier d’origine, et les deux passent exactement la même barrière qu’une lecture d’enregistrement. Un paquet d’extraction séparé remplit une ontologie existante depuis PDF, DOCX, XLSX et PPTX à travers une barrière de provenance verbatim, de sorte qu’une valeur extraite porte l’endroit d’où elle vient.

Pouvons-nous voir quels systèmes et quelles colonnes alimentent une réponse donnée ?

Une carte de lineage sert un graphe déterministe des sources, connecteurs, tables, objets d’ontologie et de leur usage. Elle est cadrée par PBAC et auditée comme n’importe quelle autre lecture, et elle a un kill switch pour une organisation qui considère la carte du schéma physique elle-même comme sensible.

Ce que l’agent a le droit de faire

Peut-on donner à un agent IA des permissions de base de données plutôt que des restrictions au niveau du prompt ?

C’est la conception même, et c’est la réponse à l’essentiel de ce qui suit. Les permissions effectives sont les permissions que les rôles de l’utilisateur autorisent, intersectées avec les permissions que la finalité active autorise, appliquées de façon redondante à cinq couches : le filtre d’outils, le filtre d’ontologie, le validateur SQL, les grants PostgreSQL et l’audit. La quatrième couche est le plancher non négociable. Il y a un rôle PostgreSQL par finalité, avec des column-level grants, et chaque lecture de données bascule vers ce rôle pour la durée de la transaction, de sorte que l’exécutant n’est jamais le propriétaire de la table. Une lecture sans finalité est routée vers un rôle qui ne détient aucun grant et ne peut pas se connecter, et elle est refusée pour privilège insuffisant. Un test du build échoue sur tout changement de rôle écrit à la main ailleurs, de sorte qu’un nouveau code ne peut pas ouvrir discrètement un second chemin contournant ce plancher.

Comment appliquez-vous techniquement la finalité sous laquelle un système d’IA agit ?

La finalité est ici une primitive de contrôle d’accès, pas un paragraphe dans une politique. Chaque finalité est un rôle PostgreSQL avec ses propres column-level grants, et les permissions que détient un utilisateur sont intersectées avec les permissions de la finalité sous laquelle il agit, de sorte qu’un rôle qui autoriserait une lecture ne suffit pas si la finalité active ne l’autorise pas. Escalader vers une autre finalité à l’intérieur d’une session est un événement enregistré à part entière, non un élargissement silencieux. Quand un DPO demande si la limitation de finalité est appliquée ou seulement déclarée, voici l’application : un grant que PostgreSQL applique, vérifiable en se connectant sous le rôle et en essayant.

Que se passe-t-il si une prompt injection pousse le modèle à tenter une requête qu’il ne devrait pas exécuter ?

Il reçoit une erreur de base de données, pas un refus poli. Sur la surface chat, le modèle écrit du SQL, et c’est dit franchement plutôt que caché : la garde est un contrôle de classe d’instruction sur l’outil, plus la connexion sur laquelle il s’exécute, qui porte les grants de la finalité active et rien d’autre. Une requête hors de ces grants échoue avec une erreur de privilège insuffisant venant de PostgreSQL. Le contrôle ne dépend pas de la bonne conduite du modèle, de la survie du system prompt, ni de la détection d’une instruction injectée.

Quelle est l’identité propre d’un agent, et que peut-il atteindre ?

Un agent est déclaré dans l’ontologie, non invoqué par un prompt. Il est sélectionné de façon déterministe à partir des objets nommés dans une directive, de sorte que le modèle ne choisit pas sa propre limite. Il tourne sous son propre rôle PostgreSQL, doté de l’intersection de sa finalité et de sa spécialité, et une spécialité vide n’accorde rien. Il échoue en refusant : un rôle d’agent manquant ne retombe jamais sur la finalité de l’utilisateur. Et il est borné par défaut plutôt que sur demande : un quota d’appels journalier plus un budget par run sur les appels, les lignes, les écritures et le temps d’horloge. Un agent qui n’en déclare aucun hérite des valeurs par défaut du déploiement, de sorte qu’aucun agent n’est sans bornes par omission. Retirer la borne est un choix explicite que quelqu’un doit faire et consigner, et un quota de zéro bloque l’agent purement et simplement.

Que se passe-t-il quand une permission est refusée en cours de tâche ?

Sur un refus de permission, le chemin de décision connu se dégrade en une lecture assainie plutôt que de faire échouer le tour, et le refus lui-même est écrit dans la piste d’audit. Un refus ferme lève un événement que l’utilisateur peut déposer comme demande d’accès, ce qui veut dire qu’un refus produit une demande gouvernée plutôt qu’un contournement.

Ce qui se tient avant une écriture

La plateforme peut-elle écrire dans nos systèmes de production ?

Seulement là où vous l’activez, et seulement vers une source déclarée inscriptible. Le write-back est désactivé dans le runtime par défaut et s’active par déploiement. Quand il est actif, l’écriture atterrit dans la vraie table de votre propre base, en live et de façon réversible, non dans un jeu de données de write-back séparé que quelqu’un devra réconcilier plus tard, et elle s’exécute sur la même transaction cadrée par les permissions que l’écriture qui l’a déclenchée, jamais sur une connexion à elle.

L’inscriptibilité elle-même est en refus par défaut. Chaque écriture résout sa table cible jusqu’à la source qui la possède, et l’écriture est refusée si cette source n’est pas déclarée inscriptible. Une copie gérée et un cache à durée bornée ne sont jamais inscriptibles, quoi que quiconque déclare, parce qu’une écriture dans une copie est une perte de données silencieuse : elle atterrit dans la copie, la synchronisation suivante l’écrase, et rien ne vous le dit. Une foreign table live n’est écrite que là où elle a été déclarée inscriptible, et une table native à la base de la plateforme n’est pas concernée. Le contrôle s’exécute à chaque écriture, dans chaque profil de déploiement, avant l’ouverture du savepoint, et un refus déclenche un rollback et inscrit une exécution en échec dans la piste, en nommant la source comme étant en lecture seule.

Qu’est-ce qui se tient entre le modèle et une écriture irréversible ?

L’outil d’écriture ne s’exécute jamais en ligne. Une écriture proposée persiste comme approbation en attente, ouvre un savepoint sous la finalité capturée au moment de la proposition, calcule un diff en dry run, et attend. L’approuver la valide, un rollback l’abandonne, une prolongation réinitialise l’attente. La finalité utilisée à l’exécution est celle capturée quand l’écriture a été proposée, de sorte qu’un changement de permissions entre la proposition et l’approbation ne peut pas servir à élargir ce que l’écriture touche.

Que se passe-t-il si personne ne répond à l’approbation à temps ?

L’attente a un délai et il est de cinq minutes. Une prolongation le réinitialise, jusqu’à trois fois. Si le délai passe sans réponse et sans prolongation, le balayage d’expiration prend la branche rollback : le savepoint est annulé, l’approbation en attente est marquée expirée, et rien n’atteint la table cible. L’inaction ne peut pas valider, et elle ne laisse pas non plus de transaction ouverte, donc une proposition bloquée se résout en aucun changement du tout. L’expiration est écrite dans la piste comme un événement à part entière, comme chaque étape du cycle de vie, et la proposition conserve son diff en dry run, de sorte qu’un auditeur lit ce qui a été proposé et confirme que cela n’a jamais été appliqué. Récupérer l’écriture signifie la proposer à nouveau, sous une nouvelle attente.

Les actions sont-elles déclarées, ou le modèle les invente-t-il ?

Déclarées. L’ontologie porte des actions et des fonctions nommées, et en appliquer une émet du SQL paramétré contre la cible à travers le même flux d’approbation et de savepoint. Chacune est conditionnée à la permission pour cette action précise, plus la permission de mutation sur l’objet qu’elle touche. Il n’existe aucun chemin où un modèle compose une écriture inédite et l’exécute.

Un humain valide-t-il avant toute exécution, pas seulement les écritures ?

Oui. Une barrière de plan arrête le tour avant que quoi que ce soit ne s’exécute : le planner annonce son plan, lève un événement plan requis, et rien ne s’exécute tant que l’utilisateur ne l’a pas validé. Des événements distincts couvrent une approbation de mutation, une escalade de finalité en session, et un refus ferme. Quand un déployeur doit démontrer un contrôle humain effectif, c’est le mécanisme à montrer : non une case à cocher dans une page de réglages, mais une exécution qui ne démarre pas.

Ce que prouve la piste d’audit

Comment prouver à un auditeur à quelles données un agent a accédé et qui a approuvé l’action ?

La complétude de l’audit est énoncée comme un contrat plutôt que comme un niveau de log, et trois des choses qu’elle capture sont les trois oublis ordinaires du logging applicatif.

La table elle-même est en ajout seul via un trigger PostgreSQL. Avec la séparation du propriétaire activée, ce qui est le défaut, le serveur refuse de démarrer tant que le runtime possède encore le log d’audit, de sorte que le process qui écrit la piste n’est pas le process qui pourrait l’altérer.

Le log détecte-t-il les altérations, et qu’est-ce que cela veut dire concrètement ?

Chaque ligne d’audit porte un SHA-256 écrit par un trigger d’insertion qui écrase ce que l’appelant a fourni, de sorte qu’un bug applicatif ou une application compromise ne peut pas forger le hash d’une ligne. Des ancres chaînent des plages de lignes entre elles. Une commande de vérification livrée recalcule la chaîne et sort avec un code d’échec en cas d’altération, ce qui fait de la vérification quelque chose que votre propre pipeline exécute sur un planning, plutôt que quelque chose que nous affirmons sur une slide.

Les ancres sortent de la machine, et c’est le défaut plutôt qu’un réglage dont il faut se souvenir. Le produit est livré durci : la piste écrit vers un sink fichier durable, un scellement planifié exporte les ancres des deux chaînes, ce qu’un agent a fait et ce qu’il a regardé, et le serveur refuse de démarrer si l’ancrage ne peut pas être activé. Le sink par défaut est un fichier local, donc un déploiement totalement déconnecté est ancré sans aucune sortie. Pour placer les ancres là où les exploitants de la machine ne peuvent pas les atteindre, pointez-le vers l’un des autres sinks : syslog RFC 5424 sur TLS, un collecteur HTTP, ou un stockage objet avec Object Lock en mode COMPLIANCE, qui refuse un bucket dont le lock n’est pas réel.

Que ne couvre pas la détection d’altération ?

Trois limites, nommées, parce qu’un contrôle dont le bord n’est pas déclaré n’est pas un contrôle.

• La destruction de la machine hôte n’est pas empêchée, elle est rendue indéniable. La chaîne prouve que des lignes manquent. Elle ne les ramène pas. Les ancres hors machine sont ce qui transforme cela en preuve plutôt qu’en trou.
• La rétention vous appartient. La plateforme ne décide pas combien de temps la piste est conservée, et aucune rétention par défaut n’est imposée en votre nom.
• Les hash ne sont pas notariés par un tiers. Il n’y a pas de signature HSM et pas d’horodatage qualifié RFC 3161. La piste détecte les altérations contre l’application et ses exploitants, ce qui est une affirmation différente et plus étroite qu’une affirmation contresignée.

Que se passe-t-il si l’écriture d’audit échoue ?

L’écriture est refusée, et c’est une garantie transactionnelle plutôt qu’un contrôle applicatif. L’enregistrement de commit est inséré sur la connexion propre à la mutation, à l’intérieur de la transaction propre à la mutation, avant le commit. Si cette insertion échoue, la transaction est annulée et rien n’atteint la table cible. Il n’existe aucun état où l’écriture a été validée et où l’enregistrement de la validation ne l’a pas été.

La limite mérite d’être nommée, parce que c’est une décision de conception et non un oubli. Seul l’enregistrement de commit est dans la transaction. Les enregistrements d’exécution et de rollback qui l’entourent sont écrits en best effort, en dehors, délibérément : un rollback abandonne la transaction même à l’intérieur de laquelle son enregistrement devrait être écrit, donc l’y lier voudrait dire qu’un rollback ne laisserait aucune trace du tout. La propriété sur laquelle nous tenir est celle qui gouverne un changement persisté. Une écriture qui a été validée porte toujours son enregistrement de commit, et un enregistrement de cycle de vie qui échoue à s’écrire laisse un trou dans l’histoire d’une écriture, jamais une écriture sans histoire.

Comment rejouer une décision des mois plus tard et obtenir la même réponse ?

Une décision enregistrée stocke ses paramètres plus un enregistrement émis immuable : verdict, règles, codes, périmètre et hash. Elle ne stocke jamais la sortie. La rouvrir re-dérive la décision sous la finalité courante, avec zéro appel de modèle, et signale une divergence de hash quand le résultat a changé, par exemple parce qu’une finalité plus étroite laisse voir moins de constats.

C’est la propriété dont un audit a réellement besoin. Une réponse stockée ne prouve que ce qui a été affiché une fois. Une re-dérivation vous dit si la décision tient encore aujourd’hui, et quand ce n’est pas le cas, elle le dit au lieu de renvoyer discrètement autre chose.

Un agent a écrit de mauvaises données dans un système de production. Comment revenir en arrière et prouver ce qui s’est passé ?

Avant le commit, faire un rollback de la proposition abandonne le savepoint et rien n’atterrit. Après le commit, la piste porte tout le cycle de vie de cette écriture : la proposition, le diff en dry run montré à l’époque, qui l’a approuvée, sous quelle finalité, et quand. Toute correction est elle-même une écriture, elle passe donc par le même chemin de proposition, de diff et d’approbation et atterrit dans la piste à côté de l’originale, ce qui veut dire que la remédiation est aussi documentée que l’erreur.

Déterminisme et risque modèle

La même question donnera-t-elle deux fois la même réponse ?

La réponse honnête a deux moitiés et les deux comptent pour une fonction de risque modèle.

Sur la surface app, des paramètres identiques renvoient des chiffres identiques. Le chemin d’exécution n’appelle aucun modèle et compile son SQL depuis un contrat de retrieval déclaré : le même contrat, la même ontologie et les mêmes paramètres produisent un SQL identique à l’octet près, les valeurs sont liées comme paramètres et jamais interpolées, et un contrôle de conformance vérifie que le SQL émis est égal au contrat. Un validateur relit donc le contrat une fois, plutôt que de relire une requête générée à neuf à chaque run.

La surface chat est stochastique par conception, et le modèle y écrit le SQL. Le router qui sélectionne quelle décision exécuter sur la surface app est lui-même un appel de modèle. Donc « tapez cette phrase, obtenez la même application à chaque fois » n’est pas garanti. « Exécutez cette application avec ces paramètres, obtenez les mêmes chiffres à chaque fois » l’est, et c’est l’affirmation sur laquelle nous tenir.

La réponse est-elle identique à l’octet près entre deux runs ?

Non, et la différence est consignée plutôt que masquée. La charge utile porte un timestamp de génération en wall clock, qui est exclu du hash d’intégrité, de sorte que l’enveloppe diffère tandis que l’enregistrement de décision reste stable. Les constats sont retriés dans le code sur une clé qui n’est pas totale, donc les tableaux de lignes peuvent permuter entre deux runs. Les chiffres ne changent pas.

Identité et accès à la plateforme

Comment les utilisateurs s’authentifient-ils, et cela s’intègre-t-il à notre fournisseur d’identité ?

Quatre chemins sont livrés, chacun sur son propre interrupteur et éteint jusqu’à ce que vous l’activiez : le SSO via un identity-aware proxy, OIDC natif avec PKCE, le provisionnement push SCIM 2.0, et l’authentification multifacteur TOTP native. Le step-up est la partie qui mérite d’être relevée : le MFA est exigé sur toute finalité marquée comme l’exigeant, de sorte que le second facteur est requis quand le travail est sensible, plutôt qu’une seule fois à la porte.

Comment les identifiants sont-ils stockés et comment la force brute est-elle traitée ?

Les mots de passe sont stockés avec bcrypt. Le verrouillage de compte est porté par la base et indexé par compte : cinq tentatives échouées, puis un verrouillage de quinze minutes. Il est persistant, donc il survit à un redémarrage, et les tentatives de devinette du TOTP puisent dans le même compteur au lieu d’obtenir un budget neuf.

Existe-t-il un chemin machine à machine, et un navigateur peut-il appeler l’API directement ?

Une clé d’API machine existe pour l’usage serveur à serveur. Il n’y a pas d’allowlist CORS et aucun middleware CORS n’est monté, et la content security policy restreint la page à appeler sa propre origine, donc il n’existe aucun chemin direct depuis un navigateur vers l’API depuis une autre origine. L’application est same-origin à travers son propre proxy.

Certification, et ce que vous pouvez vérifier vous-mêmes

Quelle certification le produit porte-t-il ?

Nous n’en affirmons aucune, et la raison est architecturale. Monarch tourne dans votre infrastructure, sur vos machines, sous vos clés et votre juridiction. L’homologation qui gouverne le système en fonctionnement est donc celle qui couvre l’environnement dans lequel vous l’installez, et elle vous appartient. Ce que nous mettons devant un évaluateur, c’est le contrôle et son point d’application : le trigger, le grant, le flag, le code de sortie. Chaque réponse de cette page est écrite pour être vérifiée sur une instance en fonctionnement plutôt qu’acceptée sur parole.

Que pouvons-nous vérifier nous-mêmes, avant de signer quoi que ce soit ?

Quatre contrôles, tous exécutables sur votre propre instance, dont aucun ne demande de faire confiance à un document.

1. Exécutez la commande de vérification d’audit contre votre propre piste, puis altérez une ligne et regardez-la échouer.
2. Tentez une lecture sans finalité active et observez une erreur de privilège insuffisant venant de PostgreSQL, non un message venant d’un modèle.
3. Proposez une écriture, lisez le diff en dry run, faites-en un rollback, puis confirmez que la table cible est intacte et que tout le cycle de vie est dans la piste.
4. Restreignez une finalité, rouvrez une décision enregistrée, et regardez le signal de divergence de hash se déclencher.

Une répétition d’un pack de cas d’usage écrit en plus une preuve générée par la machine, consignant l’empreinte du pack, le hash du commit et l’horodatage d’un run vert, de sorte que l’artefact qui dit qu’une instance a réussi est produit par le run lui-même plutôt que tapé après coup.