◆ Pour le RSSI qui signe

Vos agents proposent. Votre politique autorise.
Rien d’autre ne passe.

Le déploiement attend votre signature. L’agent, lui, ne détient aucun secret, et tout ce qui passe laisse un reçu signé.

Réservez 30 min de revue →Lisez la spécification ouverte
01Proposer. Une action, c’est d’abord une proposition signée. L’agent ne détient aucun secret.02Autoriser. Votre politique signée tranche en quelques millisecondes : autorisée, mise en attente ou refusée.03Exécuter. Ce qui a été autorisé, ZIFFER l’exécute lui-même, avec son propre identifiant.04Prouver. Rien ne s’exécute sans laisser un reçu signé, ancré à l’extérieur.05Distribuer. Les règles sont signées hors ligne. Nous-mêmes ne pouvons pas les réécrire.

◆ Pour le RSSI qui signe

Vos agents proposent. Votre politique autorise. Rien d’autre ne passe.

Le déploiement attend votre signature. L’agent, lui, ne détient aucun secret, et tout ce qui passe laisse un reçu signé.

Réservez 30 min de revue →Lisez la spécification ouverte
01Proposer. Une action, c’est d’abord une proposition signée. L’agent ne détient aucun secret.02Autoriser. Votre politique signée tranche en quelques millisecondes : autorisée, mise en attente ou refusée.03Exécuter. Ce qui a été autorisé, ZIFFER l’exécute lui-même, avec son propre identifiant.04Prouver. Rien ne s’exécute sans laisser un reçu signé, ancré à l’extérieur.05Distribuer. Les règles sont signées hors ligne. Nous-mêmes ne pouvons pas les réécrire.

Le dossier finira sur votre bureau. Ceux qui déploient des agents traitent ce risque.

8,5 %des injections indirectes aboutissent malgré tout contre le modèle le plus résistant mesuré à ce jour, en 15 tentatives
97 %des organisations compromises lors d’un incident lié à l’IA n’avaient pas de contrôles d’accès adaptés à l’IA

8,5 % : OpenAI, GPT-6 Astra system card, 2026-09-03, n = 1 810 attaques, 15 tentatives. 97 % : IBM, Cost of a Data Breach 2025, n = 600 organisations, sur les 13 % ayant déclaré une compromission liée à l’IA. Graphique : McKinsey, enquête mondiale « The state of AI in 2026: On the road to ROI », n = 1 719, mai-juin 2026 (Exhibit 15).

Part des répondants travaillant à atténuer chaque risque lié à l’IA, en %

Les plus performants en IATous les autres
L’écart ne se creuse que là où il est question de l’autorité de l’agent. Sur les risques devenus ordinaires, il n’y en a aucun.

Le dossier finira sur votre bureau. Ceux qui déploient des agents traitent ce risque.

8,5 %des injections indirectes aboutissent malgré tout contre le modèle le plus résistant mesuré à ce jour, en 15 tentatives
97 %des organisations compromises lors d’un incident lié à l’IA n’avaient pas de contrôles d’accès adaptés à l’IA

Part des répondants travaillant à atténuer chaque risque lié à l’IA, en %

Les plus performants en IATous les autres
L’écart ne se creuse que là où il est question de l’autorité de l’agent. Sur les risques devenus ordinaires, il n’y en a aucun.

8,5 % : OpenAI, GPT-6 Astra system card, 2026-09-03, n = 1 810 attaques, 15 tentatives. 97 % : IBM, Cost of a Data Breach 2025, n = 600 organisations, sur les 13 % ayant déclaré une compromission liée à l’IA. Graphique : McKinsey, enquête mondiale « The state of AI in 2026: On the road to ROI », n = 1 719, mai-juin 2026 (Exhibit 15).

Aucun système probabiliste ne descend à zéro.

Vos agents lisent e-mails, tickets et documents hors de votre contrôle. Une phrase glissée là devient une consigne.

