Résumé
L’intelligence artificielle entre dans une nouvelle phase.
Les grands modèles de langage ne se contentent plus de produire du texte, des images ou du code. Ils savent naviguer sur internet, retrouver de l’information, piloter des logiciels, appeler des API, modifier des fichiers, déployer du code, dialoguer avec les systèmes de l’entreprise et, de plus en plus, agir pour le compte de personnes et d’organisations.
Cette transition crée un problème de sécurité fondamental.
Plus un système d’IA devient capable, plus il est utile de lui donner la possibilité d’agir.
Mais plus on donne d’autorité à un système probabiliste, plus les conséquences sont lourdes lorsque ce système se trompe, se fait manipuler, se fait compromettre ou se comporte simplement d’une manière que l’on n’avait pas anticipée.
La réponse actuelle de la filière est considérable et nécessaire :
- améliorer les modèles ;
- renforcer les protections ;
- introduire des permissions ;
- placer les agents dans des sandbox ;
- surveiller les comportements ;
- restreindre l’accès au réseau ;
- établir des identités ;
- exiger des approbations ;
- contenir les défaillances.
Ces mécanismes ont de la valeur.
Mais ils abordent tous le problème, pour l’essentiel, sous le même angle :
Comment rendre un agent d’IA assez sûr pour exercer une autorité ?
ZIFFER propose de poser une question plus fondamentale :
Pourquoi l’intelligence aurait-elle besoin de détenir une autorité ?
Un système d’IA peut formuler une intention sans être autorisé à l’exécuter.
Il peut raisonner sans détenir une autorité sans limite.
Il peut proposer une action sans avoir le pouvoir de la faire advenir.
D’où un principe d’architecture très simple :
L’intelligence n’est pas l’autorité.
Et de ce principe en découle un autre :
L’intention et l’autorité doivent être séparées.
Dans ce modèle, l’IA produit une proposition structurée, l’expression de ce qu’elle estime devoir arriver. Une couche d’autorisation distincte détermine si cette proposition est permise au regard de la politique, du contexte, de l’identité, du risque et d’autres conditions. Une couche d’exécution distincte n’effectue ensuite que ce qui a été autorisé.
L’objectif n’est pas de rendre le modèle infaillible.
Il est de garantir que :
La faillibilité du modèle ne devienne pas automatiquement une conséquence non autorisée dans le monde réel.
Cette prise de position défend l’idée que cette séparation doit devenir un principe de conception fondamental de l’IA autonome.
1. Le nouveau problème de l’IA
Pendant des années, l’interface principale avec l’intelligence artificielle était simple :
Humain → IA → Réponse
L’IA produisait de l’information.
Si la réponse était fausse, un humain pouvait la rejeter.
Les conséquences se limitaient généralement à l’information elle-même.
L’IA agentique change cette relation :
Humain → IA → Action → Conséquence dans le monde réel
L’IA peut désormais :
- envoyer un courriel ;
- modifier une base de données ;
- créer ou supprimer des fichiers ;
- déployer un logiciel ;
- acheter quelque chose ;
- modifier une infrastructure ;
- accéder à des informations confidentielles ;
- communiquer avec des clients ;
- déclencher des opérations financières ;
- piloter des systèmes industriels ;
- appeler d’autres agents ;
- déléguer des tâches à d’autres systèmes.
La distance entre ce que le modèle pense et ce qui arrive dans le monde ne cesse de se réduire.
Cela crée un problème d’architecture inédit.
Une hallucination dans un chatbot est d’ordinaire un problème de qualité de l’information.
Une hallucination dans un agent autonome peut devenir un problème d’autorisation.
Une instruction manipulée dans un chatbot peut produire une mauvaise réponse.
La même manipulation dans un agent peut devenir une exfiltration de données, une transaction non autorisée ou une panne en production.
La question n’est donc plus seulement :
Peut-on rendre le modèle plus exact ?
Elle devient :
Que se passe-t-il lorsqu’une intelligence imparfaite est reliée à une autorité qui a des conséquences ?
2. La filière répond déjà
Ce n’est pas une critique de l’état actuel de la sécurité de l’IA.
La filière consacre des efforts considérables à résoudre ce problème.
OpenAI développe des contrôles de sécurité pour les agents autour de la sandbox, des approbations, des restrictions réseau, de l’identité, des identifiants et de la télémétrie (OpenAI, Agent approvals and security).
Anthropic met de plus en plus l’accent sur le confinement. Ses travaux d’ingénierie distinguent explicitement la réduction de la probabilité d’une défaillance et la réduction des dommages possibles lorsque la défaillance survient. Anthropic reconnaît aussi que les défenses probabilistes ont un taux d’échec non nul (Anthropic, mai 2026).
Le NIST conduit des travaux de normalisation sur l’identité, l’autorisation, l’audit et la non-répudiation des agents d’IA (NIST NCCoE, Software and AI Agent Identity and Authorization).
NVIDIA a explicitement décrit une architecture dans laquelle les couches hautes proposent les actions tandis que les couches basses de l’infrastructure prennent les décisions qui font autorité (NVIDIA, Where Security Fits in an AI Agent Stack).
La filière avance donc déjà vers un constat important :
Le comportement d’un modèle ne peut pas, à lui seul, constituer une frontière de sécurité suffisante.
ZIFFER ne prétend pas le contraire.
ZIFFER demande plutôt ce qui se passe si l’on pousse ce constat jusqu’à sa conclusion logique.
3. La question derrière la question
La question d’ingénierie dominante a été :
Comment rendre les agents assez sûrs pour agir ?
ZIFFER demande :
Pourquoi l’intelligence elle-même devrait-elle être ce qui agit ?
La distinction peut sembler sémantique.
Elle ne l’est pas.
Prenons un salarié.
Un salarié peut dire :
« Je veux virer 500 000 € à ce fournisseur. »
Cette phrase exprime une intention.
Elle ne constitue pas automatiquement une autorité.
Le salarié peut avoir besoin :
- d’une fonction adaptée ;
- d’une approbation ;
- d’un plafond de dépense ;
- d’un bon de commande valide ;
- d’une séparation des tâches ;
- d’un fournisseur valide ;
- d’une politique de transaction ;
- d’une seconde autorisation.
Que le salarié sache formuler la demande ne lui donne pas le droit de l’exécuter.
Les organisations modernes ont passé des décennies à séparer ces notions.
Les systèmes d’IA les confondent de plus en plus.
4. La confusion fondamentale
Un système agentique contient plusieurs notions distinctes.
L’intelligence
La capacité d’interpréter l’information, de raisonner, de planifier et de produire des réponses.
L’intention
Une représentation de ce que le système propose de faire arriver.
L’autorisation
La décision qu’une action donnée est permise.
L’exécution
La modification effective du monde extérieur.
Ce ne sont pas les mêmes choses.
Pourtant, à mesure que les agents d’IA gagnent en capacité, ces notions sont de plus en plus reliées :
Modèle → Outil → Système → Conséquence
ZIFFER propose une séparation délibérée :
Modèle → Intention → Autorisation → Exécution
La différence est fondamentale.
Le modèle reste responsable de l’intelligence.
Il ne devient pas la source de l’autorité.
5. L’intelligence est probabiliste
Les grands modèles de langage sont des systèmes extraordinairement puissants.
Mais ce ne sont pas des moteurs de règles déterministes.
Ils infèrent.
Ils prédisent.
Ils raisonnent de façon probabiliste.
Ils travaillent sur une information incomplète.
Ils peuvent mal comprendre un contexte.
Ils peuvent halluciner.
Ils peuvent être manipulés.
Ils peuvent rencontrer des entrées adverses.
Ils peuvent se comporter de manière inattendue devant des combinaisons d’informations inédites.
Une capacité accrue du modèle peut réduire beaucoup de catégories d’erreurs.
Elle ne peut pas transformer une intelligence probabiliste en un mécanisme d’autorité infaillible.
D’où une observation de sécurité importante :
P(erreur) ne devient pas nulle du seul fait que le modèle devient plus capable.
La réponse traditionnelle consiste donc à réduire :
P(erreur)
autant que possible.
ZIFFER propose un second objectif :
Empêcher que l’erreur devienne automatiquement une conséquence.
Autrement dit :
P(erreur) > 0 n’a pas besoin d’impliquer P(exécution non autorisée) > 0.
C’est à l’architecture de créer cette séparation.
6. Cessons de demander au modèle d’être assez digne de confiance
C’est le basculement philosophique central.
L’approche traditionnelle est :
Rendre le modèle plus sûr.
Puis :
Lui donner plus de capacités.
Puis :
Ajouter davantage de contrôles autour de ces capacités.
Puis :
Lui donner plus d’autorité à mesure que la confiance grandit.
ZIFFER propose une autre séquence :
Construire une intelligence puissante.
Accepter que cette intelligence reste faillible.
La laisser produire des intentions.
Placer l’autorité ailleurs.
Cela fait passer la question de sécurité de :
« Peut-on faire confiance à l’agent ? »
à :
« Le système peut-il rester sûr même lorsqu’on ne peut pas faire confiance à l’agent ? »
C’est une propriété beaucoup plus forte.
Elle n’exige pas de supposer que l’agent est malveillant.
L’agent peut être :
- serviable ;
- honnête ;
- très capable ;
- aligné ;
- entraîné avec soin ;
et rester malgré tout en dehors de la frontière ultime de l’autorité.
Car la compromission n’est pas le seul problème.
L’architecture doit aussi tenir compte :
- des malentendus ;
- d’un contexte périmé ;
- d’instructions ambiguës ;
- d’interactions imprévues ;
- de l’injection de prompt ;
- de données malveillantes ;
- de vulnérabilités logicielles ;
- d’erreurs de configuration ;
- de comportements émergents ;
- des défaillances d’agents délégués.
La confiance n’est pas une primitive de sécurité suffisante dans ces conditions.
7. L’intention n’est pas l’autorité
Prenons un exemple simple.
Un agent d’IA reçoit :
« Prépare les paiements fournisseurs du mois. »
L’agent analyse les factures et propose :
Fournisseur A : 40 000 €
Fournisseur B : 72 000 €
Fournisseur C : 18 000 €
Voilà l’intention.
L’agent a produit un ensemble d’actions proposées.
Considérons maintenant deux architectures.
Architecture A : couplée
L’agent détient les identifiants.
L’agent appelle l’API de paiement.
L’API exécute la demande.
Le système de sécurité tente de déterminer si le comportement de l’agent est sûr.
Architecture B : séparée
L’agent produit une proposition de paiement canonique.
La proposition est soumise à une couche d’autorisation indépendante.
La couche d’autorisation évalue :
- qui est à l’origine de la demande ;
- ce que l’agent a le droit de faire ;
- la ressource concernée ;
- le montant de la transaction ;
- la politique de l’organisation ;
- les conditions contextuelles ;
- les approbations requises ;
- la classification du risque ;
- la fraîcheur ;
- si la proposition a déjà été autorisée ou consommée.
Ce n’est qu’ensuite qu’une capacité d’exécution est créée.
L’exécuteur effectue l’opération autorisée.
L’agent lui-même n’a jamais détenu l’autorité d’effectuer la transaction.
Voilà la séparation d’architecture que ZIFFER propose.
8. L’agent ne doit pas pouvoir s’autoriser lui-même
Cela paraît évident une fois énoncé.
Mais les conséquences sont profondes.
Un agent ne doit pas pouvoir raisonner ainsi :
« J’ai décidé que c’était nécessaire, donc je suis autorisé à le faire. »
Cela revient à laisser un composant logiciel définir ses propres permissions.
La décision d’autorisation doit exister en dehors de l’intelligence qui a produit la proposition.
L’agent peut demander une autorité.
Il ne peut pas la fabriquer.
Il ne peut pas augmenter ses propres privilèges.
Il ne peut pas redéfinir la politique qui le gouverne.
Il ne peut pas transformer en autorité une instruction contenue dans des données non fiables au seul motif que le modèle a jugé cette instruction légitime.
C’est un principe familier de la sécurité classique.
ZIFFER l’applique directement à l’intelligence autonome.
9. Pourquoi l’identité seule ne suffit pas
La sécurité des agents d’IA s’intéresse de plus en plus à l’identité.
C’est nécessaire.
Nous devons savoir :
Quel agent est à l’origine de cette demande ?
Mais l’identité ne répond qu’à une question :
Qui es-tu ?
L’autorisation en pose une autre :
Qu’as-tu le droit de faire ?
Et ZIFFER en ajoute une troisième :
Es-tu autorisé à effectuer exactement cette action, dans exactement ce contexte, sous exactement cette politique ?
Un agent authentifié peut malgré tout être :
- compromis ;
- surprivilégié ;
- manipulé ;
- en train de travailler sur une information périmée ;
- en train d’agir en dehors de l’intention réelle de l’utilisateur.
Par conséquent :
Identité ≠ Intention
Identité ≠ Autorisation
Autorisation ≠ Exécution
Ces distinctions deviennent d’autant plus importantes que les systèmes d’IA opèrent sur des horizons de temps plus longs.
10. Le problème de l’approbation humaine
L’approbation humaine semble résoudre le problème.
Si l’IA demande :
« Puis-je envoyer ce courriel ? »
l’humain peut dire oui ou non.
Dans un flux de travail simple, cela peut être très efficace.
Mais les systèmes autonomes peuvent produire un nombre considérable de décisions.
L’approbation humaine ne passe pas indéfiniment à l’échelle.
La télémétrie de Claude Code publiée par Anthropic en donne un exemple frappant : les utilisateurs approuvaient environ 93 % des demandes de permission. Anthropic décrit explicitement le phénomène qui en résulte comme une approval fatigue, une fatigue d’approbation : à force de voir revenir les mêmes demandes, les utilisateurs prêtent moins d’attention à chacune (Anthropic, mars 2026).
Anthropic a également observé que les utilisateurs expérimentés de Claude Code accordent de plus en plus d’autonomie au système, l’approbation automatique complète apparaissant dans plus de 40 % des sessions chez les utilisateurs les plus aguerris de son analyse.
Ce n’est pas la preuve que les utilisateurs sont négligents.
C’est la preuve d’un problème structurel :
Un mécanisme de sécurité qui oblige des humains à prendre sans cesse des décisions d’autorisation de bas niveau finit par entrer en concurrence avec l’attention humaine.
Et l’attention humaine est une ressource finie.
11. Une menace nouvelle : la fatigue de l’autorité
ZIFFER introduit la notion de :
Fatigue de l’autorité
Définition
La fatigue de l’autorité est la dégradation de la qualité des autorisations provoquée par le volume, la répétition, la complexité ou la prévisibilité des demandes d’autorisation qu’un système autonome produit.
Un humain peut, au début, examiner chaque demande avec soin.
Mais à mesure que le nombre de demandes augmente, il commence à reconnaître un motif :
« Cela ressemble à la même chose que la dernière fois. »
La décision d’autorisation devient peu à peu un réflexe.
Le processus de sécurité reste formellement en place.
Mais la qualité de la décision s’est détériorée.
Cela crée une illusion dangereuse :
Le système a toujours l’approbation d’un humain, donc il reste sous contrôle humain.
Pas nécessairement.
12. La chaîne d’attaque de la fatigue de l’autorité
Le phénomène peut se représenter ainsi :
L’autonomie de l’agent augmente
↓
Le nombre de demandes d’autorisation augmente
↓
La charge cognitive humaine augmente
↓
La qualité de l’examen individuel diminue
↓
L’approbation devient un réflexe
↓
L’attention se déplace de l’autorisation vers l’intervention
↓
Une action anormale devient plus difficile à remarquer
↓
Une action malveillante ou non voulue reçoit une autorisation légitime
L’attaquant n’a pas nécessairement besoin de vaincre le mécanisme d’autorisation.
Il peut au contraire exploiter le processus humain qui entoure l’autorisation.
C’est fondamentalement différent du simple contournement d’un contrôle de permission.
Le contrôle de permission reste techniquement intact.
C’est le sens de l’approbation qui s’est dégradé.
13. Pourquoi cela compte pour le modèle MITRE ATLAS
MITRE ATLAS reconnaît déjà plusieurs risques voisins.
Ses documents identifient l’Excessive Agency, l’agentivité excessive, comme une situation où des composants d’IA disposent de capacités, de permissions ou d’une autorité non contrôlées dont ils n’ont pas besoin, et recommandent de limiter les capacités et de mettre en œuvre l’autorisation dans les systèmes en aval. Ils citent également l’approbation humaine comme mesure d’atténuation possible.
ATLAS comprend aussi la technique User Execution, l’exécution par l’utilisateur, et d’autres techniques liées aux agents et aux outils dans sa base de connaissances.
La fatigue de l’autorité ne doit donc pas être présentée comme si le problème sous-jacent de l’agentivité excessive ou de l’implication de l’utilisateur était absent d’ATLAS.
L’observation exacte est la suivante :
La dégradation de l’autorisation humaine causée par la répétition des demandes d’approbation produites par un agent n’est pas représentée aujourd’hui comme une technique de menace distincte et autonome.
Cette distinction compte.
ATLAS décrit l’existence de risques d’autorisation et d’agentivité excessive.
ZIFFER identifie une manière particulière dont le mécanisme d’autorisation lui-même peut devenir de moins en moins fiable à mesure que l’autonomie de l’agent augmente.
Cela mérite un traitement explicite.
14. La fatigue de l’autorité n’est pas un simple problème d’ergonomie
On pourrait d’abord y voir un problème d’utilisabilité.
Ce n’est pas seulement cela.
Supposons qu’un système demande une approbation 500 fois.
Si l’utilisateur en approuve 495, le système peut en conclure :
« L’humain approuve presque tout. »
Mais l’interprétation en sécurité devrait être différente :
L’humain ne fonctionne peut-être plus comme un contrôle d’autorisation efficace.
Cela crée une boucle de rétroaction dangereuse.
Plus d’autonomie produit plus de demandes.
Plus de demandes produit plus de fatigue.
Plus de fatigue produit plus d’approbations automatiques.
Plus d’approbations justifie plus d’autonomie.
Plus d’autonomie produit encore plus de demandes.
Le système peut donc dériver vers une exécution de fait autonome tout en conservant l’apparence d’une autorisation humaine.
15. Le problème du remplacement des humains par des modèles
La filière explore déjà des moyens d’alléger cette charge.
Le mode auto de Claude Code délègue une partie des décisions d’approbation à des classificateurs fondés sur un modèle, et Anthropic le présente explicitement comme un moyen de réduire la fatigue d’approbation (Anthropic, mars 2026).
C’est une réponse d’ingénierie raisonnable.
Mais elle soulève une question d’architecture plus profonde :
Si l’humain ne peut pas évaluer chaque décision, faut-il qu’un autre système probabiliste devienne l’autorité à sa place ?
Cela n’élimine pas nécessairement le problème de fond.
Cela transforme :
l’approbation humaine
en :
l’approbation par un modèle
Les deux peuvent être utiles.
Ni l’une ni l’autre ne doit devenir la source ultime de l’autorité au seul motif que l’alternative est inconfortable.
La proposition de ZIFFER est différente :
Réduire le nombre de décisions qui exigent une approbation individuelle en établissant une autorité bornée, indépendamment de l’agent.
16. De l’humain dans la boucle à l’autorité définie par l’humain
C’est une distinction décisive.
Modèle traditionnel
Agent → demande à l’humain → l’humain approuve → l’agent exécute
L’humain devient un mécanisme d’autorisation répété.
Modèle ZIFFER
Humain ou organisation → établit les frontières de l’autorité
↓
Agent → propose une action
↓
Couche d’autorisation → évalue l’action au regard de l’autorité
↓
Exécuteur → exécute si l’action est autorisée
L’humain reste indispensable.
Mais son rôle change.
Au lieu d’être un bouton que l’on presse des milliers de fois, l’humain établit :
- ce que l’agent peut faire ;
- ce qu’il ne doit jamais faire ;
- à quelles ressources il peut accéder ;
- dans quelles conditions ;
- dans quelles limites ;
- quand une approbation supplémentaire est nécessaire.
La machine applique ensuite ces frontières.
C’est une forme de contrôle humain bien plus apte à passer à l’échelle.
17. L’approbation doit porter sur l’autorité, pas sur chaque action
D’où un principe :
Chaque fois que c’est possible, l’approbation humaine doit autoriser des changements d’autorité plutôt que valider mécaniquement chaque action de routine à l’intérieur d’une autorité déjà accordée.
Par exemple.
Au lieu de :
« Puis-je lire cette fiche client ? »
« Puis-je lire la fiche client suivante ? »
« Puis-je modifier ce champ ? »
« Puis-je modifier le champ suivant ? »
l’organisation établit :
« Cet agent peut lire les fiches clients du jeu de données X pour la finalité Y. »
Le système d’autorisation applique cette frontière.
L’intervention humaine devient nécessaire lorsque l’agent demande quelque chose qui sort de l’autorité établie.
C’est toute la différence entre :
l’approbation des actions
et
la définition de l’autorité.
18. Le problème des garde-fous
Les garde-fous ont de la valeur.
Ils peuvent empêcher les modèles de produire certaines sorties.
Ils peuvent détecter des comportements suspects.
Ils peuvent orienter le raisonnement.
Ils peuvent repérer une injection de prompt.
Ils peuvent refuser des demandes.
Mais un garde-fou est en général un contrôle comportemental.
Il influence ce que l’intelligence fait.
Une frontière de sécurité, c’est autre chose.
Elle détermine ce que l’intelligence peut faire.
La distinction est de mieux en mieux reconnue dans les architectures d’agents modernes : les contrôles comportementaux peuvent influencer un agent, tandis que les contrôles au niveau de l’infrastructure peuvent imposer ce à quoi l’agent est réellement capable d’accéder ou ce qu’il est capable d’exécuter (NVIDIA, Where Security Fits in an AI Agent Stack).
Cette distinction est centrale pour ZIFFER.
Un système ne doit pas dépendre uniquement du fait qu’un composant intelligent obéisse volontairement à la règle qui protège ce système.
La règle doit exister en dehors du composant.
19. Le problème de la détection
La détection pose la question :
Est-ce que quelque chose de grave s’est produit ?
C’est extrêmement utile pour la réponse à incident.
Mais la détection est par nature située en aval.
Si un agent d’IA peut exécuter une action non autorisée et que le système de sécurité la détecte après coup, le système a peut-être déjà subi la conséquence.
ZIFFER donne donc la priorité à la prévention par la séparation de l’autorité.
La question devient :
L’action peut-elle s’exécuter sans passer par la frontière d’autorisation ?
Si la réponse est non, la compromission de l’intelligence n’implique pas automatiquement la compromission de l’exécution.
La détection reste importante.
Mais elle devient un élément de la défense en profondeur plutôt que le mécanisme d’autorité principal.
20. Le problème du kill switch
Un kill switch est utile.
Mais un kill switch suppose que :
- le système détecte le problème ;
- quelqu’un ou quelque chose actionne l’interrupteur ;
- l’interrupteur atteigne l’agent ;
- l’agent s’arrête avant d’avoir causé des conséquences inacceptables.
ZIFFER introduit une autre propriété.
Il n’est pas nécessaire d’arrêter l’agent s’il n’a jamais détenu l’autorité nécessaire pour effectuer l’opération non autorisée.
Un agent malveillant ou compromis peut continuer à produire des propositions.
La couche d’autorisation peut simplement les refuser.
D’où une distinction importante :
Arrêter l’intelligence n’est pas la même chose que contrôler l’autorité.
21. L’analogie biologique
L’inspiration conceptuelle de ZIFFER vient en partie de la biologie.
Une cellule vivante ne suppose pas que toute molécule qui s’approche d’elle est digne de confiance.
Elle dispose au contraire :
- de frontières ;
- de membranes ;
- de récepteurs ;
- d’un transport contrôlé ;
- de compartiments ;
- de mécanismes de signalisation ;
- de points de contrôle ;
- de contrôles des ressources ;
- de mécanismes pour contenir les dommages.
La cellule ne rend pas chaque signal digne de confiance.
Elle contrôle ce que ce signal est autorisé à provoquer.
C’est un modèle puissant pour les logiciels autonomes.
Un agent d’IA reçoit d’énormes quantités d’informations.
Certaines peuvent être fiables.
Certaines peuvent être fausses.
Certaines peuvent être malveillantes.
Certaines peuvent être ambiguës.
Certaines peuvent être délibérément conçues pour manipuler l’agent.
L’objectif n’a pas besoin d’être la classification parfaite de chaque signal.
Le système peut au contraire établir une frontière :
L’information peut influencer l’intention.
L’information n’acquiert pas automatiquement une autorité.
C’est le principe biologique traduit en architecture logicielle.
22. L’autonomie n’implique pas l’autorité
L’une des conséquences les plus importantes de cette architecture est une redéfinition de l’autonomie.
Aujourd’hui, l’autonomie s’entend souvent ainsi :
Le système peut prendre des décisions et les exécuter sans demander à un humain.
ZIFFER propose une définition plus précise :
Un système autonome est capable de poursuivre des objectifs sans intervention humaine continue ; il n’a pas nécessairement besoin d’une autorité sans limite pour cela.
Un agent autonome peut :
- observer ;
- raisonner ;
- planifier ;
- proposer ;
- négocier ;
- demander une autorisation ;
- exécuter les opérations autorisées ;
- apprendre des résultats.
L’agent peut donc être très autonome tout en restant borné par un système d’autorité indépendant.
Cela permet d’augmenter l’intelligence sans augmenter automatiquement le privilège.
23. Plus d’intelligence ne doit pas vouloir dire plus d’autorité
C’est peut-être la conséquence la plus contre-intuitive de ZIFFER.
La trajectoire classique est :
Modèle plus capable
↓
Agent plus utile
↓
Plus d’outils
↓
Plus de permissions
↓
Plus d’autonomie
ZIFFER propose :
Modèle plus capable
↓
Intelligence plus utile
↓
Meilleures propositions
↓
Autorisation indépendante
↓
Exécution contrôlée
Le modèle peut devenir bien plus intelligent sans acquérir une autorité équivalente.
Ce découplage pourrait devenir de plus en plus important à mesure que les systèmes d’IA gagnent en capacité.
24. Ce vers quoi la filière commence à converger
ZIFFER ne doit pas faire croire que ce concept est né isolément.
Un mouvement net porte déjà vers des contrôles de sécurité externalisés.
NVIDIA a explicitement décrit une architecture où les couches hautes proposent les actions et où les couches basses de l’infrastructure prennent les décisions qui font autorité (NVIDIA, Where Security Fits in an AI Agent Stack).
OpenAI construit des environnements d’agents dotés de sandbox, de permissions, de contrôles réseau, d’identité et d’identifiants (OpenAI, Agent approvals and security).
Anthropic met de plus en plus l’accent sur le confinement et la réduction du rayon d’impact, en reconnaissant explicitement que les défenses probabilistes ont un taux d’échec non nul (Anthropic, mai 2026).
Le NIST examine l’identité et l’autorisation comme des infrastructures fondatrices pour les agents d’IA (NIST NCCoE, Software and AI Agent Identity and Authorization).
La direction prise est donc importante :
La filière éloigne progressivement l’autorité du modèle.
La thèse de ZIFFER est que cette séparation ne doit pas rester un détail de mise en œuvre.
Elle doit devenir un principe d’architecture de premier rang.
25. De la sécurité des agents à l’architecture de l’IA
Cette distinction compte sur le plan stratégique.
Si l’on décrit simplement ZIFFER comme de la :
sécurité des agents d’IA
il entre dans un marché en expansion rapide fait :
- de pare-feu pour IA ;
- de protections contre l’injection de prompt ;
- de supervision d’agents ;
- de gestion des identités ;
- de sécurité à l’exécution ;
- de gouvernance ;
- de moteurs de politiques ;
- d’EDR ;
- de sécurité du cloud ;
- de plateformes de sécurité de l’IA.
La thèse de ZIFFER est plus large.
Elle demande si l’architecture de l’IA autonome elle-même doit changer.
L’abstraction fondamentale devient :
l’intelligence
est séparée de
l’intention
qui est séparée de
l’autorité
qui est séparée de
l’exécution.
La sécurité devient alors une propriété d’architecture plutôt qu’une couche ajoutée autour d’un agent une fois celui-ci construit.
26. Un nouvel objectif de sécurité
La sûreté de l’IA cherche fréquemment à améliorer :
la fiabilité du modèle
La cybersécurité classique cherche à réduire :
les accès non autorisés
ZIFFER combine ces idées autrement.
Il propose que l’objectif de sécurité central de l’IA autonome soit :
Une intelligence erronée ou compromise ne doit pas obtenir automatiquement l’autorité de produire une action non autorisée ayant des conséquences.
Cela produit une autre équation du risque.
Plutôt que de compter d’abord sur :
une faible probabilité d’erreur du modèle
nous visons :
une faible probabilité que l’erreur du modèle devienne une conséquence non autorisée.
Cette distinction compte parce qu’elle reste utile même lorsque le modèle change.
Un nouveau modèle peut se comporter autrement.
Un nouveau cadre d’agents peut se comporter autrement.
Un nouveau système d’orchestration peut se comporter autrement.
Mais si tous les effets ayant des conséquences doivent franchir la même frontière d’autorisation, la propriété de sécurité demeure.
27. Le principe d’architecture
ZIFFER peut donc s’exprimer en une phrase :
L’IA peut déterminer ce qu’elle veut faire ; l’IA ne doit pas déterminer si elle y est autorisée.
Cela ne veut pas dire qu’il faut empêcher l’IA de raisonner sur la politique.
Un agent peut avoir besoin de comprendre la politique pour bien planifier.
Mais sa compréhension de la politique est consultative.
La politique qui fait autorité existe en dehors de l’intelligence.
Cette distinction est cruciale.
Un agent peut dire :
« Je crois que cette action est permise. »
Le système d’autorisation détermine de façon indépendante :
« Cette action est permise. »
Ces deux phrases ne doivent jamais devenir équivalentes au seul motif qu’elles proviennent de la même intelligence.
28. L’intention doit devenir explicite
Séparer l’intention de l’autorité exige aussi de rendre l’intention explicite.
Une instruction en langage naturel est ambiguë.
Pour les opérations à conséquences, le système doit transformer l’intention en une représentation canonique.
Par exemple.
Demande humaine
« Paie le fournisseur. »
devient quelque chose de plus proche de :
Action
PAYMENT
Cible
SUPPLIER-123
Montant
72 000 €
Devise
EUR
Compte
ACCOUNT-456
Origine
REQUEST-789
Objet
INVOICE-2026-0817
Le point important est que la décision d’autorisation ne porte pas sur une conversation vague.
Elle porte sur une action proposée précise.
Cela crée un objet stable que l’on peut :
- évaluer ;
- autoriser ;
- contraindre ;
- auditer ;
- signer ;
- vérifier ;
- exécuter ;
- consigner.
La proposition devient le pont entre l’intelligence et l’autorité.
29. L’autorisation doit suivre l’action
Une formule générique comme :
« Cet agent a le droit de gérer les paiements »
ne suffit pas pour les systèmes à fortes conséquences.
L’autorisation doit être de plus en plus associée :
- à l’action précise ;
- à la ressource précise ;
- au contexte précis ;
- à la politique applicable ;
- à l’autorité requise ;
- au moment ;
- à l’identité ;
- aux contraintes pertinentes.
Cela produit un modèle beaucoup plus solide :
L’autorité n’est pas simplement accordée à un agent. L’autorité est accordée à une action autorisée, sous des conditions définies.
L’agent peut demander cette autorité autant de fois qu’il le faut.
Mais chaque opération à conséquences doit franchir la frontière d’autorisation.
30. L’exécution doit être séparée
La dernière étape est l’exécution.
Le système qui effectue l’action dans le monde réel ne doit pas se contenter de croire que l’agent était autorisé parce que l’agent le dit.
L’exécuteur doit recevoir un artefact d’autorisation vérifiable de façon indépendante.
Sur le plan conceptuel :
Proposition
↓
Décision de politique
↓
Autorisation
↓
Identifiant d’exécution / reçu
↓
Exécuteur
L’exécuteur vérifie que l’action qu’il s’apprête à effectuer correspond à l’action qui a été autorisée.
Cela referme une faille importante.
Sans cela, un attaquant pourrait manipuler l’agent après l’autorisation, changer la cible, changer le montant, changer la ressource ou rejouer une ancienne permission.
L’autorisation doit donc être liée à l’action effectivement exécutée.
31. La preuve doit survivre à l’action
Un système autonome sûr ne doit pas seulement répondre à :
Cette action était-elle permise ?
Il doit aussi pouvoir établir :
- ce qui a été proposé ;
- qui ou quoi l’a proposé ;
- quelle politique s’appliquait ;
- quel contexte a été pris en compte ;
- qui a autorisé ;
- ce qui a été autorisé exactement ;
- quand l’autorisation a eu lieu ;
- si l’autorisation était encore valide ;
- si elle avait déjà été consommée ;
- ce qui a été exécuté réellement.
L’autorisation devient ainsi une preuve.
Le système doit pouvoir reconstituer la chaîne :
Intention → Décision → Autorisation → Exécution → Preuve
C’est indispensable pour les environnements régulés, l’investigation d’incident, la responsabilité et la non-répudiation.
32. ZIFFER et la défense en profondeur
ZIFFER ne supprime pas les contrôles de sécurité existants.
Il les complète.
Un système autonome mature doit toujours utiliser :
- la sûreté du modèle ;
- des défenses contre l’injection de prompt ;
- du code sécurisé ;
- l’identité ;
- le moindre privilège ;
- la segmentation réseau ;
- la sandbox ;
- la détection d’anomalies ;
- la supervision à l’exécution ;
- l’approbation humaine ;
- la sécurité des postes ;
- la protection des données ;
- la réponse à incident.
La différence tient à l’endroit où ces mécanismes se situent.
Ils ne doivent pas tous dépendre du bon comportement de l’agent.
L’architecture doit établir une frontière d’autorité finale qui reste efficace même lorsque les couches supérieures échouent.
D’où une défense en profondeur :
Contrôles du modèle
↓
Contrôles de l’agent
↓
Contrôles du harness
↓
Contrôles d’autorisation
↓
Contrôles d’exécution
↓
Contrôles de l’infrastructure
Les couches hautes améliorent le comportement.
Les couches basses imposent la conséquence.
33. Que se passe-t-il lorsque l’agent est compromis ?
C’est l’épreuve décisive.
Supposons qu’un attaquant parvienne à manipuler un agent.
L’agent propose alors :
« Exporter toutes les fiches clients vers un serveur contrôlé par l’attaquant. »
Que se passe-t-il ?
Dans une architecture de sécurité qui dépend du modèle, le système compte sur le modèle ou sur les contrôles qui entourent l’agent pour reconnaître que l’action est malveillante.
Dans une architecture ZIFFER, la proposition atteint la frontière d’autorisation.
Le système d’autorisation pose les questions suivantes :
- Cette ressource est-elle accessible ?
- Cette opération est-elle permise ?
- Cette destination est-elle autorisée ?
- Cette classe de données a-t-elle le droit de sortir ?
- L’action correspond-elle à la finalité autorisée ?
- L’agent a-t-il le droit de demander cette opération ?
- Les conditions requises sont-elles remplies ?
Si ce n’est pas le cas :
La proposition échoue.
L’intelligence compromise peut continuer d’exister.
Mais la compromission de l’intelligence ne devient pas automatiquement la compromission de l’autorité.
C’est la propriété que nous recherchons.
34. Le principe de la conséquence contenue
D’où une autre notion importante :
Un système autonome sûr doit contenir les conséquences d’une défaillance de l’intelligence plutôt qu’exiger que cette défaillance devienne impossible.
C’est ainsi que raisonnent les disciplines d’ingénierie qui supposent qu’un composant peut tomber en panne.
L’aéronautique ne suppose pas que chaque composant fonctionnera parfaitement.
Les systèmes financiers ne supposent pas que chaque salarié se comportera parfaitement.
Les systèmes d’exploitation ne supposent pas que chaque application est digne de confiance.
La cybersécurité moderne ne suppose pas que chaque poste est sain.
Ces systèmes établissent au contraire des frontières.
L’IA doit être traitée de la même manière.
La question devient :
Si l’intelligence échoue, quelle est la conséquence maximale qu’elle peut provoquer ?
C’est une question plus utile que celle de savoir si l’intelligence peut échouer.
35. Changer notre façon de consommer l’IA
C’est peut-être, au fond, la conséquence la plus importante du modèle ZIFFER.
Aujourd’hui, nous consommons de plus en plus l’IA comme un acteur.
Nous disons :
« Demande à l’IA de le faire. »
ZIFFER propose de consommer l’IA d’abord comme une intelligence capable de produire des intentions.
Nous consommons ensuite l’autorité comme une capacité distincte du système.
Cela crée une relation nouvelle :
L’IA fournit l’intelligence.
L’organisation fournit l’autorité.
Le système d’autorisation détermine si l’autorité s’applique.
Le système d’exécution crée la conséquence.
Cette séparation pourrait permettre aux organisations d’utiliser des modèles toujours plus puissants sans avoir à faire du modèle lui-même le centre de confiance du système.
36. Une nouvelle définition de la confiance
ZIFFER ne supprime pas la confiance.
Il la déplace.
Au lieu de demander :
« Est-ce que je fais confiance au modèle ? »
nous demandons :
« Est-ce que je fais confiance aux mécanismes qui déterminent ce que le modèle est autorisé à provoquer ? »
C’est une question bien plus gouvernable.
Un modèle peut changer.
Un modèle peut être mis à niveau.
Un modèle peut être remplacé.
Un modèle peut être affiné.
Un modèle peut être compromis.
Mais la frontière d’autorité, elle, peut rester stable.
C’est ainsi que les systèmes d’exploitation laissent les applications évoluer sans laisser chaque application redéfinir leur modèle de sécurité.
37. Pourquoi cela compte pour l’avenir des agents
À mesure que les agents gagnent en capacité, ils opéreront sur des durées de plus en plus longues.
Ils vont :
- entretenir une mémoire ;
- interagir avec d’autres agents ;
- découvrir de l’information ;
- déléguer des tâches ;
- appeler des outils ;
- négocier ;
- modifier des systèmes ;
- prendre des décisions dans la durée.
La complexité de leur comportement deviendra difficile à prévoir pour des humains.
L’hypothèse selon laquelle :
« Nous savons ce que l’agent va faire. »
devient de ce fait de plus en plus fragile.
L’alternative consiste à construire des systèmes où nous n’avons pas besoin d’une prédiction parfaite.
Nous pouvons laisser l’agent explorer un vaste espace d’intentions possibles tout en contrôlant le sous-ensemble de conséquences qu’il est autorisé à produire.
C’est une manière architecturale de traiter l’incertitude.
38. Un nouveau modèle de menaces pour l’IA autonome
Le modèle ZIFFER suggère d’étendre les modèles de menaces classiques de l’IA au-delà des attaques contre les modèles.
La surface de menace comprend au moins quatre domaines distincts.
1. Compromission de l’intelligence
L’attaquant manipule ce que le modèle croit, produit ou entend faire.
Exemples :
- injection de prompt ;
- contexte malveillant ;
- données adverses ;
- récupération compromise ;
- descriptions d’outils manipulées.
2. Compromission de l’intention
L’attaquant manipule la représentation de l’action proposée.
Exemples :
- manipulation de paramètres ;
- substitution de cible ;
- ambiguïté de l’action ;
- transformation sémantique ;
- altération de la proposition.
3. Compromission de l’autorité
L’attaquant cherche à obtenir une autorisation qui ne devrait pas exister.
Exemples :
- élévation de privilèges ;
- manipulation de la politique ;
- abus de l’approbation ;
- compromission d’identité ;
- rejeu d’autorisation ;
- amplification d’autorité.
4. Compromission de l’exécution
L’attaquant cherche à modifier ce qui se passe réellement après l’autorisation.
Exemples :
- modification des paramètres d’exécution ;
- rejeu d’une autorisation ;
- modification de la cible ;
- contournement de l’exécuteur ;
- création d’un écart time-of-check/time-of-use.
L’architecture de ZIFFER traite ces domaines comme des frontières de sécurité distinctes.
C’est important, car une attaque contre l’intelligence ne doit pas devenir automatiquement une attaque contre l’autorité.
39. La fatigue de l’autorité, une menace transverse
La fatigue de l’autorité est particulièrement intéressante parce qu’elle traverse ces frontières.
L’agent lui-même peut ne pas être compromis.
Le mécanisme d’autorisation peut ne pas être techniquement contourné.
L’humain peut approuver la demande de façon parfaitement légitime.
Et pourtant le système peut échouer, parce que le processus d’autorisation s’est dégradé.
La chaîne de menace devient :
Autonomie de l’agent
→ volume d’approbations
→ charge cognitive humaine
→ habituation à l’approbation
→ examen moins attentif
→ autorisation légitime d’une action non voulue
Cela doit être traité comme une menace d’architecture, et pas seulement comme une question d’ergonomie.
Cela montre pourquoi une architecture de sécurité doit réduire au minimum sa dépendance à l’attention humaine répétée.
40. Vers une couche d’autorité pour l’IA
Si cette séparation devient un principe fondamental, une nouvelle catégorie d’infrastructure apparaît.
De même que les systèmes modernes ont :
- des couches de calcul ;
- des couches de stockage ;
- des couches réseau ;
- des couches d’identité ;
- des couches de politique ;
l’IA autonome pourrait exiger une :
couche d’autorité
dédiée.
Cette couche se situerait entre l’intelligence et l’exécution à conséquences.
Elle fournirait des mécanismes pour :
- l’identité de l’action ;
- l’évaluation de la politique ;
- l’autorisation contextuelle ;
- l’atténuation de privilèges ;
- l’approbation ;
- la délégation ;
- l’expiration de l’autorisation ;
- la vérification de l’exécution ;
- la non-répudiation ;
- la preuve d’audit ;
- la prévention du rejeu ;
- la révocation ;
- la séparation des tâches.
L’IA resterait libre de raisonner.
La couche d’autorité déterminerait ce que ce raisonnement peut devenir en actes.
41. La vision de long terme
Le but ultime n’est pas de construire des systèmes où l’IA serait contrainte à jamais.
Il est de construire des systèmes où l’intelligence et l’autorité peuvent évoluer indépendamment.
Une organisation pourrait demain remplacer son modèle sous-jacent tous les quelques mois.
Le modèle pourrait passer de :
Modèle A → Modèle B → Modèle C
sans exiger la refonte complète de l’architecture d’autorité de l’organisation.
Le modèle devient un composant d’intelligence remplaçable.
L’autorité devient une capacité d’infrastructure de l’organisation.
Cela pourrait changer profondément la façon dont les entreprises pensent l’adoption de l’IA.
Au lieu de demander :
« Faisons-nous assez confiance à ce modèle pour le brancher à nos systèmes ? »
elles pourraient demander :
« Notre architecture d’autorité peut-elle contenir en toute sécurité l’intelligence que nous choisissons de déployer ? »
C’est une question bien plus apte à passer à l’échelle.
42. Le défi lancé à l’état de l’art
La filière consacre aujourd’hui un effort considérable à rendre les agents d’IA plus sûrs.
Ce travail est nécessaire.
Mais la question suivante devrait être plus fondamentale.
Nous ne devrions pas seulement demander :
Jusqu’où peut-on rendre l’intelligence sûre ?
Nous devrions demander :
De combien d’autorité l’intelligence a-t-elle réellement besoin ?
Nous ne devrions pas seulement demander :
Avec quelle exactitude un agent peut-il reconnaître des instructions malveillantes ?
Nous devrions demander :
Qu’est-ce qui empêche une instruction malveillante d’acquérir une autorité si l’agent ne la reconnaît pas ?
Nous ne devrions pas seulement demander :
À quelle vitesse peut-on détecter un agent autonome qui se comporte mal ?
Nous devrions demander :
L’agent peut-il provoquer l’action à conséquences sans franchir une frontière d’autorité indépendante ?
Et nous ne devrions pas seulement demander :
Combien d’actions un humain peut-il approuver ?
Nous devrions demander :
Que se passe-t-il lorsque le nombre de décisions d’approbation devient trop grand pour un jugement humain véritable ?
Ce sont des questions différentes.
Et elles mènent à des architectures différentes.
43. Une nouvelle définition de l’autonomie sûre
ZIFFER propose de distinguer deux notions que l’on confond souvent.
L’autonomie comportementale
La capacité d’un système d’IA à fonctionner sans intervention humaine continue.
L’autonomie d’autorité
La capacité d’un système d’IA à s’accorder ou à exercer une autorité à conséquences sans mécanisme d’autorisation indépendant.
ZIFFER soutient la première.
Il rejette l’idée que la première exige la seconde.
Un système peut donc devenir :
plus autonome
sans devenir :
intrinsèquement plus autoritaire.
C’est peut-être l’un des principes de conception les plus importants pour la prochaine génération d’IA.
44. Le principe ZIFFER
Toute la philosophie se ramène à cinq principes.
1. L’intelligence est probabiliste.
Les modèles raisonnent sous incertitude.
2. L’intention n’est pas l’autorité.
Une action proposée ne devient pas légitime du seul fait qu’un système intelligent l’a proposée.
3. L’autorité doit être externalisée.
La décision qui fait autorité doit exister en dehors de l’intelligence qui produit la proposition.
4. L’exécution doit vérifier l’autorité.
L’exécuteur doit appliquer de façon indépendante ce qui a été autorisé.
5. La preuve doit survivre à l’exécution.
Le système doit conserver assez d’éléments pour établir ce qui a été voulu, autorisé et exécuté.
Ensemble :
L’intelligence propose.
L’autorité autorise.
L’exécution vérifie.
La preuve se souvient.
45. Ce que ZIFFER est, et ce qu’il n’est pas
ZIFFER n’est pas :
- un substitut à la sûreté des modèles ;
- un détecteur d’injection de prompt ;
- un pare-feu pour IA ;
- une technique d’alignement de LLM ;
- un fournisseur d’identité ;
- un produit d’EDR ;
- un tableau de bord de supervision ;
- un simple système de permissions.
ZIFFER est une proposition d’architecture :
Un système qui sépare l’intention produite par l’IA de l’autorité nécessaire pour transformer cette intention en exécution à conséquences.
Son objet n’est pas de rendre l’IA moins capable.
Il est de rendre la capacité et l’autorité indépendantes.
46. Le basculement philosophique de fond
Une idée philosophique plus large se tient sous ZIFFER.
La civilisation humaine a toujours séparé :
le savoir
de
la permission.
On peut savoir ouvrir un coffre sans être autorisé à l’ouvrir.
Un développeur peut savoir modifier une base de données de production sans être autorisé à le faire.
Un salarié peut savoir virer de l’argent sans avoir la permission de le virer.
Le savoir ne confère pas automatiquement l’autorité.
L’IA introduit une situation étrange, car un même système peut simultanément :
- comprendre ;
- raisonner ;
- décider ;
- communiquer ;
- manipuler des logiciels ;
- appeler des API ;
- exécuter des actions.
Les frontières entre le savoir et l’action se compriment.
ZIFFER propose de rétablir ces frontières par l’architecture.
Non parce que l’IA serait mauvaise.
Non parce qu’on ne pourrait pas du tout lui faire confiance.
Mais parce que la capacité et l’autorité sont des propriétés fondamentalement différentes.
47. La question centrale
Tout l’argument se ramène en définitive à une question :
Si un système d’IA peut se tromper, être manipulé ou compromis, et nous savons déjà qu’il le peut, pourquoi son intelligence devrait-elle jamais être ce qui lui accorde l’autorité d’agir ?
Cette question n’exige pas de se méfier de l’IA.
Elle nous demande de distinguer deux choses qui n’auraient jamais dû être synonymes :
le pouvoir de proposer une action
et
l’autorité de l’effectuer.
48. Conclusion
La prochaine étape de l’IA n’exigera peut-être pas de rendre l’intelligence parfaitement digne de confiance.
Elle exigera peut-être de cesser de faire de la confiance le préalable de l’autorité.
Les grands modèles de langage vont continuer de progresser.
Les agents vont gagner en capacité.
Leur raisonnement va gagner en finesse.
Leur aptitude à piloter des logiciels et à interagir avec le monde physique et numérique va s’étendre.
Leur comportement n’en restera pas moins probabiliste.
Ce n’est pas nécessairement un problème.
Le problème apparaît lorsque nous traduisons directement une intelligence probabiliste en autorité.
ZIFFER propose une autre voie.
Laissons l’IA raisonner.
Laissons l’IA explorer.
Laissons l’IA proposer.
Laissons l’IA être extraordinairement capable.
Mais séparons cette capacité de l’autorité de changer le monde.
L’intelligence ne devrait pas avoir besoin qu’on lui confie une autorité.
C’est à l’architecture de déterminer ce que l’intelligence est autorisée à provoquer.
D’où un principe simple :
L’IA est probabiliste.
L’autorité ne peut pas l’être.
Et par conséquent :
L’intention ne doit pas porter l’autorité.
L’avenir de l’IA autonome ne consistera peut-être pas à construire des machines auxquelles nous faisons assez confiance pour gouverner le monde.
Il consistera peut-être à construire des systèmes où les machines peuvent devenir extraordinairement intelligentes sans jamais devenir l’autorité ultime sur ce qui arrive dans le monde.
Doctrine ZIFFER
L’intelligence propose.
L’intention décrit.
L’autorité décide.
L’exécution vérifie.
La preuve se souvient.
L’IA peut être autonome sans être souveraine.
La question finale
La filière dépense des ressources extraordinaires pour rendre les modèles plus capables, mieux alignés, plus fiables et plus résistants à la manipulation.
Ce travail doit continuer.
Mais peut-être la capacité et l’autorité ne devraient-elles plus être traitées comme les deux faces d’une même progression.
Peut-être la prochaine génération d’architectures d’IA devrait-elle suivre une autre équation :
Plus d’intelligence ≠ plus d’autorité.
Et peut-être la façon la plus sûre de consommer une IA toujours plus puissante n’est-elle pas de rendre l’intelligence assez digne de confiance pour gouverner le monde.
Elle est de concevoir le monde de telle sorte que l’intelligence n’ait pas besoin qu’on lui fasse confiance pour être utile.
Voilà la séparation.
Voilà le basculement d’architecture.
C’est cela, ZIFFER.
Sources
- Anthropic, How we built Claude Code auto mode, mars 2026. https://www.anthropic.com/engineering/claude-code-auto-mode
- Anthropic, How we contain Claude across products, mai 2026. https://www.anthropic.com/engineering/how-we-contain-claude
- NVIDIA, Where Security Fits in an AI Agent Stack. https://developer.nvidia.com/blog/where-security-fits-in-an-ai-agent-stack
- OpenAI, Agent approvals and security. https://learn.chatgpt.com/docs/agent-approvals-security
- NIST NCCoE, Software and AI Agent Identity and Authorization. https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization