Governance & Trust · the moat
Autonomy your risk committee can sign off on.
C'est le rempart, et la raison pour laquelle un acheteur réglementé dit oui : une gouvernance prouvée là où se tromper est illégal, adossée à 10 ans en production. VessterOS est la FAÇON dont nous l'appliquons, la manière dont nous faisons tourner des agents de façon auditable et dans le respect de la loi. Portable, à vous de l'exploiter, et prouvée dans les domaines réglementés les plus exigeants, puis appliquée à l'échelle de l'entreprise.
Ce que « gouverné » veut dire vraiment
Four operating disciplines. Each a control you own.
La gouvernance n'est pas un PDF de politique. Dans VessterOS, ce sont quatre disciplines opérationnelles, chacune un contrôle conçu avec un responsable et une piste d'audit, pas une promesse. Chacune est vôtre, à inspecter et à exploiter.
Deux choses qui prennent une décennie à mériter : une discipline de gouvernance prouvée là où se tromper est illégal, et 10 ans à faire tourner de l'IA en production. VessterOS est la façon dont nous appliquons cette discipline à vos processus, un véhicule de livraison que vous possédez et pouvez exploiter en toute indépendance. Les agents, et le runtime, sont à vous, pour de bon.
Certifications & standards
CertifiedThe standards we hold ourselves to.
Autonomie
Les agents gagnent leur autonomie. Ils ne commencent pas avec.
Le défaut dangereux est binaire : soit un humain fait tout, soit l'agent est « lâché dans la nature ». Ni l'un ni l'autre n'est gouvernable. VessterOS fait de l'autonomie une propriété graduée et prouvée : chaque échelon a un seuil d'entrée, un rayon d'impact borné, et un chemin de retour documenté.
- L0ShadowL0L'agent observe
Tourne aux côtés des humains, en proposant mais sans jamais agir. Des évals de référence fixent le seuil de confiance.
Rédige la note de crédit ; un humain écrit celle qui part.
- L1SupervisedL1Humain dans la boucle
N'agit qu'après qu'un humain a approuvé chaque étape. Les humains restent le point de décision.
Prépare le paiement ; un humain clique sur approuver.
- L2GuidedL2Humain sur la boucle
Agit de façon autonome ; les humains surveillent et traitent les exceptions. Le transfert-et-reprise garde l'état intact.
Intègre les clients de bout en bout ; les humains revoient les cas limites signalés.
- L3FullL3Autonome
Tourne de bout en bout dans un rayon d'impact borné et documenté, surveillé par les évals et la détection de dérive.
Rapproche les grands livres pendant la nuit ; les décisions à conséquence exigent toujours une validation.
Les humains passent d'approbateurs à traiteurs d'exceptions à mesure que la confiance se gagne, jamais l'inverse sans motif. Dans les processus réglementés aux plus forts enjeux, l'échelle est plafonnée par la loi : là où une règle réserve la décision à une personne, l'agent s'arrête à l'analyse et le verdict est REQUIRE-HUMAN. L'autonomie est bornée par la responsabilité, par conception.
Le seuil de confiance
Les évals sont l'échafaudage de la confiance, les tests d'intégration du monde des agents.
Challenge
On ne peut pas promouvoir un agent au feeling. « Ça a l'air de marcher » n'est pas un contrôle qu'un régulateur ou un comité des risques accepte.
Why it matters
Chaque mise à jour de modèle, changement de prompt ou nouvelle source de données peut déplacer le comportement en silence. Sans porte mesurée, l'autonomie grimpe sans aucune preuve derrière elle.
How Vesster-OS resolves it
Chaque échelon a une suite d'évals qu'il doit réussir pour y entrer : jeux de données de référence versionnés, seuils de régression, et un EvalReport signé et immuable. Un agent est promu par la preuve ou pas du tout ; la même suite tourne en CI, donc une régression bloque la livraison avant qu'elle ne parte.
Surveillance de la dérive
Un modèle qui a réussi le mois dernier peut échouer ce mois-ci. Nous y veillons.
Challenge
Les agents agissent sur un contexte vivant et dépendent de modèles qui changent sous vous. La preuve d'hier expire.
Why it matters
Une dérive silencieuse dans un agent en production est la façon dont un processus « de confiance » se met discrètement à prendre les mauvaises décisions, le mode de défaillance qu'un comité des risques redoute le plus.
How Vesster-OS resolves it
VessterOS surveille en continu la dérive de distribution, de coût et de qualité à partir des traces de production ; une alerte de dérive peut automatiquement faire descendre un agent d'un échelon vers un cran plus sûr et le router vers un humain jusqu'à ce qu'il se requalifie. La confiance est continue, pas une certification ponctuelle.
Transfert-et-reprise
Quand un agent atteint le bord de sa politique, il transfère, sans casser le processus.
Challenge
La plupart des automatisations échouent sur l'exception : elles bloquent, ou foncent à travers un cas qu'elles ne devraient pas toucher.
Why it matters
Dans un processus réglementé, l'exception EST le risque. La façon dont le système se comporte à sa propre frontière, c'est tout l'enjeu.
How Vesster-OS resolves it
Sur une exception hors politique, l'agent crée un point de transfert durable, délègue à un humain avec tout le contexte, et reprend le workflow exact quand l'humain répond : aucun cas orphelin, aucun état perdu. L'exécution durable signifie qu'un plantage rejoue de façon déterministe là où il s'est arrêté.
Le coupe-circuit
Révocable par conception, et journalisé pour toujours.
Challenge
« Autonome » n'est sûr que si vous pouvez l'arrêter, instantanément, et prouver après coup exactement ce qui s'est passé.
Why it matters
Un bouton d'arrêt que personne n'a testé, et des dérogations que personne n'a journalisées, c'est du théâtre. Les règles de résilience opérationnelle attendent un contrôle réel et éprouvé.
How Vesster-OS resolves it
Un coupe-circuit testé rétrograde un agent à bloqué à la demande ; le réarmement exige deux opérateurs (quatre yeux). Chaque dérogation humaine est écrite dans un journal signé en ajout seul (qui, quand, pourquoi, et l'état avant), et l'exercice du coupe-circuit est documenté et répété.
Sécurité
Chaque entrée est traitée comme contrôlée par un adversaire.
Une défense robuste est architecturale, pas un modèle mieux entraîné. Un modèle plus fort abaisse les chances d'une attaque réussie ; il n'en supprime jamais la possibilité. Une architecture correcte supprime la possibilité par conception, et c'est la seule affirmation qu'un RSSI devrait accepter.
Untrusted input
doc · message · payload
Defense-in-depth · 4 independent layers
- 01
Spotlighting
delimits & encodes input as data
- 02
CaMeL isolation
quarantined reader can't act
- 03
Detection guardrails
injection & insecure-code checks
- 04
Policy / PDP
policy-as-code decision point
Governed action
tool call · under policy
Le modèle de menace
Le document est le vecteur d'attaque.
Challenge
L'injection de prompt indirecte (instructions cachées en texte blanc, dans les métadonnées, les couches d'image, les champs de formulaire) et l'empoisonnement de mémoire transforment une entrée ordinaire en une commande visant le modèle, pas l'humain.
Why it matters
Donnez à un agent des outils et de l'autonomie, et une injection réussie signifie exfiltration de données ou décision manipulée : un « aucune fraude trouvée » forcé, un paiement qui ne devrait pas passer. C'est la première question sérieuse qu'un RSSI pose.
How Vesster-OS resolves it
Nous nommons le modèle de menace par écrit et concevons l'architecture contre lui, en utilisant le Top 10 OWASP pour les applications agentiques (ASI01-10) comme taxonomie, associé point par point à un contrôle nommé (ci-dessous).
Frontière de contamination
Un document empoisonné ne peut pas détourner votre agent.
Challenge
Si un contenu non fiable peut influencer ce que fait l'agent, pas seulement ce qu'il lit, chaque entrée est un exploit potentiel.
Why it matters
C'est l'unique frontière qui sépare une démo d'un système que vous pouvez présenter à un régulateur.
How Vesster-OS resolves it
Un invariant non négociable : les valeurs dérivées de données non fiables ne deviennent jamais arguments d'un outil privilégié sans passer par la politique. La contamination se propage à travers le flux de données ; au moindre doute, le système échoue en position fermée : mise en quarantaine et escalade, jamais une autorisation silencieuse.
Dual-LLM (CaMeL)
Le composant qui lit du contenu non fiable ne peut jamais agir dessus.
Challenge
Un modèle unique qui lit à la fois le document et appelle les outils est à une injection d'agir sur des instructions d'attaquant.
Why it matters
Séparer les rôles est ce qui rend la frontière de contamination réelle plutôt qu'aspirée.
How Vesster-OS resolves it
Le motif CaMeL (Google DeepMind / ETH Zurich) sépare les rôles : un planificateur privilégié (P-LLM) planifie et appelle les outils sur des instructions fiables uniquement ; un lecteur en quarantaine (Q-LLM) traite le contenu non fiable et ne détient aucun outil. Même un document malveillant peut remplir des valeurs de données ; il ne peut jamais changer le plan. Coût publié : ~7 points de pourcentage d'utilité d'achèvement de tâche sur le benchmark AgentDojo, un prix modeste et mesuré pour une garantie structurelle. (C'est le chiffre de la recherche ; sur un projet réel, nous mesurons et rapportons notre propre taux sur vos entrées.)
Défense en profondeur
Aucun contrôle isolé n'est jugé capable de tenir seul.
Challenge
N'importe quelle couche isolée, un détecteur, un filtre d'entrée, finira par être contournée.
Why it matters
Miser le système sur une seule garde astucieuse, c'est ainsi que les brèches surviennent.
How Vesster-OS resolves it
Quatre couches indépendantes : spotlighting (marquer l'entrée non fiable) → isolation CaMeL → garde-fous de détection (injection de prompt, code non sécurisé, contrôles d'alignement) → un point de décision de politique qui rend chaque verdict autoriser/refuser. Le spotlighting réduit la surface d'attaque ; il ne l'élimine pas, raison précise pour laquelle il n'est jamais l'unique couche.
Identité non humaine
Un identifiant d'agent volé ne vaut rien.
Challenge
Les identifiants de service statiques et largement portés sont le butin classique du mouvement latéral.
Why it matters
Un agent compromis ne doit jamais pouvoir dépasser son périmètre minimal.
How Vesster-OS resolves it
Chaque agent tourne sous sa propre identité éphémère et à moindre privilège, rien de statique à voler, avec des capacités d'outil typées explicites, une exécution en bac à sable, et une liste d'autorisation de sortie. Aucun canal de sortie n'est contrôlable par des données non fiables.
OWASP Agentic Security InitiativeAll 10 threats, each mapped to a named architectural control
| ASI | Threat | Architectural control |
|---|---|---|
| ASI01 | Manipulation de prompt / d'objectif | CaMeL + spotlighting |
| ASI02 | Détournement d'outil | Capacités typées + PDP |
| ASI03 | Compromission de privilège | Moindre privilège + identifiants éphémères |
| ASI04 | Ressources / DoS | Quotas + délais d'expiration |
| ASI05 | Empoisonnement de mémoire | Écritures mémoire étiquetées par provenance |
| ASI06 | Cascade multi-agents | Politique par saut |
| ASI07 | Tromperie / désalignement | Contrôles d'alignement |
| ASI08 | Sortie non sécurisée | Bouclier de code avant exécution |
| ASI09 | Identité / usurpation | Identité non humaine |
| ASI10 | Exfiltration | Liste d'autorisation de sortie |
Contexte et accès
Les agents ne valent que le contexte qu'ils peuvent atteindre.
C'est la faille que l'histoire « il suffit de construire un agent » saute. Un agent sur un ordinateur portable n'atteint rien de ce qui fait tourner votre organisation. Le rendre utile, et sûr, signifie lui donner un accès gouverné à vos systèmes, vos documents et vos équipes, sans lui remettre les clés de tout. Cette couche est un livrable d'ingénierie, et c'est celle que les concurrents laissent inachevée.
La couche manquante
La couche d'interopérabilité doit être construite. Elle n'est pas sur étagère.
Challenge
Votre réalité s'étend sur des systèmes centraux, des documents non structurés, et des décisions humaines qui ne vivent dans l'API de personne.
Why it matters
Sans une couche qui couvre les trois, un agent soit ne peut pas agir, soit agit à l'aveugle, et ni l'un ni l'autre n'est de la production.
How Vesster-OS resolves it
Des équipes déployées chez vous construisent un contexte prêt pour les agents sur vos processus réels : une ingestion qui normalise les entrées multicanal, des adaptateurs typés vers vos systèmes, et une orchestration durable qui garde les personnes dans la boucle là où elles doivent l'être. La couche est vôtre, documentée, et portable.
Frontière d'identité
Moindre privilège, par agent. L'accès est accordé, jamais présumé.
Challenge
La voie rapide est de donner à l'agent un identifiant partagé puissant. C'est aussi la voie par laquelle une seule compromission devient une brèche.
Why it matters
Un agent qui s'étend à travers vos systèmes est une nouvelle catégorie d'initié, à moins que son accès ne soit borné et attribuable.
How Vesster-OS resolves it
Chaque agent obtient sa propre identité éphémère et à moindre privilège et une carte explicite des outils qu'il peut invoquer (liste d'autorisation). L'accès est typé, délimité et révocable, et chaque action est attribuable à une identité d'agent précise dans la piste d'audit.
Capacités typées
Un agent ne peut appeler que ce qui lui a été explicitement remis.
Challenge
« L'agent peut utiliser n'importe quel outil » est commode en démo et inacceptable en production.
Why it matters
L'accès incontrôlé aux outils (OWASP ASI02) est l'un des principaux risques agentiques : la différence entre un acteur borné et un acteur non gouverné.
How Vesster-OS resolves it
Chaque outil déclare une capacité typée : action, arguments, périmètre, et un identifiant éphémère. L'agent n'invoque que les capacités qui lui ont été accordées ; un point de décision de politique autorise chaque appel privilégié avant son exécution.
Frontière de données et de sensibilité
Les données sensibles sont classées avant de circuler. Et le plus souvent, elles ne circulent pas.
Challenge
Atteindre le contexte signifie toucher des données réglementées et personnelles. Où ces données ont le droit d'aller est une question juridique, pas une question de commodité.
Why it matters
Un seul chemin de données négligent transforme un agent utile en incident de conformité.
How Vesster-OS resolves it
Un classificateur de sensibilité étiquette les données à l'ingestion (fail-closed, sur site par défaut) ; l'étiquette les route. Les données réglementées et personnelles restent dans votre périmètre ; seules les charges non sensibles peuvent atteindre un modèle en région UE, et seulement si vous l'autorisez. La provenance voyage avec chaque valeur, pour que la piste d'audit sache toujours d'où le contexte vient.
Conformité et souveraineté
Une conformité que vous pouvez exécuter, et une souveraineté que vous pouvez prouver.
Ici, la conformité n'est pas un document que l'on classe. C'est une couche qui tourne. Chaque obligation est un contrôle testable, versionné et signé qui émet un verdict lisible par machine auquel le workflow doit obéir. Votre équipe conformité possède les règles et peut le prouver.
Toutes les conditions sont satisfaites, l'agent poursuit sans intervention humaine.
Partiellement remplies, poursuit sous contraintes documentées (journalisation, revue, périmètre).
Une condition dure échoue, la transaction est bloquée. Aucune voie d'exception.
Le poids réglementaire ne peut être délégué, un humain décide ; l'agent ne fait qu'analyser.
La politique que votre équipe possède
Votre équipe conformité possède les règles, et peut le prouver.
Challenge
Quand les règles sont enfouies dans le code applicatif, la conformité ne peut ni les inspecter, ni les changer, ni les attester. Elle s'en remet à la parole de l'ingénierie.
Why it matters
Une règle que personne hors de l'équipe de dev ne peut lire ou signer n'est pas un contrôle qu'un régulateur crédite.
How Vesster-OS resolves it
Politique-comme-code : les obligations sont des règles déclaratives, versionnées, testables, cryptographiquement signées, et approuvées avant déploiement. Le mécanisme est proprement séparé de la décision : le workflow applique ; la politique décide. Les politiques expirent par TTL, pour que l'obsolescence soit visible et que chaque règle soit re-revue selon un calendrier.
La piste de preuves
Chaque décision laisse un enregistrement qu'un régulateur peut inspecter.
Challenge
« Faites-nous confiance, c'était journalisé » n'est pas une preuve. Des journaux modifiables ne prouvent rien.
Why it matters
Les règles de résilience opérationnelle et d'IA à haut risque attendent une traçabilité démontrable et infalsifiable, pas une reconstruction après coup.
How Vesster-OS resolves it
Une piste de preuves en ajout seul, chaînée par hachage (Merkle) sur un stockage WORM, écrite avant que la décision ne s'engage. Pas de stockage de preuves, pas de décision : elle échoue en position fermée. Les dérogations humaines, les transferts et les événements de coupe-circuit font partie de la même piste : qui, quand, pourquoi, et l'état avant.
L'horizon réglementaire
Conçu pour les règles qui arrivent, pas seulement celles déjà là.
Challenge
Le régime est une cible mouvante : EU AI Act, règles de résilience opérationnelle, droit à l'explication, résidence des données, RGPD.
Why it matters
Une stack conforme aujourd'hui et rigide demain est un passif avec un minuteur. Et « nous serons conformes en 2027 » vous disqualifie auprès d'un acheteur sérieux.
How Vesster-OS resolves it
Prêt pour l'AI Act par conception, dès à présent. VessterOS est bâti selon l'ISO 42001 (le système d'exploitation de gestion de l'IA) par conception, sur des fondations certifiées ISO 27001/27017/27018, avec supervision humaine, autonomie graduée, journalisation et documentation technique prêtes dès aujourd'hui. Pour les services financiers, la posture de résilience opérationnelle (contrôles tiers de type DORA, plans de sortie testés, registre de preuves) est intégrée : preuve de profondeur, appliquée à l'échelle de l'entreprise.
Résidence des données et déploiement partout
Vos données ne quittent jamais vos murs.
Challenge
Une banque soumise à des règles de résidence a besoin d'un déploiement fondamentalement différent d'un hôpital. Le sur étagère ne passe jamais la revue.
Why it matters
Où les données tournent est souvent l'unique condition qui décide si un projet est même légal.
How Vesster-OS resolves it
Le déploiement est routé selon la souveraineté des données et adapté à votre régime : les données réglementées et personnelles restent dans votre périmètre ; seules les charges non sensibles peuvent atteindre un modèle en région UE, si vous l'autorisez. Déployez dans votre VPC, sur site, ou entièrement isolé du réseau, indépendant du fournisseur (Anthropic / Mistral / open-source sur vos propres GPU), pour que le choix du modèle ne dicte jamais où vivent vos données.
Anti-lock-in
Anti-enfermement, la réassurance, pas la fiche technique
La raison de dire oui avec confiance : chaque partie de la stack, nous compris, est remplaçable sans réécrire la fondation. La portabilité est une contrainte d'ingénierie que nous nous imposons en tant que tiers au regard des règles de vos régulateurs.
What you own
Ce que VessterOS vous laisse, c'est un actif que vous possédez et exploitez.
VessterOS est la façon dont nous livrons la gouvernance ; le projet vous laisse un actif sous votre contrôle, pour que votre feuille de route continue d'avancer quand nous partons, portable, ouvert, et prêt à la sortie par contrat.
Pourquoi maintenant
Two clocks are already running.
Clock 01
L'horloge réglementaire
L'article 4 de l'EU AI Act est en vigueur : depuis le 2 février 2025, chaque organisation qui déploie de l'IA doit s'assurer que ses opérateurs disposent d'une littératie en IA suffisante ; les autorités nationales ont commencé à en assurer la surveillance à partir d'août 2025. L'adoption gouvernée est une obligation légale au présent, en vigueur dès à présent.
Clock 02
L'horloge de la concurrence et des coûts
Le cimetière des pilotes se remplit : le BCG constate que ~60 % des entreprises ne tirent aucune valeur de l'IA, et Thoughtworks projette ~40 % des projets agentiques annulés d'ici 2027. Chaque mois de retard est un mois de coût sans retour en production, tandis que les concurrents qui gouvernent leurs agents jusqu'en production creusent leur avance.
Les questions qu'un comité des risques pose vraiment
What a risk committee actually asks.
Quatre objections qu'un acheteur sérieux apporte à la gouvernance. Des réponses directes, sans théâtre.
01« Notre gouvernance IT couvre déjà cela. »
Elle couvre du logiciel déterministe. Les agents sont probabilistes et dérivent à chaque mise à jour de modèle : replaquer un contrôle des changements conçu pour du code figé sur quelque chose qui change chaque jour ne tient pas. VessterOS est une gouvernance conçue pour les agents : autonomie graduée, évals comme seuil de confiance, surveillance de la dérive, et conformité comme politique exécutable, conçue pour des systèmes probabilistes, pas tordue pour s'y adapter.
02« Comment un comité des risques valide-t-il une boîte noire ? »
Ce n'est pas une boîte noire pour votre comité. Chaque décision d'agent laisse une piste de preuves en ajout seul, chaînée par hachage, écrite avant que la décision ne s'engage : pas de preuve, pas de décision. La politique est du code que votre équipe conformité possède, versionne et signe. Et les décisions à fortes conséquences se résolvent en REQUIRE-HUMAN par politique : l'agent analyse, un humain décide. Le comité valide un contrôle documenté et testable, pas une promesse.
03« Où vont réellement nos données ? »
Là où vous le décidez. Le déploiement est routé selon la souveraineté des données : les données réglementées et personnelles restent dans votre périmètre ; seules les charges non sensibles peuvent atteindre un modèle en région UE, et seulement si vous l'autorisez. Déployez dans votre VPC, sur site, ou entièrement isolé du réseau. Vos données ne quittent jamais vos murs : c'est une architecture, pas un réglage.
04« Ne sommes-nous pas simplement en train de nous enfermer chez vous ? »
Non, et c'est dans le contrat. Indépendant du fournisseur par conception (3+ options de passerelle documentées avant la mise en service), source et poids sous séquestre, un plan de sortie documenté et testé, et chaque composant substituable. Nous nous tenons à être un tiers remplaçable au regard des règles de vos régulateurs. Vous possédez le runtime et les agents ; votre feuille de route continue d'avancer quand nous partons.
The moat, applied