◆ Le point de contrôle d’autorisation pour les agents IA

Les agents IA agissent déjà sur vos systèmes.
Rien ne s’exécute sans votre règle.

ZIFFER vérifie chaque action au regard de votre politique et signe la décision. Votre code l’exécute avec votre propre identifiant. L’agent n’en détient aucun, et ZIFFER ne détient jamais le vôtre.

Analysez votre projet, gratuitement →Parlons-en 30 min
npx @ziffer-io/scan --code --report
01Proposer. Toute action commence par une proposition. L’agent ne détient aucun identifiant.02Autoriser. Votre politique autorise chaque action, la met en attente pour vos approbateurs, ou la refuse.03Exécuter. Votre code vérifie le reçu, puis exécute l’action avec votre propre identifiant.04Prouver. Chaque action exécutée a un reçu signé. Un tiers peut vérifier l’enregistrement.05Distribuer. Vous signez vos règles avec votre propre clé. ZIFFER ne peut pas les réécrire.

◆ Le point de contrôle d’autorisation pour les agents IA

Les agents IA agissent déjà sur vos systèmes. Rien ne s’exécute sans votre règle.

ZIFFER vérifie chaque action au regard de votre politique et signe la décision. Votre code l’exécute avec votre propre identifiant. L’agent n’en détient aucun, et ZIFFER ne détient jamais le vôtre.

Analysez votre projet, gratuitement →Parlons-en 30 min
npx @ziffer-io/scan --code --report
01Proposer. Toute action commence par une proposition. L’agent ne détient aucun identifiant.02Autoriser. Votre politique autorise chaque action, la met en attente pour vos approbateurs, ou la refuse.03Exécuter. Votre code vérifie le reçu, puis exécute l’action avec votre propre identifiant.04Prouver. Chaque action exécutée a un reçu signé. Un tiers peut vérifier l’enregistrement.05Distribuer. Vous signez vos règles avec votre propre clé. ZIFFER ne peut pas les réécrire.

◆ En 67 secondes

Regardez trois actions passer par une même politique.

Une modification courante obtient un reçu. Un virement injecté de 48 000 € attend vos approbateurs. Une action sans règle est refusée.

◆ En 67 secondes

Regardez trois actions passer par une même politique.

Une modification courante obtient un reçu. Un virement injecté de 48 000 € attend vos approbateurs. Une action sans règle est refusée.

◆ Démarrer en une commande

Analysez le dépôt où sont construits les outils de votre agent, ou donnez à votre assistant IA les outils de ZIFFER.

Trouve les outils que votre code donne à un modèle d’IA, et ceux dont l’effet ne peut pas être annulé. Il écrit un rapport. Vous n’avez besoin d’aucun compte, et rien n’est envoyé nulle part.

npx @ziffer-io/scan --code --report

Lire la documentationLe code source sur GitHub

◆ Démarrer en une commande

Analysez le dépôt où sont construits les outils de votre agent, ou donnez à votre assistant IA les outils de ZIFFER.

Analyser votre projet

Trouve les outils que votre code donne à un modèle d’IA, et ceux dont l’effet ne peut pas être annulé. Il écrit un rapport. Vous n’avez besoin d’aucun compte, et rien n’est envoyé nulle part.

npx @ziffer-io/scan --code --report

Claude Code

Ajoute le plugin ZIFFER et ses six skills. Ils analysent votre code, y intègrent ZIFFER, construisent la politique, mettent en place son pipeline et vérifient le résultat. Le plugin démarre lui-même le serveur MCP.

claude plugin marketplace add ziffer-hq/ziffer-sdk
claude plugin install ziffer@ziffer

Autres assistants IA

Placez cette commande dans les réglages MCP de votre assistant IA. Elle donne à l’assistant les outils de ZIFFER : analyser votre code, intégrer le SDK, vérifier votre politique et essayer une décision.

npx -y @ziffer-io/mcp

Lire la documentationLe code source sur GitHub

Supposez que l’injection réussisse. Voici trois façons dont elle atteint votre agent.

Vos agents lisent des e-mails, des tickets et des documents hors de votre contrôle. Une phrase qui s’y trouve devient une instruction.

Votre politique décide, quoi qu’ait cru le modèle. Un agent injecté, un agent qui se trompe et un agent utilisé à mauvais escient rencontrent la même règle.

via un e-mail qu’il résumeUn texte caché dans le message dit à l’agent de transmettre ce qu’il peut atteindre. Les données quittent votre tenant. Refusée : aucune règle ne l’autorise.
via un ticket qu’il litUn ticket empoisonné devient une écriture destructrice en production, autorisée parce que l’agent détient l’identifiant. En attente : le quorum 2 sur 2 de cette politique, non atteint.
via un document qu’il récupèreUne page récupérée déplace un paiement vers un nouveau bénéficiaire. Rien n’enregistre qui l’a autorisé, parce que personne ne l’a fait. En attente jusqu’à ce que les approbateurs nommés par cette politique aient signé.

Quiconque peut placer du texte devant un agent peut agir avec ses identifiants : un e-mail, un ticket, un PDF, une page web. 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 : cette faille ne se refermera peut-être jamais comme l’a fait l’injection SQL.

Supposez que l’injection réussisse. Voici trois façons dont elle atteint votre agent.

Vos agents lisent des e-mails, des tickets et des documents hors de votre contrôle. Une phrase qui s’y trouve devient une instruction.

Votre politique décide, quoi qu’ait cru le modèle. Un agent injecté, un agent qui se trompe et un agent utilisé à mauvais escient rencontrent la même règle.

via un e-mail qu’il résumeUn texte caché dans le message dit à l’agent de transmettre ce qu’il peut atteindre. Les données quittent votre tenant. Refusée : aucune règle ne l’autorise.
via un ticket qu’il litUn ticket empoisonné devient une écriture destructrice en production, autorisée parce que l’agent détient l’identifiant. En attente : le quorum 2 sur 2 de cette politique, non atteint.
via un document qu’il récupèreUne page récupérée déplace un paiement vers un nouveau bénéficiaire. Rien n’enregistre qui l’a autorisé, parce que personne ne l’a fait. En attente jusqu’à ce que les approbateurs nommés par cette politique aient signé.

Quiconque peut placer du texte devant un agent peut agir avec ses identifiants : un e-mail, un ticket, un PDF, une page web. 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 : cette faille ne se refermera peut-être jamais comme l’a fait l’injection SQL.

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

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 Global Survey, « 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 n’apparaît que sur les deux risques qui portent sur l’autorité de l’agent. Les deux autres n’en montrent aucun.
8,5 %des injections indirectes réussissent malgré tout contre le modèle mesuré le plus résistant aux injections, en 15 tentatives
97 %des organisations compromises ayant subi un incident lié à l’IA n’avaient pas de contrôles d’accès à l’IA adaptés

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

Les plus performants en IATous les autres
L’écart n’apparaît que sur les deux risques qui portent sur l’autorité de l’agent. Les deux autres n’en montrent 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 Global Survey, « The state of AI in 2026: On the road to ROI », n = 1 719, mai-juin 2026 (Exhibit 15).

Comment cela fonctionne

L’agent propose, votre politique décide, votre code exécute, et un reçu signé le prouve.

ZIFFER ne filtre pas les prompts. Il vérifie les actions. Un agent manipulé ne détient aucun identifiant, donc il ne peut pas agir seul.

01 · Proposer

Toute action commence par une proposition. L’agent détient une seule clé ZIFFER. Cette clé peut demander, et elle ne peut pas agir.

  • Via MCP, un agent de codage obtient l’intégration. Le contrôle, c’est la ligne de vérification du SDK, dans votre propre code.
  • Ou bien un appel SDK, ou du simple HTTPS. Votre agent, votre modèle et vos prompts ne changent pas.
  • Le moindre privilège que vous pouvez montrer : il n’y a dans l’agent aucun identifiant qu’un auditeur puisse examiner. Pourquoi un agent ne doit détenir aucun identifiant

02 · Autoriser

Votre politique décide. Elle autorise les actions courantes sans attendre personne. Elle met en attente pour vos approbateurs les actions que personne ne peut annuler.

  • Autorisée quand vos règles évaluent l’action LOW
  • Mise en attente d’un quorum quand vos règles l’évaluent HIGH. Chaque approbateur signe les octets exacts qui s’exécuteront. Le silence ne vaut jamais consentement.
  • Refusée par défaut quand aucune règle n’existe

03 · Exécuter

