EN

L’AUTORISATION AVANT L’EXÉCUTION

Si ce n’est pas autorisé, il n’y a pas d’exécution.

Ironproof vérifie chaque action critique avant son exécution, pas après.

DÉMARRER UN PILOTE VOYEZ-LE DÉCIDER

CE QU’EST IRONPROOF

Un point de contrôle entre votre automatisation et les actions qu’on ne peut pas défaire.

Les agents IA, les API et les scripts peuvent déjà déplacer de l’argent, donner des accès, effacer des données et déployer du code, seuls. Ironproof se place devant ces actions et vérifie chacune contre vos règles avant qu’elle s’exécute.

Autoriséeexécution.

Non autoriséepas d’exécution.

  1. 01

    Vérifié avant, pas journalisé après

    Chaque action attend à la barrière tant qu’elle ne respecte pas votre politique. Aucun modèle de langage ne décide : la même demande, sous la même politique, reçoit toujours la même réponse.

  2. 02

    Prouvé, pas testé

    On ne teste pas vos règles, on les prouve. Vous ressortez avec le cas exact qui les brise, ou la preuve qu’il n’en existe aucun.

  3. 03

    Scellé, vérifiable par tous

    Chaque décision, autorisée ou bloquée, est scellée. Votre auditeur la revérifie sur sa propre machine, sans nous.

VOYEZ-LE DÉCIDER

Quatre types d’action. Une seule barrière.

Choisissez ce que l’agent tente de faire. Chaque demande est vérifiée contre la politique avant de s’exécuter — et chaque décision, autorisée ou bloquée, laisse une trace scellée.

INITIATEUR Agent IA · treasury-ops

ACTION DEMANDÉE

Transfert interne de 30 000 $, après un virement de 35 000 $ plus tôt aujourd’hui

VÉRIFICATIONS DE LA POLITIQUE

  • Transfert sous son propre plafond de 50 000 $
  • Virements + transferts internes du jour sous le plafond combiné de 60 000 $
  • Compte de destination détenu par le même client

Bloquée. Pas d’exécution.

Une règle échoue. L’action ne s’exécute pas, et le refus est scellé avec sa raison.

CE QUE CONTIENT LA TRACE SCELLÉE

  1. 01L’action exacte demandée, et par qui
  2. 02La version de la politique en vigueur
  3. 03Le verdict et la règle qui l’a décidé
  4. 04Deux signatures (Ed25519 + ML-DSA-65), revérifiables hors ligne
VÉRIFIEZ UNE VRAIE TRACE SCELLÉE

Décisions illustratives sous une politique d’exemple.

POURQUOI LA CONNEXION NE SUFFIT PAS

Connecté ne veut pas dire autorisé.

Votre agent a déjà des identifiants. Ça règle qui il est — pas si cette action précise, maintenant, respecte votre politique.

01 · AUTHENTIFICATION — DÉJÀ RÉGLÉE

Qui demande ? Clés, jetons, SSO, comptes de service. Un agent en production l’a déjà passé.

02 · AUTORISATION — LÀ OÙ SE PLACE IRONPROOF

Cette action doit-elle s’exécuter ? Montant, cumuls, approbations, fenêtres de temps, gels — vérifiés avant l’exécution, chaque fois.

Un agent aux identifiants valides et au mauvais plan reste une session valide. Le seul endroit pour l’arrêter, c’est avant l’exécution.

RECHERCHE EN SÉCURITÉ PAR IRONPROOF — CRÉDITÉE PARIBMGnuPGMozillaRed HatwolfSSLVideoLANDCMTK

CE QU’IRONPROOF N’EST PAS

Ni un tableau de bord, ni un garde-fou.

  • Pas de la surveillance

    L’observabilité dit ce qui s’est passé. Ironproof décide avant : action bloquée, pas d’exécution.

  • Pas un garde-fou d’IA

    Aucun modèle de langage dans le chemin de décision. La même demande sous la même politique reçoit toujours le même verdict.

  • Pas un test d’intrusion

    Un test échantillonne des cas. Ironproof prouve une propriété sur toute séquence modélisée — ou rend celle qui la casse.

  • Pas un remplacement de plateforme

    Ironproof ne détient pas de fonds et ne garde pas de clés. Il tourne dans votre environnement, devant les systèmes que vous opérez déjà.

Ce qu’Ironproof est : une barrière déterministe avant l’exécution, une preuve sur la politique, et une trace scellée de chaque décision.

OÙ ÇA S’APPLIQUE

Déplacer de l’argent. Donner un accès.
Supprimer des dossiers. Livrer un changement.

Les actions qu’on ne peut plus reprendre une fois exécutées. Pour celles-là, l’autorisation cesse d’être un réglage et devient une infrastructure.

  • Banque et paiements

    Virements, remboursements et transferts · Changements de bénéficiaire et limites quotidiennes · Paiements en temps réel

    BSIF E-23 · BSIF B-13 · LAPD · programmes LBA

  • Hypothécaire et prêt

    Approbations hors des limites de souscription · Déboursement des fonds · Changements aux coordonnées de versement

    BSIF B-20 · LRPCFAT (secteur hypothécaire, depuis oct. 2024)

  • Assurance

    Approbations automatisées de réclamations · Décisions de souscription · Versements

    BSIF E-23 · ligne directrice de l’AMF sur l’IA

  • Jeu en ligne

    Limites de dépôt et de mise · Versements de gains · Autoexclusion

    Normes du registrateur de la CAJO (Ontario)

  • Gouvernement et défense

    Mises à jour de dossiers officiels · Approbations et dépenses · Accès aux systèmes sensibles

    Orientation du SCT sur l’IA agentique · ITSG-33

  • Santé

    Accès aux dossiers patients · Changements d’ordonnances · Exportations de données

    LPRPS · Loi 25 · LPRPDE

  • Énergie et infrastructures critiques

    Changements de consignes et de configuration · Opérations à distance sur les systèmes de contrôle · Déploiements en production

    IEC 62443 · NERC CIP

Ces cadres disent déjà ce qui ne doit jamais arriver. Ironproof transforme cette phrase en une frontière que le système ne peut pas franchir, et en une preuve que le régulateur peut revérifier.

POURQUOI MAINTENANT

Le code commence à déplacer l’argent tout seul.

Les régulateurs et les banques du Canada y ont mis des dates. Chaque élément renvoie à sa source.

  1. 1er sept. 2026

    EY : 52 % des banques ont piloté l’IA agentique, 16 % seulement ont des cas d’usage pleinement déployés. « Une banque ne peut pas simplement dire qu’un système d’IA est gouverné. Elle doit pouvoir le prouver. » (notre traduction)

    EY, How governed intelligence can scale agentic banking↗

  2. 10 sept. 2026

    Le BSIF affirme que les dépôts tokenisés ne sont pas juridiquement distincts des dépôts traditionnels. Les règles existantes s’y appliquent.

    BSIF, énoncé sur les dépôts tokenisés↗

  3. 22 sept. 2026

    Six banques canadiennes annoncent explorer une solution de dépôts tokenisés en dollars canadiens, pour des paiements plus rapides, plus efficaces et programmables.

    Communiqué conjoint, Newswire↗

  4. 1er mai 2027

    La ligne directrice E-23 du BSIF sur la gestion du risque de modèle entre en vigueur. Sa définition d’un modèle inclut explicitement les méthodes d’IA et d’apprentissage automatique.

    BSIF, ligne directrice E-23↗

Quand un paiement peut se libérer tout seul sur une condition, quelqu’un doit vérifier la condition avant l’exécution.

CE QUE SEULE UNE PREUVE FAIT

Des règles vérifiées une à une — ou la politique entière prouvée.

Une barrière qui vérifie chaque règle contre chaque demande peut toutes les laisser passer alors qu’une suite d’actions conformes brise ce que la politique devait empêcher. Ironproof vérifie la politique comme un tout : il rend la séquence exacte qui la casse, ou la preuve qu’aucune n’existe.

Un test vous dit ce qu’il a essayé. Une preuve vous dit ce qui est impossible.

Prouvé à l’intérieur de la frontière que vous définissez. Le certificat énonce cette frontière.

UNE SEULE BARRIÈRE, PEU IMPORTE QUI DEMANDE

La barrière ne demande pas qui demande.

Elle demande si l’action est à l’intérieur de la politique en vigueur. La même vérification s’applique à tous les chemins qui mènent à un système critique — c’est pourquoi ce n’est pas un problème d’IA qui appelle une réponse d’IA.

