Réglages de sécurité

Une machine-labo dédiée n’est pas un bot public — et ce n’est pas non plus « juste ChatGPT dans un onglet ». Avec les outils allumés, l’agent peut agir comme un opérateur shell puissant, sous l’utilisateur OS et le backend que vous lui avez donnés. Le gateway doit échouer fermé : les inconnus n’atteignent jamais les outils par défaut, comme l’explique le guide sécurité ↗.

• ·Machine : préférez une machine dédiée ou un VPS ; ordinateur du quotidien seulement avec isolation Docker ↗ (ou équivalent) pour les outils.
• ·Modèles cloud (OpenRouter / OpenCode / similaires) : la conversation et le contexte lié quittent votre machine vers les hôtes de modèles — rangez les secrets en conséquence.
• ·Réalité shell : les backends d’outils peuvent lire / écrire des fichiers et lancer des commandes à l’intérieur de leur frontière d’isolation — traitez cette frontière comme réelle, ou comme cassée.

• ·Mettez les utilisateurs du gateway de messagerie sur liste d’autorisation (échec fermé si elle n’est pas posée).
• ·Approbations : manual | smart (défaut) | off — le cours utilise smart ou manual. YOLO est réservé aux experts et ne contourne quand même pas la blocklist dure.
• ·Les timeouts refusent par défaut quand vous ne répondez pas.

• ·Filtrage des secrets : gardez les tokens hors des prompts et des environnements enfants MCP quand c’est possible — pratiquez ça dans le lab rotation des clés.
• ·Scans d’injection sur SOUL / AGENTS.md / fichiers de contexte, quand c’est activé.
• ·Réseau : les protections SSRF bloquent les plages privées ; n’ouvrez que pour un service local de confiance que vous comprenez.
• ·Moindre privilège par profil : la recherche n’a pas besoin d’une surface d’outils de code.
• ·Plus tard, optionnel : les suggestions d’approbation minent vos décisions passées — elles ne doivent jamais auto-appliquer des classes destructrices.