Plus je réfléchis à la sécurité de l’IA, plus je reviens à une seule question.
Que se passe-t-il quand le système censé autoriser les actions de l’IA... n’y arrive pas ?
Au début, je pensais que la réponse était évidente.
Si la couche d’autorisation tombe en panne, l’IA ne devrait rien pouvoir faire.
Ça ressemble au choix le plus sûr.
Après tout, si un système ne peut pas confirmer qu’une action est autorisée, il ne devrait pas deviner. En finance en particulier, l’incertitude ne doit pas devenir une autorisation.
Mais plus j’y pensais, moins j’étais sûr de moi.
Et si un coffre avait vraiment besoin d’attention pendant que le service d’autorisation est indisponible ?
Faut-il tout verrouiller et espérer que le problème se résolve tout seul ?
Ou bien faut-il donner à quelqu’un la possibilité d’intervenir ?
C’est le problème qui m’a paru intéressant en lisant au sujet du Newton's VaultKit.
Au lieu d’autoriser une annulation immédiate, il utilise une voie d’urgence retardée. Une action exceptionnelle peut toujours se produire, mais pas tout de suite. Il faut attendre, et cette décision est visible en chaîne.
En fait, j’aime bien cette idée.
Un contournement immédiat ferait paraître la couche de politique optionnelle. S’il existe toujours une façon rapide de passer outre les règles, alors ces règles n’ont pas autant de poids.
Mais supprimer complètement l’accès d’urgence ne semble pas non plus réaliste.
Les systèmes réels se brisent.
Les réseaux subissent des pannes.
Les services deviennent indisponibles.
Parfois, attendre que tout revienne à la normale n’est tout simplement pas une option.
Donc, une voie d’urgence retardée me semble être un compromis raisonnable.
Mais je ne pense pas que la période d’attente soit la partie la plus intéressante.
Ce qui m’a vraiment marqué, c’est que la source de confiance change.
Dans des conditions normales, une action privilégiée est évaluée par rapport à des politiques prédéfinies. Les opérateurs l’approuvent, les contrôles requis ont lieu, puis seulement l’action est autorisée à avancer.
Pendant une urgence, ce n’est plus ce qui protège le système.
Au lieu de cela, vous vous reposez sur l’autorité du propriétaire, la période d’attente et le fait que tout le monde peut voir ce qui s’est passé on-chain.
C’est une autre forme de sécurité.
Ce n’est pas forcément plus faible.
C’est simplement construit sur des hypothèses différentes.
Et je pense que c’est une distinction importante.
La transparence est précieuse, mais la transparence n’est pas la même chose que l’autorisation.
Le fait de voir qu’une voie d’urgence a été utilisée ne signifie pas automatiquement que l’action a reçu le même niveau de vérification que pendant un fonctionnement normal.
Ensuite, il y a la question du timing.
De combien de temps le délai d’urgence doit-il être ?
Trop court, et la voie d’urgence commence à ressembler à un raccourci.
Trop long, et cela pourrait ralentir la récupération même que l’on voulait permettre.
Je ne pense pas qu’il y ait une réponse parfaite.
Chaque protocole doit décider où il veut se placer entre sécurité et flexibilité.
Pour moi, le principal enseignement n’était pas que Newton a un mécanisme d’urgence.
Le fait de comprendre que les mécanismes d’urgence révèlent où vit réellement la dernière couche de confiance.
Il est facile de parler de sécurité quand chaque composant fonctionne exactement comme prévu.
La question la plus difficile est de savoir ce qui se passe lorsque ces hypothèses cessent d’être vraies.
Qui prend la décision finale ?
Quelles protections restent encore ?
Et de quoi demande-t-on finalement aux utilisateurs d’avoir confiance ?
Je pense que ces questions méritent autant d’attention que la performance de l’IA ou l’automatisation elle-même.
Parce que la véritable force d’un système de sécurité ne se mesure pas à sa capacité à fonctionner parfaitement lorsque tout est en ordre.
Elle se mesure à la manière dont il se comporte quand quelque chose ne va pas.
