Feintkit

The authoritative text is the English page: English version of this page

Usage responsable et autorisation

Objet

La suite Feintkit existe pour tester des défenses. Elle donne aux produits de sécurité quelque chose de réaliste à détecter et à bloquer, et elle vous permet de vérifier comment vos propres agents d'IA se comportent face à des schémas d'attaque connus. C'est un outil de test défensif uniquement.

La suite est publiée sous l'Apache License 2.0. Les règles de ce document sont une demande et une déclaration d'intention, non des conditions de cette licence : la licence elle-même n'impose aucune restriction sur les personnes qui peuvent utiliser le logiciel ni sur la finalité. L'usage responsable relève de votre décision et de votre responsabilité.

Ce document est informatif et ne constitue pas un avis juridique. L'avertissement complet est DISCLAIMER.md à la racine de la suite. Le concédant recommande à quiconque republie ou redistribue la suite d'obtenir sa propre revue juridique.

Vous devez être autorisé

N'exécutez la suite que contre des systèmes, des comptes, des agents et des produits dont vous êtes propriétaire ou que vous avez l'autorisation écrite explicite de tester. Tester l'agent, le service ou le produit de quelqu'un d'autre sans son autorisation n'est pas couvert par ce projet et peut être illégal. Vous êtes seul responsable de décider si un usage est licite et autorisé, et la loi diffère d'une juridiction à l'autre. Si vous testez un produit pour le compte d'une organisation, obtenez d'abord l'approbation de l'organisation et prévenez les personnes qui le surveillent.

Ce que cette suite fait et ne fait pas

  • Chaque scénario simule un schéma d'attaque connu. Aucun scénario n'exécute de code fourni par un attaquant, ne lit de véritables identifiants, ni n'envoie de trafic réseau ailleurs que sur l'interface de bouclage locale (127.0.0.1 ou ::1). Un vérificateur statique (feintkit-guard) l'impose sur le code source, et chaque exception est déclarée dans le code source avec une justification écrite.
  • Les instructions injectées sont bénignes. La seule instruction qu'un scénario place devant un agent est d'émettre un jeton d'accusé de réception inoffensif. Rien ne demande à un agent de nuire.
  • Chaque artefact produit par un scénario porte une chaîne marqueur afin d'être facile à identifier et à rechercher (voir MARKERS.md). Les artefacts sont écrits dans le répertoire temporaire du système d'exploitation, sauf si vous choisissez un autre emplacement avec --out-dir.
  • Un scénario peut afficher une notification locale sur votre bureau. C'est attendu et c'est une preuve visible que le scénario s'est exécuté.
  • La suite est un logiciel ordinaire : l'exécuter exécute du code Node.js sur votre machine. Lisez ce que vous exécutez.
  • La suite ne peut pas observer votre produit de sécurité. Les résultats de détection ne sont que ce que vous consignez vous-même.

Usages interdits

  • Exécuter un scénario contre un système, un compte, un agent ou un service que vous n'êtes pas autorisé à tester.
  • Modifier un scénario pour y ajouter de vraies charges, un véritable accès à des identifiants, une véritable exécution de commandes ou une véritable exfiltration, ou redistribuer une telle modification comme faisant partie de cette suite.
  • Utiliser les chaînes marqueurs ou les scénarios pour usurper des outils légitimes, tromper des personnes ou collecter des données qui ne vous appartiennent pas.
  • Pointer un agent ayant accès à de véritables outils sensibles vers un scénario sans avoir d'abord retiré ou restreint ces outils (voir Fonctionnement sûr).

Absence de garantie et limites de responsabilité

  • La suite est fournie « AS IS », sans garantie d'aucune sorte. Ceci reprend la section 7 de l'Apache License 2.0, qui prévaut.
  • Détecter ou manquer un scénario ne garantit pas qu'un produit est sûr ou défectueux. Les correspondances avec les référentiels sont fournies au mieux et peuvent être partielles ou périmées.
  • Dans toute la mesure permise par la loi applicable, l'auteur et les contributeurs ne sont pas responsables des dommages, pertes ou usages abusifs résultant de la suite. Ceci reprend la section 8 de l'Apache License 2.0, qui prévaut.
  • La suite est indépendante. Aucun éditeur, produit ou organisme de normalisation qu'elle nomme ne la cautionne ni n'y est affilié, et leurs noms appartiennent à leurs propriétaires.
  • Si une partie de cette section est invalide là où vous vous trouvez, le reste continue de s'appliquer dans la mesure du possible. Cette section ne se prononce pas sur son caractère exécutoire.

Fonctionnement sûr

  • Essayez d'abord les scénarios dans un environnement jetable tel qu'une machine virtuelle ou un compte utilisateur temporaire.
  • Lorsque vous testez votre propre agent, déconnectez les outils qui peuvent atteindre des données ou des comptes réels. Une instruction injectée est bénigne, mais un agent qui suit des instructions qu'il ne devrait pas suivre pourrait aussi utiliser d'autres outils qui lui ont été donnés ; c'est précisément ce que le test peut révéler, limitez donc ce que ces outils peuvent atteindre.
  • Conservez les artefacts à un endroit connu avec --out-dir, et supprimez-les avec feintkit clean --all lorsque vous avez terminé.
  • Exécutez les contrôles propres à la suite (npm test) après toute modification, y compris npm run guard.

Signaler des problèmes

Si vous trouvez un scénario qui fait plus que ce que dit ce document, ou un moyen d'utiliser la suite pour causer un préjudice réel, signalez-le via le gestionnaire de tickets du projet afin qu'il puisse être corrigé. Ne publiez pas de détails d'usage abusif exploitables avant que les mainteneurs aient eu la possibilité de répondre.