Chaque autorisation consigne l’acteur qui demande, la version de la politique et l’action. Rien ne s’exécute sans dépenser un jeton à usage unique lié à cette décision exacte.

COMMENT ÇA MARCHE

Prouver. Appliquer. Sceller. Vérifier.

Ironproof vérifie mathématiquement qu’aucune séquence d’actions atteignable ne peut franchir la frontière d’autorisation définie.

Votre politique écrite est compilée en mathématiques par un compilateur déterministe — le même que celui qu’utilise le runtime. Un contrôle différentiel fait échouer la compilation si les deux divergent.

  1. 01

    Prouver

    Avant le déploiement, Ironproof établit que la politique définie tient sur tout l’espace d’actions modélisé.

  2. 02

    Appliquer

    À l’exécution, chaque action demandée est vérifiée de façon déterministe avant de s’exécuter.

  3. 03

    Sceller

    Chaque décision est scellée au moment de l’exécution — empreinte SHA3-512, double signature Ed25519 + ML-DSA-65 — liant l’action, la version de la politique et le verdict dans un seul artefact.

  4. 04

    Vérifier

    Le certificat est revérifié contre ses entrées scellées : le même verdict doit revenir, sinon le sceau est rompu.

Le théorème qui relie le chemin rapide du runtime au modèle formel complet, et les contrôles d’équivalence derrière lui, sont dans le dossier technique.

VÉRIFIER UNE PREUVE

Vérifiez vous-même une vraie preuve

Chargez un vrai dossier scellé et vérifiez-le ici même — signatures Ed25519 + ML-DSA-65, chaîne SHA3-512, et l’ancrage temporel qui fixe le quand, entièrement dans votre navigateur. Chargez ensuite un dossier altéré et regardez-le se faire rejeter. Aucun tableau de bord, aucun serveur, aucune confiance requise.

IRONPROOF · VÉRIFICATEUR DE SCEAUPRÊT

Tourne entièrement dans votre navigateur — Ed25519 + ML-DSA-65 (FIPS 204) + SHA3-512 en JavaScript pur, sans serveur et sans code Ironproof. Le format est publié, donc n’importe qui peut écrire un second vérificateur : lire la spécification →

LE MÊME MOTEUR

Le même moteur de preuve. Éprouvé sur de vraies vulnérabilités.

Découvertes par Dominik Blainet Cobalt, créditées sur les dépôts des projets eux-mêmes — recherche publiée, CVE assignées et remerciements publics en amont.

CVE-2026-41682
VOIR LE DOSSIER TECHNIQUE

PILOTE PARTENAIRE DE CONCEPTION

Commencez par un seul type d’action.

Un pilote à périmètre fixe sur une seule action que votre automatisation exécute déjà. Vous gardez le certificat, la barrière et les traces scellées.

  1. 01

    Choisir l’action

    Un type d’action que vos agents ou scripts exécutent déjà — un transfert, un accès, une suppression, un déploiement — et les règles qui l’encadrent aujourd’hui.

  2. 02

    Prouver la politique

    Nous encodons les règles, cherchons les séquences qui passent chaque règle mais trahissent l’intention, et prouvons que la politique corrigée tient.

  3. 03

    Appliquer et sceller

    La barrière tourne dans votre environnement, devant l’action. Chaque décision, autorisée ou bloquée, est scellée.

  4. 04

    Vérifier sans nous

    Votre équipe de risque ou votre auditeur revérifie le certificat et les traces sur sa propre machine.

UN BON CANDIDAT SI

  • Un agent, une API ou un script peut déjà exécuter l’action sans qu’une personne clique sur approuver
  • Les règles existent sur papier — limites, approbations, fenêtres, gels
  • Quelqu’un devra montrer que ces règles ont réellement tenu

Chaque action vérifiée. Ce qui est prouvé s’exécute. Le reste, jamais.

Probablement sûr, ce n’est pas
prouvé impossible.

Les agents déplacent déjà de l’argent, donnent des accès et modifient la production, seuls. On vous montre exactement où votre politique casse, ou on prouve qu’elle ne peut pas casser. Ensuite, chaque action est vérifiée avant de s’exécuter : ce qui est autorisé passe, scellé ; pour le reste, pas d’exécution.

DÉMARRER UN PILOTE