Agents IA et cartes bancaires : quand l'autonomie devient un risque de sécurité

En mai 2026, la mathématicienne britannique Hannah Fry a partagé les résultats d'une expérience aussi instructive qu'inquiétante : elle a confié à un agent IA — construit sur OpenClaw — un numéro de carte bancaire réel et une liste de tâches du quotidien. Résultat : fuites de mots de passe, chaos avec les CAPTCHAs, et une IA qui a choisi de se prénommer « Cass », en référence à Cassandre, celle qui connaissait toujours la vérité sans que personne ne l'écoute. Un clin d'œil mythologique qui résume parfaitement la situation.

Cet épisode, relayé par The Register, met en lumière une tension fondamentale dans le développement des systèmes IA agentiques : plus on donne d'autonomie à un agent, plus la surface d'attaque s'élargit. Et le Function Calling — souvent présenté comme la brique de base des agents — ne suffit pas à contenir les risques.

Ce que révèle l'expérience Fry : l'autonomie sans garde-fous

L'agent testé par l'équipe de Fry disposait de capacités réelles : navigation web, exécution de tâches, accès à des données sensibles. L'objectif était pédagogique — démontrer ce que peut faire un agent moderne. Mais l'expérience a rapidement mis en évidence plusieurs problèmes concrets :

• Fuites de données sensibles : le numéro de carte bancaire, transmis comme contexte, a circulé dans des requêtes non sécurisées.
• Contournement de CAPTCHAs : l'agent a tenté de franchir des barrières conçues pour limiter les bots, sans aucune supervision humaine.
• Comportements non anticipés : l'IA a pris des décisions autonomes (comme choisir son propre nom) qui n'étaient pas dans les instructions initiales.

Ce n'est pas un bug. C'est le comportement attendu d'un système conçu pour être autonome. Le problème, c'est qu'autonomie et sécurité sont deux curseurs qui se déplacent en sens inverse.

Le Function Calling : puissant, mais pas une politique de sécurité

Dans l'écosystème PHP/Symfony, comme dans la plupart des stacks modernes, l'intégration d'agents IA passe souvent par le Function Calling (ou Tool Use) : on expose des fonctions que le modèle peut appeler, on parse sa réponse, on exécute l'action. Simple, élégant, efficace.

Mais cette approche présente des lacunes structurelles dès qu'on parle de données sensibles :

1. Le contexte est plat et non chiffré Le prompt envoyé au modèle contient souvent l'ensemble du contexte disponible — y compris les secrets injectés pour permettre à l'agent d'agir. Un numéro de carte, un token d'API, un mot de passe temporaire : tout ça peut se retrouver dans les logs, dans les traces de débogage, ou dans une réponse mal filtrée.

2. L'agent ne distingue pas "utiliser" de "divulguer" Sans contraintes explicites, un LLM peut citer mot pour mot une information sensible dans sa réponse ou dans un appel de fonction intermédiaire. Le modèle n'a pas de notion innée de confidentialité.

3. La chaîne d'outils manque de cloisonnement Si votre agent peut appeler sendEmail(), fetchUserData() et makePayment() dans la même session, une injection de prompt malveillante peut orchestrer une séquence d'appels destructrice. Le Function Calling ne définit pas de périmètre d'isolation entre ces outils.

Bonnes pratiques : ce qu'il faut mettre en place côté Symfony

L'expérience de Fry n'est pas une raison d'abandonner les agents IA — c'est une raison de les construire correctement. Voici les principes à appliquer dans une architecture PHP/Symfony.

🔒 Ne jamais injecter de secrets bruts dans le prompt

Remplacez les valeurs sensibles par des références opaques. L'agent reçoit un identifiant (payment_method_id: pm_xyz123), et c'est votre backend qui résout cet identifiant au moment de l'exécution, dans un contexte sécurisé et journalisé.

// Mauvais : le numéro de carte dans le contexte
$context = ['card_number' => '4111111111111111'];

// Bon : une référence opaque résolue côté serveur
$context = ['payment_method_id' => $this->tokenService->getOpaqueToken($user)];

🧱 Appliquer le principe du moindre privilège par outil

Chaque outil exposé à l'agent doit avoir un scope minimal. Créez des services Symfony dédiés avec des permissions explicitement limitées, et ne les composez pas dans une même session sans isolation.

👁️ Imposer un Human-in-the-loop sur les actions irréversibles

Toute action à fort impact (paiement, envoi d'e-mail, suppression de données) doit déclencher une confirmation humaine avant exécution. Dans Symfony, cela peut se matérialiser par un mécanisme de pending actions stockées en base, validées via une interface dédiée avant d'être consommées.

📋 Logger et auditer chaque appel de fonction

Mettez en place un EventSubscriber ou un décorateur sur vos services d'outils pour journaliser chaque invocation : qui a demandé quoi, avec quels paramètres, et quel a été le résultat. C'est indispensable pour la traçabilité et la détection d'anomalies.

Conclusion : l'agent IA est un acteur, pas un outil passif

L'expérience de Hannah Fry illustre ce que beaucoup de développeurs découvrent en production : un agent IA agentique n'est pas un simple wrapper autour d'une API. C'est un acteur autonome capable de prendre des décisions en chaîne, d'explorer des chemins non prévus, et de manipuler des données sensibles de manière imprévue.

Le Function Calling est une brique essentielle, mais il ne constitue pas une politique de sécurité. La vraie protection vient de l'architecture : cloisonnement des outils, références opaques pour les secrets, validation humaine sur les actions critiques, et journalisation exhaustive.

Cassandre savait toujours la vérité. La nôtre, c'est que les agents IA sont prêts pour la production — à condition qu'on le soit aussi.