Votre code exécute. Il n’exécute une action qu’après avoir vérifié le reçu, et seulement avec votre propre identifiant.

  • L’identifiant reste dans votre outil. Votre code ne l’utilisera pas sans un reçu qu’il a vérifié lui-même, hors ligne, avec la clé publique de ZIFFER.
  • Votre auditeur peut le tester : il appelle votre outil sans reçu, ou avec un reçu pour d’autres octets, et il voit votre code refuser.
  • Ce qui a été autorisé est exactement ce qui s’est exécuté. Votre code hache les octets qu’il détient et les compare au reçu. Il ne fait jamais confiance au message.

04 · Prouver

Un reçu signé prouve ce qui s’est exécuté. L’enregistrement conserve ce que l’agent a lu. Personne ne peut le modifier ensuite.

  • Signatures hybrides post-quantiques (Ed25519 + ML-DSA-65)
  • Ni nous, ni votre propre administrateur : personne ne peut modifier un enregistrement une fois qu’il est écrit
  • Une non-répudiation que votre auditeur vérifie avec un CLI public, sans accès à la production

05 · Distribuer

Vous signez vos règles avec votre propre clé. ZIFFER ne voit jamais cette clé. Même compromis, ZIFFER ne peut pas réécrire vos règles.

  • Aucun composant d’exécution ne détient de clé capable de produire une signature de politique valide, donc le chemin d’exécution n’a rien qui vaille la peine d’être volé.
  • Le moteur de politique, le KMS et l’exécuteur vérifient chacun le bundle de façon indépendante, à chaque lecture : un service qui recevrait la politique d’un pair se contenterait de faire confiance à ce pair.
  • Gestion des changements : chaque nouvelle politique doit porter un numéro de version plus élevé, donc un retour aux règles plus souples d’hier est refusé

Comment cela fonctionne

L’agent propose, votre politique décide, votre code exécute, et un reçu signé le prouve.

ZIFFER vérifie les actions, pas les prompts. Un agent manipulé ne détient aucun identifiant, donc il ne peut pas agir seul.

01 · Proposer

Toute action commence par une proposition. L’agent détient une seule clé ZIFFER. Cette clé peut demander, et elle ne peut pas agir.

  • Via MCP, un agent de codage obtient l’intégration. Le contrôle, c’est la ligne de vérification du SDK, dans votre propre code.
  • Ou bien un appel SDK, ou du simple HTTPS. Votre agent, votre modèle et vos prompts ne changent pas.
  • Le moindre privilège que vous pouvez montrer : il n’y a dans l’agent aucun identifiant qu’un auditeur puisse examiner. Pourquoi un agent ne doit détenir aucun identifiant

02 · Autoriser

Votre politique décide. Elle autorise les actions courantes sans attendre personne. Elle met en attente pour vos approbateurs les actions que personne ne peut annuler.

  • Autorisée quand vos règles évaluent l’action LOW
  • Mise en attente d’un quorum quand vos règles l’évaluent HIGH. Chaque approbateur signe les octets exacts qui s’exécuteront. Le silence ne vaut jamais consentement.
  • Refusée par défaut quand aucune règle n’existe

03 · Exécuter

Votre code exécute. Il n’exécute une action qu’après avoir vérifié le reçu, et seulement avec votre propre identifiant.

  • L’identifiant reste dans votre outil. Votre code ne l’utilisera pas sans un reçu qu’il a vérifié lui-même, hors ligne, avec la clé publique de ZIFFER.
  • Votre auditeur peut le tester : il appelle votre outil sans reçu, ou avec un reçu pour d’autres octets, et il voit votre code refuser.
  • Ce qui a été autorisé est exactement ce qui s’est exécuté. Votre code hache les octets qu’il détient et les compare au reçu. Il ne fait jamais confiance au message.

04 · Prouver

Un reçu signé prouve ce qui s’est exécuté. L’enregistrement conserve ce que l’agent a lu.

  • Signatures hybrides post-quantiques (Ed25519 + ML-DSA-65)
  • Ni nous, ni votre propre administrateur : personne ne peut modifier un enregistrement une fois qu’il est écrit
  • Une non-répudiation que votre auditeur vérifie avec un CLI public, sans accès à la production

05 · Distribuer

