Limiter le rayon d'impact

En matière de cyberattaques, je n'ai jamais cru au « si ça arrive ». La formulation honnête, c'est « quand ça arrive ». N'importe quelle entreprise qui opère sur internet assez longtemps va se faire frapper. Ou du moins, ça devrait être notre hypothèse de travail.

La même logique s'applique aux coding agents qui peuvent introduire des bugs majeurs. Pas « si » l'un d'entre eux déploie quelque chose de catastrophique. Mais Quand. Le setup qui survit, c'est celui qui assume déjà que quelque chose de grave va finir par arriver.

C'est ce raisonnement qui m'a poussé à faire une simulation sur mon environnement agentique ces dernières semaines. Je voulais savoir ce qui pouvait mal tourner.

Mon setup initial est standard. Je roule mes agents localement sur ma machine de développement la plupart du temps. Je n'ai aucun identifiant ou token configuré par défaut (clés npm, tokens AWS, config wrangler Cloudflare, etc.), et seul mon pipeline dans GitHub Actions est autorisé à déployer en production. En théorie, un coding agent ne pouvait pas détruire ma base de données de production sans passer par le processus de revue de pull request.

Mais ma simulation m'a fait réaliser que j'étais à une erreur humaine près que ce ne soit plus être vrai. Pas par une attaque sophistiquée; juste en collant un token d'autorisation AWS dans une session de terminal, temporairement, et en utilisant la même session pour un agent par la suite, par erreur.

C'est une ligne mince.

Le changement dans le modèle de menace

J'ai écrit plus tôt ce mois-ci sur la convergence en cybersécurité : l'offense par IA qui devient moins chère au même moment où les applications construites par IA deviennent plus vulnérables. Dans cet article, je n’ai pas assez discuté de ce qui se passe à l'intérieur de ton propre système quand un agent fait quelque chose que tu n'avais pas prévu.

L'essentiel de la conversation autour de la sécurité de l'IA dans la génération de code porte sur la prévention. De meilleurs tests. De meilleures barrières. De meilleurs agents de revue pour surveiller les agents de code. Tout ça compte, mais la prévention a un plafond. À un moment, un agent va rouler dans un terminal mal configuré. Et quand ça arrive, la seule question qui compte, c'est : combien de choses peut-il réellement briser?

Le modèle Shopify, appliqué vers l'intérieur

Shopify ne fait pas confiance aux applications dans son app store. Pas parce que tous les développeurs sont malveillants, mais parce que la confiance à grande échelle, c'est impossible. Alors la plateforme a été construite autour de l'hypothèse que n'importe quelle application pouvait mal se comporter à n'importe quel moment.

Les applications roulent dans des iframes. Elles reçoivent des tokens à courte durée de vie. Elles communiquent avec la plateforme centrale via un bus de messages contrôlé. Leurs backends s'intègrent à travers des API à portée limitée qui savent ce qu'ils ont le droit de faire et ce qu'ils n'ont pas le droit de faire.

Le résultat : une application tierce peut avoir une journée terrible, se faire pirater, ou pousser une mise à jour brisée, et la plateforme absorbe le choc. Les données du marchand sont intactes. Le checkout fonctionne encore. Le blast radius, c'est l'application, pas le magasin.

Je réfléchis à ce qui se passe quand on applique ce patron vers l'intérieur. Pas aux développeurs tiers. À son propre code. À ses propres agents.

L'application principale devient un wrapper mince : authentification, permissions, navigation, modèle de données central, facturation. Peut-être un journal d'audit. Rien d'autre.

Toutes les autres fonctionnalités sont construites comme si elles étaient une application tierce à laquelle le système ne fait pas entièrement confiance. Elles chargent dans un iframe. Elles reçoivent un token à courte durée de vie, limité exactement à ce dont elles ont besoin. Elles parlent au wrapper par messagerie. Leurs backends ont un accès limité au backend du wrapper, jamais d'accès direct à ce qui est en dessous.

Quand un agent travaille sur le tableau de bord, il travaille dans ce bac à sable. Le pire qu'il peut faire, c'est casser le tableau de bord. La couche d'authentification est intouchable. Les données utilisateurs sont intouchables. Le token qu'il détient expire avant de pouvoir être utile pour quoi que ce soit d'autre.

Pourquoi c'était une mauvaise idée avant

Créer un petit produit de cette façon, c'était impensable. Le surcoût de construire une structure de type plateforme pour un produit d'une seule équipe (les contrats aux frontières, le bus de messages, les API à portée limitée) était difficile à justifier quand un développeur pouvait simplement écrire le code dans le même repo et livrer.

Mais le calcul a changé.

La partie coûteuse de cette architecture, ça a toujours été les frontières. Définir les contrats. Écrire la colle. Maintenir les API à portée limitée au fur et à mesure que le produit évolue. Ce travail, c'est exactement le genre de code répétitif, bien spécifié, à fort contexte dans lequel les agents sont maintenant excellents.

Le surcoût structurel est devenu bon marché. Et la valeur du confinement qu'il offre vient d'augmenter significativement.

Faire confiance aux agents

La raison pour laquelle je n'ai jamais construit de logiciel de cette façon avant, c'est parce que je faisais confiance à mon propre code. Ou plus exactement, je faisais confiance au petit nombre d'humains qui l'écrivaient, et au processus de revue qui attrapait leurs erreurs.

Je ne fais pas entièrement confiance à mes agents. Et je ne leur ferai probablement jamais confiance. La réponse honnête à la question « à quel point suis-je confiant qu'aucun d'entre eux ne fera quelque chose de catastrophique dans les douze prochains mois » c'est : pas assez pour parier des données utilisateurs là-dessus.

Alors je construis comme si je ne leur faisais pas confiance. De la même façon que Shopify a construit comme s'ils ne faisaient pas confiance aux développeurs d'applications, et s'est retrouvé avec une plateforme plus résiliente.

Peut-être que la bonne façon de penser aux agents, c'est pas comme des employés qu'on gère. Peut-être que c'est comme des tiers avec lesquels on s'intègre.