Supposez l’injection réussie. Trompé dans 2 % des cas ou à tous les coups, le modèle bute sur la même règle.

via un e-mail qu’il résumeUn texte invisible demande à l’agent de faire suivre ce qu’il atteint. Les données sortent de chez vous. Refusé : aucune règle n’autorise cet envoi.
via un ticket qu’il litUn ticket piégé devient une écriture destructrice en production : l’agent tenait l’identifiant. En attente : quorum 2 sur 2, non atteint.
via un document qu’il récupèreUne page récupérée détourne un virement vers un nouveau bénéficiaire. Aucune trace de qui l’a autorisé : personne. En attente de deux personnes nommées.

Un e-mail, un ticket, un PDF, une page web : qui place du texte sous les yeux d’un agent agit avec ses identifiants. Les descriptions d’outils sont le canal qui progresse le plus vite. OWASP LLM01:2025 : aucune parade infaillible à l’injection de prompt n’est connue. UK NCSC, 2025-12-10 : la faille ne se refermera peut-être jamais comme l’a fait l’injection SQL.

Aucun système probabiliste ne descend à zéro.

Vos agents lisent e-mails, tickets et documents hors de votre contrôle. Une phrase glissée là devient une consigne.

Supposez l’injection réussie. Trompé dans 2 % des cas ou à tous les coups, le modèle bute sur la même règle.

via un e-mail qu’il résumeUn texte invisible demande à l’agent de faire suivre ce qu’il atteint. Les données sortent de chez vous. Refusé : aucune règle n’autorise cet envoi.
via un ticket qu’il litUn ticket piégé devient une écriture destructrice en production : l’agent tenait l’identifiant. En attente : quorum 2 sur 2, non atteint.
via un document qu’il récupèreUne page récupérée détourne un virement vers un nouveau bénéficiaire. Aucune trace de qui l’a autorisé : personne. En attente de deux personnes nommées.

Un e-mail, un ticket, un PDF, une page web : qui place du texte sous les yeux d’un agent agit avec ses identifiants. Les descriptions d’outils sont le canal qui progresse le plus vite. OWASP LLM01:2025 : aucune parade infaillible à l’injection de prompt n’est connue. UK NCSC, 2025-12-10 : la faille ne se refermera peut-être jamais comme l’a fait l’injection SQL.

La plateforme

L’autorisation des agents, placée entre eux et tout ce qu’ils touchent.

Nous ne filtrons aucun prompt. Un agent manipulé de bout en bout ne change toujours rien : il ne détient rien.

01 · Côté agent

Toute action commence par une proposition. L’agent ne détient qu’une clé ZIFFER : de quoi demander, pas de quoi agir. La demande prend la forme d’une proposition structurée, dans un catalogue que vous définissez.

  • Via MCP, votre catalogue est l’outillage de l’agent. Hors catalogue, une action ne peut même pas se formuler.
  • Sinon un appel SDK, ou du simple HTTPS. Ni votre agent, ni votre modèle, ni vos prompts ne bougent.
  • Le moindre privilège, prouvé par l’absence : dans l’agent, votre auditeur n’a aucun identifiant à examiner

02 · Le produit

C’est votre politique signée qui décide. La règle autorise, l’exception met en attente : la vitesse de la machine pour le courant, deux personnes nommées pour l’irréversible.

  • Autorisée en quelques millisecondes dès lors que vos règles disent LOW
  • Mise en attente d’un quorum quand elles disent HIGH : double validation, chaque approbateur signant les octets exacts qui s’exécuteront. Ici, qui ne dit mot ne consent pas.
  • Refusée par défaut faute de règle. L’inconnu n’est jamais LOW.

03 · Mise en application

Seule une action autorisée s’exécute. ZIFFER réémet l’intention sous son propre identifiant : il n’y a pas de chemin à côté.

  • Vos systèmes n’acceptent une action que depuis l’identité de ZIFFER : un identifiant à portée limitée par système, une pile CloudFormation à déployer, et c’est tout.
  • Un contrôle d’accès que votre auditeur peut éprouver lui-même : qu’il rejoue le même appel en contournant ZIFFER, il échouera
  • Ce qui a été autorisé est exactement ce qui s’exécute : recalculé au moment de l’exécution, jamais repris du message sur parole.

