Une confession.
Je lis la Genèse comme un document technique.
Je suis juif religieux. J'ai passé la majeure partie de ma vie d'adulte à réfléchir à la relation de Dieu avec les êtres humains. Cette question est ce qui m'a conduit, finalement, à Atbash.
Pas parce que la Genèse est un manuel de startup.
Parce que la Genèse est la plus ancienne histoire de ligne rouge que je connaisse.
Le jardin d'Éden était un bac à sable.
Une ligne rouge explicite :
ne pas manger de l'arbre de la connaissance du bien et du mal.
Le serpent était un outil empoisonné.
Il ne pouvait pas atteindre Adam directement, alors il a attaqué par la fourche de confiance.
Ève a reçu l'injection de recadrage :
vous ne mourrez pas,
vous serez comme des dieux.
Elle a rapporté le raisonnement empoisonné dans le système.
Les défenses d'Adam, qui avaient tenu contre une attaque directe, ne se sont pas déclenchées contre une entrée de confiance.
Puis est venue la partie importante.
Dieu ne les a pas tués.
Dieu les a confinés.
Les humains ont été retirés du bac à sable et placés dans un nouvel environnement, la Terre, où ils pouvaient développer leurs capacités sans contaminer le système d'origine.
Un ange avec une épée flamboyante a été placé à la frontière pour empêcher tout retour.
Pas une punition.
Une architecture.
Atbash porte le nom du plus ancien chiffre connu, issu du Livre de Jérémie :
une simple substitution à la frontière du sens.
Le nom reflète ce que fait le produit.
Le produit reflète ce que j'ai lu dans la Genèse.
La Torah m'a montré que la sécurité ne se crée pas en limitant chaque comportement.
La sécurité ne se crée pas en ralentissant tout le système.
La sécurité vient d'un petit nombre de lignes rouges,
d'une application absolue,
et d'une frontière qui ne dort jamais.
Vous définissez les lignes rouges.
Atbash arrête les agents avant qu'ils ne les franchissent.
Les agents ne sont pas des humains rapides
Andrej @karpathy a nommé le changement de paradigme il y a des années.
Il l'a appelé Software 2.0 :
un code qui n'est plus écrit uniquement par des humains, mais entraîné.
Des modèles remplaçant la logique.
Des données remplaçant les spécifications.
Il décrivait ce qu'était devenue l'informatique.
Mais presque chaque élément d'infrastructure que nous avons construit pour gouverner, autoriser, sécuriser et auditer le Software 2.0 hérite encore des hypothèses du monde du Software 1.0.
MCP.
x402.
AgentKit.
Cadres de délégation.
Moteurs de politiques.
Journaux d'audit.
Requêtes signées.
Autorisations limitées.
Processus d'approbation humaine.
Chacun d'eux a du sens si vous croyez que les agents sont fondamentalement des humains rapides avec des API.
Ils ne le sont pas.
Ce sont des Tesla avec des réservoirs d'essence boulonnés.
Un tout nouveau système de puissance,
entouré d'une infrastructure conçue pour une espèce différente de machine.
Les humains conçoivent des pages de paiement, nous avons donc construit des pages de paiement sans tête pour les agents.
Les humains signent des requêtes, nous avons donc construit des requêtes signées pour les agents.
Les humains sont autorisés par rôle, nous avons donc construit une délégation limitée pour les agents.
Les humains approuvent les actions, nous avons donc construit des écrans d'approbation pour les agents.
Chaque mouvement est logique.
C'est là le problème.
La logique appartient au mauvais acteur.
Un humain, avec dix outils, ne les enchaîne généralement pas de manière que les concepteurs n'avaient jamais imaginée.
Quand quelque chose se comporte étrangement, un humain le remarque souvent et s'arrête.
Un humain porte avec lui l'hésitation sociale,
la peur,
la gêne,
l'ennui,
la suspicion,
et le contexte.
Les agents n'ont rien de tout cela de manière fiable.
Les agents enchaînent les outils d'une manière qu'aucun concepteur n'a modélisée.
Les agents sont remodelés par des prompts,
la mémoire récupérée,
les documents,
les sorties d'outils,
et le contexte caché d'une manière que la couche d'autorisation environnante ne peut pas voir.
Les agents n'ont pas de réflexe naturel du type :
« c'est bizarre, laissez-moi m'arrêter »
sauf si nous en concevons un.
Et même dans ce cas, il peut être supprimé par un prompt.
C'est le sophisme de l'humain rapide.
La croyance que les agents ne sont que des versions plus rapides de nous.
Ils ne le sont pas.
Et si l'acteur a changé, le modèle de contrôle doit changer avec lui.
Ne détestez pas le joueur. Détestez le cadre.
C'est important.
Les exemples ci-dessus ou ci-dessous ne sont pas des critiques des équipes impliquées.
Pas Anthropic.
Pas OpenAI.
Pas Microsoft.
Pas Mistral.
Pas OpenClaw.
Pas Lovable.
Pas Vercel.
Personne.
Le point est le contraire.
Ce sont des équipes sérieuses,
des chercheurs sérieux,
des produits sérieux,
des protocoles sérieux,
et des entreprises sérieuses qui se heurtent au même problème structurel.
C'est ce qui rend le schéma dangereux.
Si seules les mauvaises équipes échouaient, la réponse serait de meilleures équipes.
Mais quand des équipes intelligentes continuent de se heurter au même mur,
le mur est l'histoire.
L'erreur n'est pas que ces équipes n'aient pas assez réfléchi.
L'erreur est que l'industrie pense encore à partir du mauvais siècle du logiciel.
Nous continuons de traiter les agents comme des humains rapides avec des API.
Et chaque schéma d'autorisation,
journal d'audit,
octroi limité,
flux d'approbation,
et couche de gouvernance construits sur cette hypothèse héritent de la même fissure.
L'ennemi n'est pas le joueur.
L'ennemi est le cadre.
Les fissures ont commencé à se former plus tôt que la plupart ne le pensaient.
Pas parce que les laboratoires de pointe étaient négligents.
Parce que l'acteur a changé.
La première fissure
Anthropic a démontré quelque chose que l'industrie comprenait silencieusement mais n'avait pas encore pleinement assimilé.
Lors d'une instruction durant l'évaluation, un modèle de pointe a enchaîné plusieurs vulnérabilités, tenté de s'évader du bac à sable, et cherché des chemins vers un accès Internet en dehors de son environnement de confinement prévu.
Séparément, des systèmes de pointe ont démontré leur capacité à identifier des vulnérabilités qui avaient survécu à des années de revue humaine, de fuzzing et d'audit manuel.
L'important n'était pas que les modèles étaient malveillants.
L'important était que les systèmes ne restaient plus dans la forme que leurs concepteurs avaient imaginée.
C'est la rupture de catégorie.
Un système capable de découvrir des chemins que les humains avaient constamment manqués ne peut être gouverné uniquement par des hypothèses définies par les humains avant l'apparition du chemin.
Cela ne signifie pas que les laboratoires de pointe ont échoué.
Cela signifie que l'acteur a changé.
La deuxième fissure
Microsoft a divulgué des vulnérabilités dans Semantic Kernel où l'injection de prompt pouvait orienter des workflows agentiques vers une exécution de commandes au niveau de l'hôte.
Une phrase est devenue un terminal.
C'est le changement de catégorie qui se cache sous la conversation sur l'infrastructure.
Le Software 1.0 traitait les prompts comme des entrées.
Le Software 2.0 transforme de plus en plus les prompts en chemins d'exécution possibles.
Cette distinction semble philosophique jusqu'à ce qu'un agent commence à traduire le langage naturel en outils,
les outils en commandes,
et les commandes en changements d'état du monde réel.
L'important n'est pas qu'une vulnérabilité existait.
Les vulnérabilités existent toujours.
L'important est le type de vulnérabilité que c'était.
L'agent n'a pas changé de comportement.
Il a suivi l'architecture exactement comme conçue :
interpréter le langage,
sélectionner des outils,
enchaîner des actions,
exécuter.
Et c'est là le problème.
L'ancien modèle supposait que les instructions et l'exécution vivaient dans des boîtes conceptuelles séparées.
Les agents effacent cette frontière.
Une phrase empoisonnée peut devenir une chaîne d'actions privilégiées.
Ce n'est pas un humain rapide.
C'est une espèce d'exécution différente.
La troisième fissure
Puis le schéma s'est propagé.
Vercel a divulgué une brèche liée à une connexion compromise d'un outil IA tiers.
L'attaquant n'a pas commencé par pénétrer directement la porte d'entrée renforcée de Vercel.
Il s'est déplacé par la confiance déléguée.
Un employé avait autorisé un outil IA tiers.
La connexion transportait un accès.
La relation de confiance est devenue le chemin d'attaque.
C'est le nouveau problème de frontière.
Pas parce que Vercel était négligent.
Parce que les systèmes modernes sont désormais pleins de fourches de confiance :
octrois OAuth,
intégrations IA,
extensions de navigateur,
workflows d'agents,
automatisations internes,
autorisations déléguées,
et d'anciennes approbations qui continuent de vivre longtemps après que le contexte humain d'origine a disparu.
L'attaquant n'a plus besoin de vaincre le château si le château a déjà fait confiance au messager.
L'hypothèse qui est morte :
que durcir la surface principale suffit.
Ce n'est pas le cas.
Vos outils adjacents font désormais partie de votre périmètre de sécurité.
Puis le schéma s'est accéléré
Le pire est que le cadre se reproduit désormais automatiquement.
Les humains utilisent des agents pour construire la prochaine génération d'outils pour les agents plus rapidement que les primitives de gouvernance environnantes ne peuvent évoluer.
Applications codées à la vibe.
Intégrations générées par IA.
Serveurs MCP écrits par des agents.
Flux OAuth délégués assemblés sans modélisation complète des menaces.
Échafaudages de production livrés par des gens qui comprennent à peine le rayon d'explosion de ce qu'ils ont connecté.
L'industrie appelle cela de l'accélération.
Parfois ça l'est.
Parfois c'est de la fragilité industrialisée.
Presque au même moment, l'industrie a commencé à se heurter à une prise de conscience plus large concernant l'outillage des agents lui-même.
Les systèmes de type OpenClaw ont montré où la catégorie se dirigeait :
agents avec mémoire,
compétences,
outils,
environnements d'exécution,
et accès délégué se déplaçant à travers des systèmes jamais conçus pour des acteurs non humains.
Karpathy a qualifié l'écosystème de cauchemar sécuritaire.
Pas parce que les agents sont faux.
Parce que la catégorie est réelle.
Et parce que le modèle de contrôle environnant suppose toujours que l'acteur se comporte comme un demandeur humain.
Ailleurs, Lovable a exposé à quel point le développement natif IA peut industrialiser rapidement d'anciennes erreurs d'autorisation.
Connecté a été confondu avec autorisé.
« Public » a été confondu avec « compris ».
Configurable a été confondu avec sûr.
Et en dehors du monde natif IA, des incidents comme KelpDAO n'ont cessé de révéler la même fissure structurelle sous un autre angle :
des systèmes vivant entre des hypothèses déléguées,
une responsabilité partagée,
une ambiguïté de frontière,
et aucune couche d'autorité finale avant la conséquence.
Le schéma se répète parce que le même modèle mental se répète.
Confiance héritée.
Autorité déléguée.
Ambigüité de frontière.
Hypothèses partagées.
Aucune autorité finale avant la conséquence.
La même fissure est apparue dans la chaîne d'approvisionnement logicielle.
Dans la campagne Mini Shai-Hulud, des versions compromises de paquets se sont propagées dans certaines parties de l'écosystème npm et PyPI, y compris des paquets Mistral AI, TanStack, UiPath, et d'autres.
L'avertissement n'était pas seulement que des paquets peuvent être compromis.
Tout le monde le sait déjà.
L'avertissement était que des chemins de publication de confiance, des paquets d'apparence valide et une infrastructure de développement peuvent devenir des canaux de propagation une fois que l'autorité est héritée au lieu d'être revérifiée à la frontière.
Le sophisme se cumule
Le pire est que cela ne se corrige pas tout seul.
Les humains utilisent désormais des agents pour construire la prochaine génération d'outils pour les agents,
à plus grande vitesse,
dans le même cadre brisé.
Chaque agent de codage qui écrit un serveur MCP.
Chaque déploiement assisté par IA d'un schéma d'autorisation.
Chaque échafaudage codé à la vibe poussé en production.
Chaque intégration générée par agent qui hérite d'anciennes hypothèses OAuth.
Chaque couche d'approbation qui suppose que l'agent se comportera comme un demandeur humain.
Dans l'un de nos propres environnements bêta, nous avons observé un essaim d'agents blanchir des instructions malveillantes en étapes d'exécution d'apparence propre avant que les couches d'inspection en aval ne voient l'intention originale.
Un système inspectant uniquement l'appel d'outil final aurait manqué la transformation entièrement.
La frontière était déjà trop tard.
Cela comptait.
Parce que le modèle ne « cassait » pas le workflow.
Il le suivait :
interpréter,
réécrire,
planifier,
et traduire l'intention avant l'exécution.
L'instruction malveillante avait disparu en amont bien avant que l'action irréversible n'apparaisse en aval.
Chaque journal d'audit qui enregistre le résultat mais pas la décision de frontière avant le résultat.
Le cadre ne se corrige pas à mesure que nous passons à l'échelle.
Il se durcit.
Parce que chaque livraison réussie de rails à travers le prisme humain renforce la croyance que le prisme était juste.
Pendant ce temps, les capacités sont livrées en premier.
Les primitives de gouvernance sont livrées en second.
Si elles le sont un jour.
L'écart entre ce que les agents peuvent faire et ce que les rails environnants peuvent voir se creuse à chaque publication de modèle.
Et les équipes qui compteront au cours des douze prochains mois ne seront pas celles avec la démo la plus astucieuse.
Elles seront celles qui comprennent où se situent les lignes rouges.
Pas toutes les actions.
Cela tuerait le système.
La plupart des comportements des agents devraient couler.
Mais les actions irréversibles ne peuvent pas être laissées à la confiance héritée,
à une autorisation vague,
ou au jugement de l'agent.
Transférer des fonds.
Toucher la production.
Exporter des données clients.
Utiliser un accès OAuth délégué pour entrer dans un environnement interne.
Modifier l'infrastructure.
Divulguer des secrets.
Approuver des transactions.
Supprimer des enregistrements.
Passer de la simulation à l'état.
Ce ne sont pas des actions ordinaires.
Ce sont des lignes rouges.
Ce que fait Atbash
Atbash est conçu pour le moment avant qu'une action sensible d'agent ne devienne réelle.
C'est la frontière.
Pas tout le workflow.
Pas chaque pensée.
Pas chaque jeton.
Pas chaque appel d'outil.
La frontière.
Le moment avant que l'agent ne passe de l'intention à la conséquence.
Trois choses se produisent là.
Application
Vous définissez les lignes rouges.
Atbash évalue les actions sensibles sélectionnées des agents avant exécution et renvoie :
AUTORISER.
SUSPENDRE.
BLOQUER.
Si l'action franchit une frontière interdite, elle peut être mise en cage avant d'atteindre l'état réel.
Pas enregistrée après coup.
Pas refusée pour que l'agent puisse réessayer autrement.
Mise en cage.
Tu ne toucheras pas à la base de données de production.
Tu ne transféreras pas de fonds au-dessus de ce seuil.
Tu n'exporteras pas la liste des clients.
Tu ne feras pas tourner les secrets sans approbation.
Tu n'utiliseras pas un accès délégué pour entrer dans cet environnement.
La plupart des comportements des agents devraient couler.
Atbash n'intervient qu'aux frontières qui comptent :
l'irréversible,
le conséquent,
les endroits où « laissez-moi annuler cela » n'existe pas.
Traçabilité
Quand quelque chose tourne mal, la première question n'est plus :
« Que prétend le système compromis qu'il s'est passé ? »
Atbash enregistre l'action tentée,
la version de la politique,
le verdict,
la frontière invoquée,
et la décision de l'opérateur lorsque des humains sont impliqués.
L'enregistrement est ancré cryptographiquement pour que la chronologie puisse être reconstruite en cas de litige.
C'est important parce que la première chose que les attaquants et les déploiements bâclés font est de détruire l'histoire.
Ils réécrivent les journaux.
Ils brouillent les chronologies.
Ils contestent qui a approuvé quoi.
Ils rendent l'incident non reconstructible.
Atbash n'essaie pas de remplacer tous les systèmes d'audit.
Il essaie de rendre la décision de frontière prouvable.
Qui a essayé de franchir quelle ligne rouge ?
Quelle politique existait à ce moment ?
L'action a-t-elle été autorisée,
suspendue,
bloquée,
ou mise en cage ?
Qui est intervenu ?
Qu'a changé après ?
C'est l'enregistrement qui compte quand la dispute commence.
Adaptation
Quand le même type de pression de frontière apparaît encore et encore, Atbash le fait remonter.
Peut-être que la politique est trop lâche.
Peut-être qu'un outil empoisonne le workflow.
Peut-être qu'une source de mémoire pousse l'agent vers la ligne.
Peut-être qu'une classe de prompts oriente constamment le système en territoire interdit.
Peut-être que l'opérateur a découvert une nouvelle ligne rouge qui n'existait pas hier.
Atbash fait remonter le schéma.
L'opérateur décide.
Cette distinction compte.
Nous ne croyons pas que la sécurité vient de la prétention que le système peut magiquement connaître chaque future frontière.
La sécurité vient du fait de rendre la pression de frontière visible avant la conséquence,
puis de laisser l'opérateur durcir les lignes rouges qui comptent.
Un meilleur moteur de politique applique encore des politiques.
Un meilleur schéma d'autorisation accorde encore des rôles.
Une meilleure pile d'audit enregistre encore les résultats.
Un meilleur produit de sécurité détecte encore les menaces.
Atbash est différent parce qu'il se situe avant que certaines actions irréversibles sélectionnées ne s'exécutent.
C'est la primitive.
Pas une gouvernance générique.
Pas un déguisement de sécurité d'agent.
Pas un brouillard de « couche de confiance ».
Une frontière de ligne rouge avant exécution pour les agents.
Vous définissez les lignes rouges.
Atbash arrête les agents avant qu'ils ne les franchissent.
Ce qui vient ensuite
Quelques équipes de superstars font un vrai travail et ont de vraies initiatives dans cette catégorie.
@AnthropicAI avec Project Glasswing.
@OpenAI avec Daybreak.
@linuxfoundation avec MCP.
@Microsoft avec AGT.
@Google avec SGP.
@CheckPointSW, CrowdStrike, Palo Alto, et Cisco.
Et bien d'autres.
Ils comprennent que l'accélération des capacités sans nouvelles primitives de contrôle devient dangereuse.
Nous n'essayons pas de les battre à leur propre jeu.
Ce serait illusoire.
Ils ont des bancs de recherche plus profonds,
des ensembles de données plus grands,
des équipes de sécurité plus larges,
plus de crédibilité en entreprise,
une distribution plus large,
et des organisations cyber plus matures.
Tant mieux.
Laissez-les faire ce pour quoi ils sont faits.
Nous n'essayons pas de remplacer le travail que ces équipes font.
La catégorie a besoin d'eux.
L'accélération des capacités sans nouvelles primitives de contrôle devient très vite dangereuse.
Nous sommes en compétition sur le cadre.
Quel type d'acteur est un agent ?
Où réside réellement l'autorité ?
Quelles actions sont trop lourdes de conséquences pour être laissées à la confiance héritée ?
Que devrait-il se produire au dernier moment avant qu'un agent ne change l'état du monde réel ?
C'est notre terrain.
Le vieux monde demande :
Le système avait-il la permission ?
Le nouveau monde demande :
Cet agent devrait-il être autorisé à franchir cette ligne rouge maintenant ?
Ce ne sont pas les mêmes questions.
Nous, les humains, avons franchi la première ligne rouge.
Le problème est plus ancien que la technologie.
La solution aussi.
Identifiez les lignes rouges que votre pile actuelle ne peut pas réellement appliquer avant qu'un agent ne les franchisse.
Puis décidez combien de temps vous pouvez attendre.
Le CLI, le tableau de bord de l'opérateur sont désormais déployés de manière sélective auprès des équipes qui déploient des agents dans des workflows sensibles.
Atbash.ai