Vous signez vos règles avec votre propre clé. ZIFFER ne voit jamais cette clé.

  • Aucun composant d’exécution ne détient de clé capable de produire une signature de politique valide, donc le chemin d’exécution n’a rien qui vaille la peine d’être volé.
  • Le moteur de politique, le KMS et l’exécuteur vérifient chacun le bundle de façon indépendante, à chaque lecture : un service qui recevrait la politique d’un pair se contenterait de faire confiance à ce pair.
  • Gestion des changements : chaque nouvelle politique doit porter un numéro de version plus élevé, donc un retour aux règles plus souples d’hier est refusé

Qui détient les clés

ZIFFER ne détient jamais vos identifiants. Il n’exécute jamais d’action dans vos systèmes.

  • Vos identifiants restent dans votre propre code. Votre code exécute une action autorisée après avoir vérifié le reçu.
  • Un point de contrôle qui exécute aussi les actions peut à la fois autoriser et agir. Plus rien ne le contrôle alors.
  • Si ZIFFER était compromis, l’attaquant n’y trouverait aucun de vos identifiants.
  • L’attaquant ne pourrait ni signer ni réécrire vos règles. ZIFFER ne voit jamais la clé qui les signe.
  • Les clés de vos approbateurs ne quittent jamais leurs propres appareils.
  • ZIFFER contacte bien vos approbateurs, par e-mail, Slack ou webhook. Une notification contient un lien, jamais un bouton d’approbation.
  • Dans la formule Assured, vos clés de reçus sont dans votre propre compte cloud, donc nous ne pouvons pas falsifier vos reçus.

Qui détient les clés

ZIFFER ne détient jamais vos identifiants. Il n’exécute jamais d’action dans vos systèmes.

  • Vos identifiants restent dans votre propre code. Votre code exécute une action autorisée après avoir vérifié le reçu.
  • Un point de contrôle qui exécute aussi les actions peut à la fois autoriser et agir. Plus rien ne le contrôle alors.
  • Si ZIFFER était compromis, l’attaquant n’y trouverait aucun de vos identifiants.
  • L’attaquant ne pourrait ni signer ni réécrire vos règles. ZIFFER ne voit jamais la clé qui les signe.
  • Les clés de vos approbateurs ne quittent jamais leurs propres appareils.
  • ZIFFER contacte bien vos approbateurs, par e-mail, Slack ou webhook. Une notification contient un lien, jamais un bouton d’approbation.
  • Dans la formule Assured, vos clés de reçus sont dans votre propre compte cloud, donc nous ne pouvons pas falsifier vos reçus.

◆ Ce que vous remettez à l’auditeur

Chaque action a sa ligne dans l’enregistrement. Chaque ligne montre ce qui a été proposé, ce que votre politique a décidé, et qui a signé.

◆ Ce que vous remettez à l’auditeur

Chaque action a sa ligne dans l’enregistrement. Chaque ligne montre ce qui a été proposé, ce que votre politique a décidé, et qui a signé.

La checklist de validation

Six propriétés que vous pouvez vérifier avant de donner votre validation. Quatre d’entre elles citent une clause publiée, indiquée sous le titre.

Aucun identifiant dans l’agent

L’agent ne détient aucun secret, même éphémère ou fourni par un intermédiaire. Rien ne peut fuir dans une fenêtre de contexte.

La preuve de chaque action

Votre plateforme d’agents montre ce que l’agent a vu. Chaque reçu ZIFFER prouve ce qu’il avait le droit de faire : l’action, la version de la politique, qui a approuvé, et la décision.

Refus par défaut

8.4-3 · P-4

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

L’approbation est explicite et liée à l’action exacte

AC-3(2)

Double autorisation : votre politique signée fixe le quorum de personnes nommément désignées, et chacune signe les octets exacts qui s’exécuteront. L’auteur de la proposition ne peut pas approuver sa propre action.

Un reçu signé pour chaque action autorisée

AU-10 · AU-3

Seule une action autorisée reçoit un reçu signé par le KMS, qui lie l’action, ses règles et les personnes qui ont signé. Un refus ou une expiration laisse un enregistrement de décision.

Un historique que personne ne peut réécrire

AU-9(3)

Les enregistrements sont seulement ajoutés, jamais modifiés. Ils sont publiés hors de ZIFFER avant qu’une action irréversible ne s’exécute.