04 · Preuves

Un reçu signé pour tout ce qui s’exécute. Un registre en ajout seul, ancré à l’extérieur avant qu’une action irréversible ne parte.

  • Signatures hybrides post-quantiques (Ed25519 + ML-DSA-65)
  • Personne ne réécrit l’historique : ni nous, ni votre propre administrateur
  • Une non-répudiation que votre auditeur vérifie avec un CLI public, sans jamais accéder à votre production

05 · La chaîne de publication des règles

Les règles se signent hors ligne. Publier, c’est une cérémonie de signature, jamais un bouton Enregistrer. Même entièrement compromis, ZIFFER ne pourrait pas les réécrire.

  • Aucun composant en exécution ne détient de clé capable de produire une signature de politique valide : sur ce chemin, il n’y a rien à voler.
  • Le moteur de politique, le KMS et l’exécuteur vérifient le bundle chacun de son côté, à chaque lecture : recevoir la politique d’un pair, ce serait simplement faire confiance à ce pair.
  • Gestion des changements signée : l’époque ne peut que croître ; revenir aux règles plus souples d’hier est refusé

La plateforme

L’autorisation des agents, placée entre eux et tout ce qu’ils touchent.

Nous ne filtrons aucun prompt. Un agent manipulé ne change rien : il ne détient rien.

01 · Côté agent

Toute action commence par une proposition. L’agent ne détient qu’une clé ZIFFER : de quoi demander, pas de quoi agir.

  • Via MCP, votre catalogue est l’outillage de l’agent. Hors catalogue, une action ne peut même pas se formuler.
  • Sinon un appel SDK, ou du simple HTTPS. Ni votre agent, ni votre modèle, ni vos prompts ne bougent.
  • Le moindre privilège, prouvé par l’absence : dans l’agent, votre auditeur n’a aucun identifiant à examiner

02 · Le produit

C’est votre politique signée qui décide. La règle autorise, l’exception met en attente : la vitesse de la machine pour le courant, deux personnes nommées pour l’irréversible.

  • Autorisée en quelques millisecondes dès lors que vos règles disent LOW
  • Mise en attente d’un quorum quand elles disent HIGH : double validation, chaque approbateur signant les octets exacts qui s’exécuteront. Ici, qui ne dit mot ne consent pas.
  • Refusée par défaut faute de règle. L’inconnu n’est jamais LOW.

03 · Mise en application

Seule une action autorisée s’exécute. ZIFFER réémet l’intention sous son propre identifiant : il n’y a pas de chemin à côté.

  • Vos systèmes n’acceptent une action que depuis l’identité de ZIFFER : un identifiant à portée limitée par système, une pile CloudFormation à déployer, et c’est tout.
  • Un contrôle d’accès que votre auditeur peut éprouver lui-même : qu’il rejoue le même appel en contournant ZIFFER, il échouera
  • Ce qui a été autorisé est exactement ce qui s’exécute : recalculé au moment de l’exécution, jamais repris du message sur parole.

04 · Preuves

Un reçu signé pour tout ce qui s’exécute. Un registre en ajout seul, ancré à l’extérieur.

  • Signatures hybrides post-quantiques (Ed25519 + ML-DSA-65)
  • Personne ne réécrit l’historique : ni nous, ni votre propre administrateur
  • Une non-répudiation que votre auditeur vérifie avec un CLI public, sans jamais accéder à votre production

05 · La publication des règles

Les règles se signent hors ligne. Publier, c’est une cérémonie de signature, jamais un bouton Enregistrer.

  • Aucun composant en exécution ne détient de clé capable de produire une signature de politique valide : sur ce chemin, il n’y a rien à voler.
  • Le moteur de politique, le KMS et l’exécuteur vérifient le bundle chacun de son côté, à chaque lecture : recevoir la politique d’un pair, ce serait simplement faire confiance à ce pair.
  • Gestion des changements signée : l’époque ne peut que croître ; revenir aux règles plus souples d’hier est refusé

