Bloquez le fetch qui atteint votre endpoint de métadonnées.
Une requête côté serveur vers une URL fournie par l'utilisateur peut pivoter vers 169.254.169.254 et voler des identifiants cloud. L'IA l'écrit dès qu'une fonctionnalité « récupère une URL donnée par l'utilisateur ». SlopGrade la bloque en CI avant le merge.
Une URL contrôlée par l'utilisateur, fetchée côté serveur.
Rien ne valide l'hôte, donc un attaquant le pointe vers le service de métadonnées cloud ou un panneau d'admin interne. Une allowlist de la destination corrige ça — le gate bloque le fetch non-allowlisté.
Ce que l'IA a livré
Ce qui quitte votre runner
Chemin, ligne, classe. Sur un repo privé, le contenu du fichier reste sur le runner par défaut ; le deep scan (heisen-slop) est une option payante. Auditez-le avec --print-payload.
Détecte → adapte → vérifie. Par défaut, rien d'autre ne sort.
Dans votre runner, sur le diff
Le client open source parcourt la pull request et signale le motif en local — dataflow intra-fonction. Par défaut, aucun code ne quitte la machine.
Verdict serveur + gate
L'empreinte structurelle est classée côté serveur. Un hit dur bloque le check sur un repo privé payant ; les repos publics sont gatés gratuitement ; le paywall échoue en mode ouvert.
Posté inline, re-vérifié au push
Le constat est posté sur sa ligne exacte. Pour les quelques classes qui ont une réécriture sûre et déterministe (vérification TLS coupée, debug actif, yaml.load…), un correctif est généré ET vérifié dans votre runner ; sinon vous corrigez, et le push suivant re-vérifie.
Et si l'URL est partiellement validée ?
Une allowlist de destination (schéma + hôte) est reconnue comme sûre. Un simple contrôle de protocole (startsWith https) ne l'est pas — il autorise encore les hôtes internes. Le gate est calibré sur cette distinction.
Quels langages ?
JavaScript/TypeScript et Python pour la classe complète ; Go et .NET couvrent les motifs fetch/client-HTTP cœur.