Les identifiants de clause sont réels. ZIFFER met en œuvre une spécification ouverte avec des preuves vérifiées par machine et une suite de conformité publique. Chaque affirmation se rejoue sur votre machine : ./tools/verify.sh --suites

La checklist de validation

Six propriétés que vous pouvez vérifier avant de donner votre validation. Quatre d’entre elles citent une clause publiée, indiquée sous le titre.

Aucun identifiant dans l’agent

L’agent ne détient aucun secret, même éphémère ou fourni par un intermédiaire. Rien ne peut fuir dans une fenêtre de contexte.

La preuve de chaque action

Votre plateforme d’agents montre ce que l’agent a vu. Chaque reçu ZIFFER prouve ce qu’il avait le droit de faire : l’action, la version de la politique, qui a approuvé, et la décision.

Refus par défaut

8.4-3 · P-4

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

L’approbation est explicite et liée à l’action exacte

AC-3(2)

Double autorisation : votre politique signée fixe le quorum de personnes nommément désignées, et chacune signe les octets exacts qui s’exécuteront. L’auteur de la proposition ne peut pas approuver sa propre action.

Un reçu signé pour chaque action autorisée

AU-10 · AU-3

Seule une action autorisée reçoit un reçu signé par le KMS, qui lie l’action, ses règles et les personnes qui ont signé. Un refus ou une expiration laisse un enregistrement de décision.

Un historique que personne ne peut réécrire

AU-9(3)

Les enregistrements sont seulement ajoutés, jamais modifiés. Ils sont publiés hors de ZIFFER avant qu’une action irréversible ne s’exécute.

Les identifiants de clause sont réels. ZIFFER met en œuvre une spécification ouverte avec des preuves vérifiées par machine et une suite de conformité publique. Chaque affirmation se rejoue sur votre machine : ./tools/verify.sh --suites

Tarifs

Trois formules. Elles diffèrent selon qui détient vos clés de reçus et qui vous contrôle.

Disponible maintenant

Standard

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

Pour qui : les équipes qui mettent leurs premiers agents IA en production et qui vérifient elles-mêmes leurs contrôles.

  • ZIFFER hébergé, consoles d’administration et d’approbation
  • Reçus signés, clé de signature par tenant
  • Ancrage externe hébergé, CLI pour l’auditeur
  • Intégration MCP / SDK / HTTPS
  • La mise en service commence sous 48 heures
Parlons-en 30 min →
Sur demande

Assured

« Est-ce quelqu’un d’indépendant qui vous contrôle ? »

Pour qui : les entreprises dont les auditeurs ou les clients grands comptes veulent une preuve vérifiée par quelqu’un d’autre que l’éditeur, avec les clés de signature dans leur propre cloud, pour que ZIFFER ne puisse pas falsifier un reçu.

  • La vérification se fait hors production, par une partie sans aucun identifiant de production
  • 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 arrive dans votre piste d’audit
Parlons-en 30 min
Sur demande

Regulated

« Est-ce un régulateur qui dicte la façon dont vos clés sont conservées ? »

Pour qui : les banques, les entreprises de paiement et de santé dont le régulateur dicte la façon dont les clés de signature sont conservées.

  • 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
Parlons-en 30 min

Lire la page complète des tarifs

Tarifs

Trois formules. Elles diffèrent selon qui détient vos clés de reçus et qui vous contrôle.

Disponible maintenant

Standard

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

Pour qui : les équipes qui mettent leurs premiers agents IA en production et qui vérifient elles-mêmes leurs contrôles.

  • ZIFFER hébergé, consoles d’administration et d’approbation
  • Reçus signés, clé de signature par tenant
  • Ancrage externe hébergé, CLI pour l’auditeur
  • Intégration MCP / SDK / HTTPS
  • La mise en service commence sous 48 heures
Parlons-en 30 min →
Sur demande

Assured

« Est-ce quelqu’un d’indépendant qui vous contrôle ? »

Pour qui : les entreprises dont les auditeurs ou les clients grands comptes veulent une preuve vérifiée par quelqu’un d’autre que l’éditeur, avec les clés de signature dans leur propre cloud, pour que ZIFFER ne puisse pas falsifier un reçu.

  • La vérification se fait hors production, par une partie sans aucun identifiant de production
  • 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 arrive dans votre piste d’audit
Parlons-en 30 min
Sur demande

Regulated