◆ Ce que vous remettez à l’auditeur

Une action, une ligne. La reproductibilité, c’est la provenance des résultats. Ici, c’est celle des actions.

◆ Ce que vous remettez à l’auditeur

Une action, une ligne. La reproductibilité, c’est la provenance des résultats. Ici, c’est celle des actions.

Avant de signer

Six propriétés. Quatre adossées à une clause publiée, deux par construction.

Aucun secret dans l’agent

Ni coffre-fort, ni intermédiaire, ni secret éphémère : l’agent n’en manipule aucun. Rien qui puisse fuir dans une fenêtre de contexte.

Impossible à contourner, pas seulement surveillé

Vos systèmes n’acceptent une action que depuis l’identité de ZIFFER. Contourner ZIFFER ne fait pas sonner une alarme : on n’arrive nulle part.

Refus par défaut8.4-3 · P-4

Sans règle, une action est refusée, jamais évaluée. Un risque inconnu n’est jamais LOW.

Un consentement explicite et opposableAC-3(2)

Double validation : le quorum, ce sont deux personnes nommées, qui signent chacune les octets exacts destinés à s’exécuter. Nul n’approuve sa propre proposition.

Des reçus, pas des journauxAU-10 · AU-3

Chaque action porte un reçu signé par le KMS, qui lie l’action, les règles qui l’ont évaluée et les personnes qui l’ont signée.

Un historique que personne ne réécritAU-9(3)

Registre en ajout seul, ancré à l’extérieur avant qu’une action irréversible ne parte.

Les identifiants de clause ne sont pas décoratifs. ZIFFER met en œuvre une spécification ouverte, et chaque affirmation se rejoue chez vous : ./tools/verify.sh --suites

Avant de signer

Six propriétés. Quatre adossées à une clause publiée, deux par construction.

Aucun secret dans l’agent

Ni coffre-fort, ni intermédiaire, ni secret éphémère : l’agent n’en manipule aucun. Rien qui puisse fuir dans une fenêtre de contexte.

Impossible à contourner, pas seulement surveillé

Vos systèmes n’acceptent une action que depuis l’identité de ZIFFER. Contourner ZIFFER ne fait pas sonner une alarme : on n’arrive nulle part.

Refus par défaut8.4-3 · P-4

Sans règle, une action est refusée, jamais évaluée. Un risque inconnu n’est jamais LOW.

Un consentement explicite et opposableAC-3(2)

Double validation : le quorum, ce sont deux personnes nommées, qui signent chacune les octets exacts destinés à s’exécuter. Nul n’approuve sa propre proposition.

Des reçus, pas des journauxAU-10 · AU-3

Chaque action porte un reçu signé par le KMS, qui lie l’action, les règles qui l’ont évaluée et les personnes qui l’ont signée.

Un historique que personne ne réécritAU-9(3)

Registre en ajout seul, ancré à l’extérieur avant qu’une action irréversible ne parte.

Les identifiants de clause ne sont pas décoratifs. ZIFFER met en œuvre une spécification ouverte, et chaque affirmation se rejoue chez vous : ./tools/verify.sh --suites

Tarifs

Trois formules. Une seule question : qui vous contrôle ?

En développement

Standard

« C’est vous qui vous contrôlez ? »

  • ZIFFER hébergé, consoles d’administration et d’approbation
  • Reçus signés, clé de signature qui vous est propre
  • Ancrage externe hébergé, CLI pour l’auditeur
  • Intégration MCP / SDK / HTTPS
  • Mise en service lancée sous 48 heures
Réservez 30 min de revue →
En développement

Assured

