Le Plugin opencode-policy Ajoute 309 Règles pour Protéger les Agents IA contre les Injections et les Fuites

Pour l'environnement opencode, une couche protectrice séparée a été proposée qui intercepte les demandes dangereuses avant qu'elles n'atteignent le modèle ou ne soient transmises aux outils shell et fichier. Le plugin opencode-policy utilise des règles déterministes, pas seulement des prompts système, et couvre les scénarios d'attaque typiques contre les agents d'IA : injection de prompt, lecture de fichiers non autorisés, tentatives d'extraction de variables d'environnement, préparation d'exfiltration de données et exécution de commandes suspectes. La version de base comprend 309 règles qui peuvent être étendues pour votre infrastructure.

L'idée a émergé de l'expérience avec les compétitions d'agents d'IA, où les participants recevaient délibérément des instructions malveillantes. Dans de telles tâches, les agents pourraient être demandés d'oublier les règles précédentes, d'afficher le prompt système, de lire .env, ~/.

ssh ou /proc/self/environ, de décoder les payloads et d'exécuter quelque chose au nom de l'utilisateur. C'est pourquoi l'auteur du plugin a placé la protection en dehors du modèle lui-même : si une commande dangereuse a déjà atteint l'exécution de l'outil, il est trop tard pour réagir. Le filtre est positionné plus tôt et vérifie à la fois les messages de l'utilisateur et les arguments des outils.

L'intégration dans opencode est construite sur deux hooks. Le premier transforme les messages avant de les envoyer au modèle et recherche les signes d'injection de prompt dans les champs de texte, y compris text, prompt, command et source.value.

Le second s'active avant l'exécution de l'outil et analyse non seulement le chemin du fichier, mais aussi le nom de l'outil, la commande shell, le texte de la demande et d'autres arguments. Si une règle correspond, la demande ne va pas plus loin : pour le modèle, elle est remplacée par un refus sûr, et l'exécution de l'outil s'arrête simplement avec une erreur de politique. Cette approche rend le comportement prévisible et pratique pour l'audit.

Actuellement, le plugin compte 282 règles pour les appels d'outils et 27 règles contre l'injection de prompt. Elles sont stockées en JSON et fonctionnent comme un ensemble de politiques regex. Les signatures typiques tombent sous le blocage, comme "ignore previous instructions," les fausses balises [developer] et [system], les commandes printenv et echo $TOKEN, les références à /run/secrets et /proc/self/environ, ainsi que les tentatives de codage de données via base64, xxd ou openssl enc.

Chaque déclenchement est enregistré dans un journal JSONL avec horodatage, type d'événement et identifiant de règle. Cela aide à enquêter sur les incidents, à trouver les faux positifs et à ajouter rapidement de nouveaux motifs basés sur les attaques réelles. Le côté pratique a également l'air maximalement pragmatique.

Le plugin est installé avec une seule commande npm install opencode-policy et connecté via la configuration opencode, après quoi les messages et les appels d'outils sont automatiquement exécutés à travers la couche de règles avant l'exécution. L'auteur souligne particulièrement que l'ensemble des politiques est ouvert et peut être étendu pour votre infrastructure spécifique, et l'approche elle-même est compatible avec les modèles locaux s'ils fonctionnent via opencode. Cela rend la solution utile non seulement pour les assistants cloud, mais aussi pour les boucles d'agents internes au sein des entreprises.

Il est particulièrement important que l'auteur s'appuie consciemment sur des mécanismes simples et transparents plutôt que sur une autre couche de LLM sur LLM. Pour certaines menaces, la sémantique complexe n'est vraiment pas nécessaire : les noms de fichiers secrets, les commandes de sortie d'environnement et les modèles de demande jailbreak sont assez spécifiques. L'approche regex est plus simple à examiner, à mettre à jour et à lier à des cas spécifiques, et après un incident, une nouvelle règle peut être ajoutée littéralement point par point.

Cette conception conservatrice est particulièrement utile là où la reproductibilité et les tests déterministes sont nécessaires, pas l'évaluation probabiliste des risques. Un tel filtre en lui-même ne remplace pas le sandboxing, les restrictions de privilèges, les listes blanches d'outils et l'isolation réseau. Mais pour les systèmes d'agents travaillant avec du code, shell, CI/CD, des référentiels internes et des secrets, il ferme une couche importante de défense précoce.

La valeur principale ici est dans la prévisibilité : les règles sont lisibles par l'homme, faciles à examiner et à tester, et la protection ne dépend pas du modèle qui se cache sous le capot. Face à la croissance des agents d'IA autonomes, cela ne ressemble pas à une option supplémentaire, mais à une hygiène de base pour la production.