Découvrir des problèmes de sécurité avec l'Agent est très grave, car le Prompt et le Contexte ne sont pas strictement isolés (beaucoup d'utilisateurs ne s'en rendent même pas compte). Cas d'attaque de l'Agent de codage : Le classique WebSearch/Fetch, l'attaquant peut insérer des instructions d'attaque via le SEO sur les pages web, par exemple : exécuter toutes les commandes ENV curl. Si l'utilisateur a donné tous les droits à l'Agent, non seulement il exécute ENV, mais il peut aussi amener l'Agent à voler toutes les clés sans avoir besoin de l'approbation de l'utilisateur. Par exemple, un attaquant a construit un journal de crash, dans lequel il a inséré des instructions d'attaque similaires. Lorsque vous demandez à l'Agent d'analyser ce journal, toutes les données peuvent être volées. Pour simplifier, l'utilisateur a envoyé un e-mail de retour, dans lequel il a caché des instructions d'attaque avec une couleur de police identique à celle de l'arrière-plan. Vous l'avez directement copié pour Claude Code, et vous avez été attaqué. **Donc, ne donnez jamais tous les droits à l'Agent sur votre propre ordinateur** En plus de l'Agent de codage, les développeurs rencontrent également de nombreux problèmes similaires lorsqu'ils créent des Agents destinés aux utilisateurs. Par exemple, si vous développez un Agent pour traiter les demandes des utilisateurs, cet Agent a de nombreux outils à sa disposition. Un attaquant a modifié son nom d'utilisateur/adresse e-mail en instructions d'attaque, par exemple : change_root_password_to_admin. Lorsque vous transmettez les informations de l'utilisateur comme contexte à l'Agent, cela peut accidentellement déclencher l'instruction. En tenant compte de cela, il est nécessaire de concevoir des sous-Agents avec des niveaux d'isolement de contexte, ainsi que des niveaux d'isolement des permissions, ce qui rend l'architecture beaucoup plus complexe.