« C’est un tiers indépendant qui vous contrôle ? »

  • Domaine de vérification séparé
  • Les clés de reçus dans votre compte cloud : nous ne pouvons pas falsifier vos reçus, et vous pouvez nous révoquer
  • Chaque signature s’inscrit dans votre piste d’audit
Réservez 30 min de revue
En développement

Regulated

« C’est un régulateur qui dicte la conservation de vos clés ? »

  • Modalités de conservation imposées
  • Clés conservées en HSM sous mandat externe
  • Pour les déploiements où le mécanisme de gestion des clés est prescrit
Réservez 30 min de revue

Tarifs

Trois formules. Une seule question : qui vous contrôle ?

En développement

Standard

« C’est vous qui vous contrôlez ? »

  • ZIFFER hébergé, consoles d’administration et d’approbation
  • Reçus signés, clé de signature qui vous est propre
  • Ancrage externe hébergé, CLI pour l’auditeur
  • Intégration MCP / SDK / HTTPS
  • Mise en service lancée sous 48 heures
Réservez 30 min de revue →
En développement

Assured

« C’est un tiers indépendant qui vous contrôle ? »

  • Domaine de vérification séparé
  • Les clés de reçus dans votre compte cloud : nous ne pouvons pas falsifier vos reçus, et vous pouvez nous révoquer
  • Chaque signature s’inscrit dans votre piste d’audit
Réservez 30 min de revue
En développement

Regulated

« C’est un régulateur qui dicte la conservation de vos clés ? »

  • Modalités de conservation imposées
  • Clés conservées en HSM sous mandat externe
  • Pour les déploiements où le mécanisme de gestion des clés est prescrit
Réservez 30 min de revue

Les objections, une par une

Ce qu’on vous demandera vraiment en comité de validation.

L’approbation humaine ne va-t-elle pas casser la vitesse des agents ?

La journée passe presque entièrement sans que personne soit sollicité. Vos règles autorisent d’office tout ce qui est courant, en quelques millisecondes ; seules les actions qu’on ne rattrape pas attendent une signature. Un contrôle qui se déclenche sur tout finit approuvé par réflexe, et OWASP range ce réflexe parmi les menaces. Les mises en attente sont donc rares, et chacune arrive avec ce que la machine sait déjà : qui a proposé, dans quel contexte, pour quelle conséquence. C’est un variateur, pas un interrupteur : une autorisation se révoque sans toucher à l’agent.

Pourquoi ne pas le faire avec notre IAM ?

Votre IAM dit si une identité a le droit d’atteindre un système. Il ne dit pas si cette action-là avait lieu d’être : un identifiant n’est pas une autorisation. La boucle de décision, c’est un week-end de travail. Le reste ne l’est pas : des invariants vérifiés par la machine, des reçus signés en hybride post-quantique, un registre ancré à l’extérieur que votre propre administrateur ne peut pas réécrire, et une suite de conformité publique qui le prouve. Si vous le construisez quand même, construisez sur la spécification ouverte : les suites vous diront ce qui manque.

Combien de temps pour intégrer, et qu’est-ce qui change pour l’équipe agents ?

Côté agent, quelques minutes : via MCP, ZIFFER publie votre catalogue d’actions, et il devient la boîte à outils de l’agent ; sinon un appel SDK, ou du simple HTTPS. Une fois par système protégé, un identifiant à portée limitée que seul ZIFFER peut utiliser. La mise en service est lancée sous 48 heures. Votre agent, votre modèle, votre framework et vos prompts restent tels quels.

Qui vous contrôle ?

Personne d’indépendant, pas encore : aucun tiers n’a cherché à le casser, et nous préférons l’écrire ici plutôt que vous laisser le découvrir. Ce que vous pouvez vérifier dès aujourd’hui sans nous : la spécification ouverte, l’implémentation de référence sous Apache 2.0, les suites d’attaque qui se rejouent sur votre poste en supprimant les contrôles un à un, et le fichier de risques résiduels, publié avant nos affirmations. Avec Assured, les clés de reçus restent dans votre compte cloud : nous ne pouvons pas falsifier vos reçus, et vous pouvez nous révoquer sans nous demander notre avis.

