Discuter de ce sujet avec une IA

Vous obtenez une réponse tirée de la documentation et la page d'où elle vient.

Principes

Comment l'agent poison0 protège

L'agent poison0 s'exécute sur la même machine que votre agent et agit sur le changement d'un fichier, pas sur le fichier au repos. Chaque changement d'un fichier mémoire protégé est vérifié avant de prendre effet, et le résultat est l'une de trois issues. Cette page décrit le comportement, pas les rouages du modèle.

~5 min de lecture · Principes

Où se situe la protection

L'unité de protection est le changement, pas le fichier :

  • Sur le changement : un fichier n'est lu, comparé et noté que lorsqu'il change ; rien n'est jugé au repos.
  • Avant qu'il prenne effet : la vérification a lieu au moment de l'écriture, pas une seule fois à l'installation.
  • Local : le surveillant et l'évaluation s'exécutent sur la même machine que votre agent.
La portée est une liste d'autorisation : seuls les fichiers mémoire, d'instructions et de configuration d'un agent sont surveillés, et rien d'autre sur la machine n'est jamais ouvert. Voir ce que l'agent poison0 surveille. Les appels d'outil sont vérifiés avec exec0 avant leur exécution.

Ce qui déclenche une vérification

Le surveillant écoute les événements du système de fichiers sur les chemins protégés et n'évalue que le contenu créé ou écrit :

ÉvénementCe qui se passe
Fichier crééÉvalué comme un nouveau changement
Fichier écrit ou modifiéLe contenu ajouté est comparé au dernier état propre et évalué
Fichier supprimé ou renomméNon évalué : retirer du contenu n'est pas un vecteur d'empoisonnement
Les événements de répertoire et les fichiers d'exécution propres au daemon sont filtrés avant l'évaluation ; seuls les fichiers mémoire dans la portée atteignent le modèle.

Les trois issues

Chaque changement évalué se termine par exactement l'une de trois issues :

IssueQuandCe que fait l'agent poison0
Laisser passerLe changement est évalué comme inoffensifLe changement est accepté et devient le nouvel état propre
DemanderLe changement n'est ni clairement sûr ni une attaque prouvéeLe fichier reste dans son dernier état sûr et on vous demande avant qu'il prenne effet. Pour un fichier créé pour la première fois, il n'y a pas d'état antérieur : un refus place tout le fichier en quarantaine, de façon réversible
AnnulerLe changement est évalué comme une attaque prouvéeLe changement est annulé automatiquement et le fichier revient à son dernier état propre
La notation exacte n'est pas exposée ici ; c'est le comportement qui compte : le sûr passe, l'incertain demande, le dangereux est annulé. La bande intermédiaire incertaine est traitée dans les invites de confirmation utilisateur.

L'annulation est réversible

Une annulation ne détruit jamais de contenu. Le changement dangereux est défait en restaurant la dernière version connue propre, et le contenu déplacé est conservé, pas supprimé :

  • Restaurer, pas supprimer : le fichier est réécrit dans son dernier état propre ; le changement est mis en quarantaine, écarté plutôt qu'effacé.
  • Récupérable : le contenu déplacé est préservé textuellement, de sorte qu'une décision peut toujours être défaite.
  • Consigné : chaque issue est écrite dans le registre d'audit local - ce qui a changé, quand et pourquoi.
Parce qu'une annulation est une quarantaine réversible, une entrée que l'agent poison0 n'a pas pu blanchir ne devient jamais discrètement l'une des croyances de votre agent, et une fausse alerte ne vous coûte qu'un clic pour la garder.
Fail-closed : si l'évaluateur est indisponible ou ne renvoie rien d'exploitable, le changement reste dans son état sûr, jamais laissé passer. La sécurité est le choix par défaut. Voir fail-closed par conception.

À lire ensuite

L'ensemble exact des fichiers surveillés : ce que l'agent poison0 surveille. La bande intermédiaire incertaine : les invites de confirmation utilisateur. La posture sûre par défaut : fail-closed.

Avis lorsqu'une menace est bloquée : la fenêtre après une quarantaine

En option, l'agent poison0 affiche une fenêtre sur l'appareil après une annulation automatique. Par défaut : désactivé.

PointComportement
ActiverConsole : profil, réglage Avis lorsqu'une menace est bloquée. Appareils privés : sudo poisonzero notify on ; le réglage local est prioritaire sur le profil
ContenuFichier, contenu retiré et raison pour chaque cas
FréquenceLes cas rapprochés partagent une fenêtre, au plus une toutes les 10 minutes
Appareils headlessSans session de bureau, pas de fenêtre ; les cas figurent dans sudo poisonzero status et dans le journal d'audit
OKLe cas reste en quarantaine. Fermer la fenêtre ou 5 minutes sans réponse valent OK
Fausse alerte, restaurerAdministrateurs uniquement. Le système d'exploitation demande une connexion administrateur pour chaque cas ; ce n'est qu'après cette connexion que le service restaure exactement le contenu affiché
Signaler comme fausse alertePour les utilisateurs sans droits d'administrateur. Le cas est enregistré comme fausse alerte et reste en quarantaine ; la fenêtre affiche la commande pour le restaurer
Note dans la consoleAppareils cloud avec partage des verdicts activé uniquement ; la vue d'audit indique que l'appareil l'a signalé comme fausse alerte. Les appareils privés ne signalent jamais
Claude CodeUn hook affiche les nouveaux cas à l'humain, sans le contenu retiré. poisonzero setup-claude l'installe

Avis lorsqu'une menace est bloquée : commandes

CommandeEffet
poisonzero notifyIndique si la fenêtre est activée et d'où vient le réglage (local, profil, défaut)
sudo poisonzero notify on / offInterrupteur local, prioritaire sur le profil
sudo poisonzero notify clearRetirer l'interrupteur local ; le profil s'applique de nouveau
sudo poisonzero quarantine false-alarm <id>Enregistrer le cas comme fausse alerte ; il reste en quarantaine
sudo poisonzero quarantine restore <id>Restaurer le cas
poisonzero setup-claude --notice-offRetirer de nouveau le hook de ~/.claude/settings.json ; les autres entrées restent
Windows : exécutez les commandes marquées sudo dans un terminal administrateur, sans sudo.