Si t'as livré quoi que ce soit avec un agent codant IA — Claude Code, Cursor, Aider, Codex, outillage interne — t'as pensé à ce qui arrive quand l'agent a un accès shell *et* tes clés API *et* du réseau sans restriction. « Un appel d'outil compromis qui leak les credentials vers un domaine contrôlé par un attaquant », c'est pas théorique; c'est la forme structurelle. Pipelock, un firewall open-source pour agents IA publié par Joshua Waldrep sous le projet PipeLab, comble le gap avec le choix architectural qui compte : l'application *hors* du processus de l'agent. Apache 2.0, binaire Go d'environ 20 Mo, actuellement à v2.3.0, sur GitHub à luckyPipewrench/pipelock.
Le split de capacités est le design porteur. Le processus de l'agent garde les secrets, n'a pas d'accès réseau direct. Le proxy a l'accès réseau, pas de secrets. Le trafic traverse une frontière de scan entre les zones. L'isolation réseau est appliquée au niveau du déploiement — namespaces réseau, iptables, Docker, Kubernetes NetworkPolicy — pas à la couche applicative où l'agent pourrait la désactiver. Le pipeline de scan en 11 couches couvre l'exfiltration de credentials (48 patterns couvrant clés API, tokens, comptes financiers, clés privées crypto, avec quatre validateurs de checksum), l'injection de prompt (25 patterns avec six passes de normalisation), SSRF, path traversal, budgets DLP par domaine, et des scans côté réponse pour caractères invisibles, homoglyphes et évasion par leetspeak. La couverture inclut HTTP forward proxy, tunnels CONNECT, frames WebSocket, Model Context Protocol stdio, et le protocole Agent-to-Agent de Google. Reçus de preuve signés Ed25519, intégration SARIF v2.1.0 dans GitHub Code Scanning, mappings de conformité vers OWASP MCP Top 10, MITRE ATT&CK, EU AI Act, SOC 2, NIST 800-53.
Le cadrage que donne Waldrep, c'est l'argument architectural que l'espace sécurité-d'agents avait besoin d'entendre : *« La plupart des outils de sécurité d'agents ont encore besoin de la coopération de l'agent. Ces contrôles marchent seulement tant que l'agent continue de les appeler. »* C'est le split SDK-vs-proxy. Chaque approche sécurité-par-callback a la même faiblesse structurelle — un agent compromis ou jailbreaké arrête d'appeler la librairie de sécurité, et les contrôles s'évaporent. L'application hors-processus n'a pas besoin de coopération; la frontière réseau est appliquée par l'OS, pas par l'agent. Attends-toi à ce que ce pattern devienne standard pour tout déploiement d'agent en production avec de vrais credentials dans le scope. Pipelock n'est pas le seul projet à aller dans cette direction (couches d'exécution sandboxées, permissions d'outils en mTLS, le système de permissions de Claude Code d'Anthropic) mais c'est l'articulation open-source la plus propre du shift architectural.
Si tu fais rouler des agents IA en production avec accès shell et appels API credentialisés, c'est le genre de chose qui appartient entre l'agent et le réseau — pas comme remplacement aux guardrails dans l'agent, comme filet de sécurité quand ces guardrails se font contourner. Apache 2.0 + binaire Go + couverture MCP + A2A veut dire que c'est déployable aujourd'hui. Lis le threat model dans le README GitHub avant d'intégrer; les budgets DLP par domaine et les passes de normalisation pour injection de prompt nécessitent un calibrage selon ton cas d'usage. L'intégration SARIF veut dire que les findings se branchent dans ton pipeline de sécurité existant sans rebâtir la télémétrie. Le mouvement plus gros est structurel : arrête de faire confiance à l'agent pour se policer lui-même.