Que m’apporte la revue de validation ?

Trente minutes, et vous repartez avec une note de validation, et non une présentation : les propriétés de votre mise en production rapportées aux contrôles que vous avez déjà en place, la liste des actions que nous mettrions en attente de deux personnes nommées, et un échantillon des preuves qu’un auditeur recevrait. Si la réponse honnête est que vous n’avez pas besoin de nous, la note le dira.

Les objections, une par une

Ce qu’on vous demandera vraiment en comité de validation.

L’approbation humaine ne va-t-elle pas casser la vitesse des agents ?

La journée passe presque entièrement sans que personne soit sollicité. Vos règles autorisent d’office tout ce qui est courant, en quelques millisecondes ; seules les actions qu’on ne rattrape pas attendent une signature. Un contrôle qui se déclenche sur tout finit approuvé par réflexe, et OWASP range ce réflexe parmi les menaces. Les mises en attente sont donc rares, et chacune arrive avec ce que la machine sait déjà : qui a proposé, dans quel contexte, pour quelle conséquence. C’est un variateur, pas un interrupteur : une autorisation se révoque sans toucher à l’agent.

Pourquoi ne pas le faire avec notre IAM ?

Votre IAM dit si une identité a le droit d’atteindre un système. Il ne dit pas si cette action-là avait lieu d’être : un identifiant n’est pas une autorisation. La boucle de décision, c’est un week-end de travail. Le reste ne l’est pas : des invariants vérifiés par la machine, des reçus signés en hybride post-quantique, un registre ancré à l’extérieur que votre propre administrateur ne peut pas réécrire, et une suite de conformité publique qui le prouve. Si vous le construisez quand même, construisez sur la spécification ouverte : les suites vous diront ce qui manque.

Combien de temps pour intégrer, et qu’est-ce qui change pour l’équipe agents ?

Côté agent, quelques minutes : via MCP, ZIFFER publie votre catalogue d’actions, et il devient la boîte à outils de l’agent ; sinon un appel SDK, ou du simple HTTPS. Une fois par système protégé, un identifiant à portée limitée que seul ZIFFER peut utiliser. La mise en service est lancée sous 48 heures. Votre agent, votre modèle, votre framework et vos prompts restent tels quels.

Qui vous contrôle ?

Personne d’indépendant, pas encore : aucun tiers n’a cherché à le casser, et nous préférons l’écrire ici plutôt que vous laisser le découvrir. Ce que vous pouvez vérifier dès aujourd’hui sans nous : la spécification ouverte, l’implémentation de référence sous Apache 2.0, les suites d’attaque qui se rejouent sur votre poste en supprimant les contrôles un à un, et le fichier de risques résiduels, publié avant nos affirmations. Avec Assured, les clés de reçus restent dans votre compte cloud : nous ne pouvons pas falsifier vos reçus, et vous pouvez nous révoquer sans nous demander notre avis.

Que m’apporte la revue de validation ?

Trente minutes, et vous repartez avec une note de validation, et non une présentation : les propriétés de votre mise en production rapportées aux contrôles que vous avez déjà en place, la liste des actions que nous mettrions en attente de deux personnes nommées, et un échantillon des preuves qu’un auditeur recevrait. Si la réponse honnête est que vous n’avez pas besoin de nous, la note le dira.

Gardez l’intelligence. Reprenez l’autorité.

C’est vous qu’on envoie signer. Trente minutes, et vous repartez avec la note qui vous permet de décider.

Réservez 30 min de revue →

Mise en service sous 48 heures · spécification ouverte · vérifiez avant de payer

Gardez l’intelligence. Reprenez l’autorité.

C’est vous qu’on envoie signer. Trente minutes, et vous repartez avec la note qui vous permet de décider.

Réservez 30 min de revue →

Mise en service sous 48 heures · spécification ouverte · vérifiez avant de payer