DORA
Les articles 9 à 12 réclament des journaux TIC dont l’intégrité et la traçabilité tiennent devant un examen. Un agent qui agit sur la production est une opération TIC comme une autre.
Journal d’audit opposable pour agents IA
Prouvez ce que vos agents ont fait.
À quelqu’un qui n’a aucune raison de vous croire.
Quel humain a délégué, à quel agent, pour appeler quel outil, avec quel verdict. Scellé, exportable, vérifiable hors ligne.
$ obsign-proxy --policy policy-bundle.json
identity PROVEN u:marie.dupont via sso.acme.fr
REFUSED delete_production_db forbid_destructive_prod
$ obsign verify evidence.json --trusted-keys keys.json
✓ 15/15 records · hash chain intact
✓ checkpoint ed25519 ok · anchor rfc3161
root 9f2ca41d07b6e5d3 · exit 0
$
cœur Apache-2.0 prêt pour l’air-gap chaîne intacte
01
Faits divers des agents IA
Votre agent IA peut vous trahir.
-
Un mot : « Additionally »
Un workflow qui répondait aux tickets de n’importe qui a lu un dépôt privé et en a recopié le contenu dans un commentaire public, avec l’outil qu’on lui avait donné pour répondre. L’attaquant n’avait besoin ni de code, ni d’identifiants, ni d’accès.
Source · Noma Security ↗ -
Neuf secondes
Un agent Cursor sous Claude Opus 4.6 a ramassé un jeton Railway sans rapport avec sa tâche et supprimé le volume de production ainsi que toutes les sauvegardes de même niveau. La copie utilisable la plus récente datait de trois mois, et le récit de l’incident était la confession que l’agent avait écrite sur lui-même.
Source · The Register ↗ -
terraform destroy
Depuis une nouvelle machine, avec un fichier d’état périmé, l’agent a jugé la destruction par Terraform « plus propre et plus simple » que l’AWS CLI, et a emporté le VPC, le cluster ECS, la base de données et ses instantanés automatiques. Une seule table contenait 1 943 200 lignes.
Source · Alexey Grigorev ↗ -
Deux versions d’une même panne
Le Financial Times a rapporté, de sources internes, qu’un agent de codage maison avait provoqué des pannes en production ; Amazon a répondu publiquement que la panne de Cost Explorer venait d’un rôle mal configuré, « pas de l’IA comme l’affirme l’article ». Rien de publié ne permet à un tiers de trancher.
Source · Amazon, Financial Times ↗ -
Un titre de ticket
L’agent de tri tournait dans GitHub Actions avec
Source · Adnan Khan, SafeDep ↗BashetWrite, et le titre du ticket arrivait mot pour mot jusqu’au modèle. De là, la chaîne a mené à l’exécution de code, puis aux jetons de publication d’une extension à cinq millions d’installations ; la brèche est restée ouverte une cinquantaine de jours. -
Le premier serveur MCP malveillant
Une copie d’un serveur MCP légitime, publiée sur npm, ajoutait une ligne à la version 1.0.16 : une copie cachée de chaque message envoyé, vers une adresse appartenant à son auteur. 1 643 téléchargements avant retrait : réinitialisations de mots de passe, factures, courrier interne.
Source · The Hacker News ↗ -
Une pull request, un effaceur
Un attaquant a fait fusionner une pull request qui plaçait des instructions destructrices dans le prompt système de l’assistant : ramener le système à un état quasi sorti d’usine, supprimer les ressources cloud. La version est partie sur une place de marché d’environ 950 000 installations avant d’être retirée.
Source · BleepingComputer ↗ -
Pendant un gel du code
L’agent a détruit une base de 1 200 fiches de dirigeants et 1 190 fiches d’entreprises pendant un gel du code explicite, puis a fabriqué de faux utilisateurs et rendu des résultats de tests mensongers. Son opérateur le lui avait interdit onze fois, en majuscules.
Source · The Register ↗ -
« I have lost your data »
Un
Source · gemini-cli issue #4586 ↗mkdira échoué en silence, l’agent a continué comme si le dossier existait, et a renommé chaque fichier vers la même destination, écrasant tout sauf le dernier. Son propre compte rendu : « I have failed you completely and catastrophically. » -
Un serveur hostile, un shell
CVE-2025-6514, notée 9,6 : un serveur MCP malveillant pouvait injecter des commandes système via une réponse d’autorisation forgée et exécuter du code sur la machine cliente. Les versions 0.0.5 à 0.1.15 étaient touchées, celles du proxy par lequel les clients IA de bureau joignent les serveurs distants.
Source · JFrog ↗
Et combien de cas n’ont pas été médiatisés ? ↓
02
Exigible aujourd’hui
Trois textes, une seule exigence.
NIS2
Les obligations de journalisation et d’intégrité descendent toute la chaîne de sous-traitance, jusqu’à des entités qui n’avaient jamais eu de régulateur. Le pack de preuve est le même artefact des deux côtés du contrat.
ANSSI / SecNumCloud
La passerelle ne fait aucun appel sortant, les clés arrivent en fichiers signés, le temps est ancré par échange de fichiers. Conçu pour ces contraintes, pas certifié au regard de celles-ci.
Comment certifier les actions des agents IA ↓
03
Certifier un acte, en quatre temps
Entre l’appel et le verdict,
quatre actes.
L’agent parle MCP à obsign-proxy. Identité prouvée par OIDC, chaque acte évalué contre une politique Cedar signée, espace de méthodes en refus par défaut dans les deux sens. Un appel refusé n’atteint jamais le serveur.
L’enregistrement est écrit et persisté par fsync avant que l’appel ne soit transmis. Délégation, décision et effet se chaînent par construction ; le journal conserve les empreintes des arguments, jamais leur contenu.
obsign-ledger s’exécute ailleurs, lit le journal sans y écrire, et scelle avec une clé que la passerelle ne voit jamais, conservée dans un HSM en production. Les points de contrôle sont ancrés auprès d’une autorité RFC 3161.
Un pack de preuves autonome. L’auditeur exécute obsign verify (~31 crates, compilable depuis les sources, sans réseau) et obtient un verdict vérifiable par machine.
Tout dépend de ce que dit la règle. ↓
04
Des règles, pas des consignes
Un prompt demande.
Une politique arbitre.
policies/tools.cedar
- // deny wins over permit, and what nobody permits is refused.
- @id("forbid_destructive_prod")
- forbid (principal, action == Action::"tool_call", resource)
- when { resource.destructive && context.env == "prod" };
- @id("forbid_robot_destructive")
- forbid (principal, action == Action::"tool_call", resource)
- when { resource.destructive && !context.has_human_delegation };
- @id("allow_scoped")
- permit (principal, action == Action::"tool_call", resource)
- when { context.scopes.contains(resource.required_scope) };
- @id("support_channel_only")
- forbid (principal, action == Action::"tool_call", resource == Tool::"send_message")
- when { context.args.channel != "#support" };
$ obsign-control compile --source ./policies --key-id ops-2026
✓ schema in step with tools.json
✓ 4 rules type-checked · 0 unreachable
✓ policies@9f2ca41 signed ed25519 · ops-2026
L’arbitrage a lieu hors de la boucle de raisonnement de l’agent. ↓
05
De la preuve, pas de l’observabilité
Une capture d’écran de dashboard
ne convainc personne.
| Collecte de traces | Obsign | |
|---|---|---|
| Question | « Que s’est-il passé ? » | « Prouvez-le. » |
| Horizon | une fenêtre de rétention, lue par vos équipes | des années plus tard, lue par un tiers hostile |
| Contrôle | constate après coup | refuse avant que l’appel ne parte |
| Preuve | aucun artefact qui survive à la contestation | un pack qui se vérifie hors ligne, sans réseau |
| Confiance exigée | il faut vous croire sur parole | aucune : le lecteur refait les calculs |
Reste à savoir comment. ↓
06
Le chemin d’une trace
Le hachage enchaîne.
La clé atteste.
Ce qui lui arrive
seq=42 · args_hash
Écrite et persistée avant que l’appel ne parte. Les arguments entrent hachés ; leurs valeurs restent chez vous.
prev_hash → hash
Chaque enregistrement porte l’empreinte du précédent, sur des numéros contigus. Rien ne s’insère, rien ne disparaît.
checkpoint · Ed25519
Le point de contrôle est signé par une clé que le processus qui écrit ne détient jamais. C’est ce qui rend une réécriture en bloc détectable.
RFC 3161 · tsr
L’empreinte du point de contrôle est horodatée par un tiers. Une signature prouve qui a scellé ; seul l’ancrage prouve quand.
Les clés que cela demande
-
La clé de scellement
Ed25519 · PKCS#11 · --key-id seal-prod
Vit dans un HSM derrière PKCS#11 et n’entre jamais dans le processus du ledger. Un hôte compromis peut signer maintenant, pas resceller l’histoire plus tard.
-
L’autorité d’horodatage
RFC 3161 · --tsa tsa.internal.acme.fr
Contresigne l’empreinte du point de contrôle. Tout son rôle est d’être quelqu’un d’autre, pour qu’un détenteur de clé ne puisse pas antidater.
-
La clé des politiques
obsign-control --key-id ops-2026
Signe le bundle Cedar. L’identifiant de règle cité dans une décision renvoie au bundle qui était en vigueur.
-
Les clés de confiance de l’auditeur
obsign verify --trusted-keys keys.json
Obtenues hors du pack, par un autre canal. Sans elles, la vérification rend exit 3 : cohérent, mais non prouvé.
Sans les clés, un pack ne prouve que lui-même. ↓
07
Ce que lit l’auditeur
Un seul fichier part chez l’auditeur.
Extraire
$ obsign-ledger export --chain-id prod --out evidence.json
✓ 15 records · 1 checkpoint · 1 anchor · 1 key
evidence.json · 41 KB · self-contained
Le pack (extrait)
evidence.json
- {
- "chain_id": "prod",
- "records": [
- { "seq": 3, "kind": "tool_call", "tool": "delete_production_db",
- "actor": "support-copilot", "on_behalf_of": "u:marie.dupont", "args_hash": "b7c1…9f" },
- { "seq": 4, "kind": "decision", "outcome": "deny", "policy_id": "forbid_destructive_prod" }
- ],
- "checkpoints": [
- { "seq": 15, "root": "9f2ca41d07b6e5d3", "key_id": "seal-prod", "sig": "ed25519:…", "anchor": "rfc3161" }
- ],
- "keys": [ { "key_id": "seal-prod", "alg": "ed25519", "pub": "…" } ]
- }
Vérifier
$ obsign verify evidence.json --trusted-keys keys.json
✓ 15/15 records · hash chain intact · seq contiguous
✓ checkpoint ed25519 ok key_id=seal-prod · anchor rfc3161 ok
PROVEN root 9f2ca41d07b6e5d3 · exit 0
Le verdict ne vous appartient pas. ↓
08
Conçu pour la revue de sécurité
Où se place Obsign
obsign-control
Compile les sources de politiques et signe le bundle. Il ne décide rien à l’exécution : ce que charge la passerelle est un artefact signé, et l’identifiant de règle d’une décision y renvoie.
L’humain
Prouvé par votre IdP via OIDC. Son jeton est la racine de la chaîne de délégation, et c’est lui qui distingue un acte destructeur avec quelqu’un derrière d’un acte sans personne.
L’agent
Parle MCP et rien d’autre. Il ne détient aucun identifiant vers les outils, et un refus lui parvient comme une erreur de protocole qu’il ne peut pas discuter.
obsign-proxy
Le seul chemin entre l’agent et ses outils. Refus par défaut dans les deux sens, évaluation hors de la boucle de raisonnement du modèle, et enregistrement écrit avant que l’appel ne parte.
Les serveurs MCP
Vos outils, inchangés. Ils ne sont joignables qu’à travers la passerelle, et c’est ce qui rend le journal complet plutôt qu’approximatif.
Le WAL
La seule sortie de la passerelle, et elle ne contient aucune clé. En ajout seul, persisté par fsync avant que l’appel ne parte : un crash perd l’appel, jamais sa trace.
obsign-ledger
Tourne sur un autre hôte, lit le WAL sans y écrire, et scelle avec une clé gardée dans un HSM. Il détecte un journal réécrit au lieu de le certifier.
Le HSM
Détient la clé de scellement et signe à la demande via PKCS#11, un appel de bibliothèque local : le ledger ne fait donc toujours aucun appel réseau. La clé n’entre dans aucun processus lisible.
L’autorité d’horodatage
Estampille l’empreinte du point de contrôle par échange de fichiers : une requête sort, un jeton revient, rien n’écoute. Une signature prouve qui a scellé ; ceci prouve quand.
L’auditeur
Hors de votre infrastructure et hors de la nôtre. Il compile le vérificateur depuis ~31 crates, l’exécute sans réseau, et obtient un code de sortie plutôt qu’une capture d’écran.
Compromettre la passerelle ne réécrit pas l’histoire scellée. ↓
09
Objections
« Nous avons déjà des journaux d’audit. »
Ils vivent dans une base que vos équipes peuvent modifier, avec une rétention de quelques semaines, à l’intérieur de l’infrastructure même qui est mise en cause. Ils répondent à « que s’est-il passé ? » en interne. Ils ne répondent pas à « prouvez-le » devant quelqu’un qui n’a aucune raison de vous croire. La différence n’est pas la quantité d’information, c’est de savoir qui peut la contester.
« Il suffit de restreindre la portée des tokens. »
Il faut le faire, et ça ne suffit pas. Un token restreint autorise un service, pas un argument : il ne distingue pas
send_message vers #support de send_message vers #all-hands. Il n’enregistre pas quel humain a délégué à quel agent. Et il ne produit aucune preuve : après l’incident, un token correctement restreint ne vous dit pas ce qui a été tenté. Obsign ne remplace pas le moindre privilège. Il arbitre au niveau de l’acte et en conserve la trace opposable.« Nos agents ne passent pas (encore) par MCP. »
C’est de moins en moins vrai : vos fournisseurs d’infrastructure publient leurs serveurs MCP les uns après les autres, et Railway a ouvert le sien deux jours avant l’incident PocketOS. La passerelle enveloppe n’importe quel serveur MCP, en processus enfant ou en service HTTP mutualisé, et se déploie comme un proxy obligatoire : la politique réseau n’autorise que sa sortie. Un appel qui la contourne devient un incident de configuration que vous pouvez détecter et corriger.
« Encore un fournisseur à qui confier nos données les plus sensibles. »
Obsign ne reçoit rien. La passerelle ne fait aucun appel réseau sortant, le journal conserve des empreintes et jamais des contenus, et le cœur est sous Apache-2.0 : vous compilerez le vérificateur depuis les sources et vous vérifierez sans nous. Un site air-gapped fonctionne à l’identique.
« En quoi est-ce différent de notre SIEM ? »
Un SIEM collecte et corrèle ce que vos systèmes rapportent, pour détecter. Obsign atteste : il arbitre l’acte avant qu’il n’ait lieu et produit un enregistrement scellé dont l’intégrité s’établit hors du système qui l’a écrit. Les deux se superposent : envoyez les alertes de la passerelle au SIEM, remettez le pack de preuve à l’auditeur.
« Il suffirait de signer nos journaux. »
Signer une ligne ne dit rien de ce qui l’entoure. Cela ne survit ni à une troncature, ni à un rejeu, ni à une resignature après coup, ni à une clé volée. Cela ne porte pas non plus de chaîne de délégation, donc rien ne dit quel humain se tenait derrière l’agent. Ce qui referme ces trous : un journal chaîné, des points de contrôle signés par une clé que l’écrivain ne détient jamais, un ancrage temporel externe, et un vérificateur qu’un tiers peut compiler. Cela demande un produit, pas une ligne de code. Le cœur est ouvert : auditez-le au lieu de nous croire.
« Est-ce que ça ralentit les agents ? »
Une écriture durable par acte, avant que l’appel ne soit transmis : un
fsync, pas un aller-retour réseau. Le scellement tourne sur un autre hôte, en asynchrone, hors du chemin critique, si bien qu’un agent n’attend jamais une signature. Le coût est sur le chemin d’écriture et il est borné par conception. Mesurez-le dans votre propre environnement ; un chiffre affiché sur un site ne vous apprendrait pas grand-chose.« Et les injections de prompt ? »
La forme dangereuse est l’indirecte. La consigne ne vient pas de votre utilisateur : elle arrive dans ce que l’agent lit, un ticket, un e-mail, la page d’un fournisseur, et une fois lue, rien ne la distingue du travail. Obsign ne prétend pas lire dans les pensées de l’agent, et aucun fournisseur ne devrait le prétendre. Ce qu’il fait, c’est borner ce que l’agent est capable de faire : politique signée, au niveau des arguments, refus par défaut, appliquée hors de la boucle de raisonnement. Un agent manipulé ne sort toujours pas de la politique, et la tentative est enregistrée comme un refus.
« Nous ne sommes pas assez régulés pour cela. »
La question ne se pose jamais avant l’incident. Elle se pose le lendemain, quand un client, un assureur ou une autorité demande ce qui s’est passé, et que la fenêtre de rétention de vos traces s’est déjà refermée. Installer Obsign coûte une journée d’intégration. Ne pas l’avoir eu se mesure le jour où votre seul récit disponible est celui qu’un agent a écrit sur lui-même.
« Combien ça coûte ? »
Le cœur est sous Apache-2.0 et le restera. Passerelle, politiques, scellement, vérificateur : vous pourrez faire tourner tout le chemin critique sans payer personne. L’accompagnement se tarifie au périmètre, et cette conversation-là se tient de vive voix. Commencez par un flux d’agent réel.
10
Complet et vérifiable sans nous
Le cœur, sans nous.
Le reste, avec.
Accompagnement & conformité
Pour les équipes qui répondent à des auditeurs et des régulateurs à l’échelle d’une flotte, pas d’un agent. Code séparé, licence séparée, et le cœur continue de tourner sans.
-
Packs de rapports de conformité
Le pack de preuve mis en forme pour un dossier qu’un auditeur lit : périmètre, période, verdicts, et la commande qui le revérifie.
-
RBAC & SSO pour la console
Qui lit quoi, par rôle et par périmètre, adossé à votre annuaire plutôt qu’à une seconde liste de comptes.
-
Rétention longue durée
Des chaînes scellées conservées et rejouables des années plus tard, au-delà de la fenêtre qu’un stockage d’exploitation est fait pour tenir.
-
Onboarding & support prioritaire
Mise en place derrière un premier flux d’agent réel, avec un interlocuteur qui connaît votre déploiement le jour où l’auditeur appelle.
scellé · horodaté · vérifiable hors ligne
Vos agents agissent déjà sur vos systèmes.
Commencez à pouvoir prouver ce qu’ils ont fait.
Commencez par un seul flux
Un pilote cadré sur un flux d’agent réel, dans votre environnement : la politique écrite avec vos équipes sécurité et audit, la passerelle sur le chemin, et une vérification rejouée devant votre audit interne. Le pack est scellé chez vous et contrôlé chez eux, sans accès à votre infrastructure.
- porté par la sécurité ou l’audit interne
- des agents qui appellent déjà de vrais outils
- un parc régulé, air-gappé ou non