« Est-ce un régulateur qui dicte la façon dont vos clés sont conservées ? »

Pour qui : les banques, les entreprises de paiement et de santé dont le régulateur dicte la façon dont les clés de signature sont conservées.

  • 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
Parlons-en 30 min

Lire la page complète des tarifs

Réponses aux objections

Les questions que votre comité de validation posera.

Attendre deux personnes ne tue-t-il pas la vitesse des agents ?

La plus grande partie de la journée se passe sans intervention. Seules les actions que personne ne peut annuler sont mises en attente, donc les mises en attente sont rares. Un contrôle qui se déclenche sur tout finit approuvé par réflexe, et OWASP répertorie ce réflexe comme une menace à part entière. Chaque mise en attente parvient à l’approbateur avec les faits déjà enregistrés : qui a proposé l’action, ce que l’agent avait lu, et ce que l’action ferait. Une autorisation peut être révoquée sans toucher à l’agent.

Pourquoi ne pas le construire avec notre propre IAM ?

Votre IAM dit si une identité peut atteindre un système. Il ne dit pas si cette action doit avoir lieu. Vous pouvez construire la boucle de contrôle en un week-end. Le reste prend plus de temps : des preuves vérifiées par 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 prouve tout cela. Si vous le construisez quand même, construisez-le sur la spécification ouverte. Les suites vous diront ce qui manque à votre version.

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

Quelques minutes côté agent. Le code de votre outil ajoute un appel SDK pour proposer et une ligne pour vérifier le reçu, et du simple HTTPS fonctionne aussi. Via MCP, un agent de codage obtient cette intégration. L’identifiant reste dans votre outil, et votre code ne l’utilisera pas sans un reçu qu’il a vérifié lui-même. La mise en service commence sous 48 heures. Votre agent, votre modèle, votre framework et vos prompts ne changent pas.

Qu’est-ce que la revue de validation m’apporte ?

Trente minutes, et vous repartez avec une note de validation plutôt qu’une présentation : les propriétés de votre déploiement rapportées aux contrôles que vous avez déjà, la liste des actions que nous mettrions en attente d’un quorum de personnes nommément désigné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 dit.

Réponses aux objections

Les questions que votre comité de validation posera.

Attendre deux personnes ne tue-t-il pas la vitesse des agents ?

La plus grande partie de la journée se passe sans intervention. Seules les actions que personne ne peut annuler sont mises en attente, donc les mises en attente sont rares. Un contrôle qui se déclenche sur tout finit approuvé par réflexe, et OWASP répertorie ce réflexe comme une menace à part entière. Chaque mise en attente parvient à l’approbateur avec les faits déjà enregistrés : qui a proposé l’action, ce que l’agent avait lu, et ce que l’action ferait. Une autorisation peut être révoquée sans toucher à l’agent.

Pourquoi ne pas le construire avec notre propre IAM ?

Votre IAM dit si une identité peut atteindre un système. Il ne dit pas si cette action doit avoir lieu. Vous pouvez construire la boucle de contrôle en un week-end. Le reste prend plus de temps : des preuves vérifiées par 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 prouve tout cela. Si vous le construisez quand même, construisez-le sur la spécification ouverte. Les suites vous diront ce qui manque à votre version.

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

Quelques minutes côté agent. Le code de votre outil ajoute un appel SDK pour proposer et une ligne pour vérifier le reçu, et du simple HTTPS fonctionne aussi. Via MCP, un agent de codage obtient cette intégration. L’identifiant reste dans votre outil, et votre code ne l’utilisera pas sans un reçu qu’il a vérifié lui-même. La mise en service commence sous 48 heures. Votre agent, votre modèle, votre framework et vos prompts ne changent pas.

Qu’est-ce que la revue de validation m’apporte ?

Trente minutes, et vous repartez avec une note de validation plutôt qu’une présentation : les propriétés de votre déploiement rapportées aux contrôles que vous avez déjà, la liste des actions que nous mettrions en attente d’un quorum de personnes nommément désigné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 dit.

Apportez-nous le déploiement qu’on vous demande d’approuver.

En trente minutes, vous repartez avec la note que vous signeriez.

Parlons-en 30 min →

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

Apportez-nous le déploiement qu’on vous demande d’approuver.

En trente minutes, vous repartez avec la note que vous signeriez.

Parlons-en 30 min →

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