Pipelock: AI agent の外向き通信に検証可能な境界を足す
ローカルで AI coding agent を動かすとき、本当に怖いのは「モデルが間違ったコードを書く」ことだけではない。むしろ、agent が実際にかなり強い権限を持っていることのほうが厄介だ。
環境変数を読める。shell を叩ける。repository に触れる。package を入れられる。browser を開ける。さらに MCP server 経由で社内 tool や外部 service にもつながる。そこへ悪意ある webpage、dependency、tool description、remote document が混ざると、本来 machine の外に出してはいけない情報が egress path に乗ってしまう。
よくある対策は、SDK、middleware、agent wrapper の中に安全ロジックを入れることだ。この方向にも意味はある。ただし agent 自身がその wrapper を通り続ける、という前提が残る。実際の network request が別経路に逃げたり、MCP server の response が agent を誘導したりすると、境界はかなり曖昧になる。
今日メモしておきたい luckyPipewrench/pipelock は、もう少し外側を切っている。agent から network、MCP、その他 transport surface へ出る流量を、検査・遮断・署名付き証跡化できる mediation layer に通す、という発想だ。
GitHub repository page、README、release / changelog page、default branch の shallow clone から 2026-07-05 に確認できる公開情報では、この project は現在およそ 740 stars、87 forks。repository の主言語は Go、core code の license は Apache-2.0。repository 作成日は 2026-02-08。default branch main の最新公開 commit は 2026-07-04 の a1dd7ad、commit message は fix(baseline): enforce behavioral baseline on A2A methods (#894)。最新 release は v3.0.0 で、GitHub release page 上の公開時刻は 2026-06-23 21:27 UTC、CHANGELOG でも 3.0.0 は 2026-06-23 とされている。
Project Overview
| 属性 | 内容 |
|---|---|
| Repository | luckyPipewrench/pipelock |
| 位置づけ | AI agent egress firewall / MCP security control |
| Stars | 740 |
| Forks | 87 |
| 主言語 | Go |
| Core license | Apache-2.0 |
| Repository 作成日 | 2026-02-08 |
| Default branch 最新 commit | 2026-07-04, a1dd7ad |
| Latest version | v3.0.0 |
| Release time | 2026-06-23 21:27 UTC |
| 核心アイデア | agent の egress point で検査・遮断・検証可能な証跡化を行う |
解いているのは「agent が強すぎる権限を持った後」の境界問題
Pipelock の README は、問題をかなり直接的に書いている。agent の environment には API key があり、shell と network access もある。そこから secret を含む outbound request が 1 本飛ぶだけで事故になる。
そのため Pipelock は「agent にそうしないよう頼む library」だけではなく、agent と外界の間に入る boundary として設計されている。README が挙げる対象 surface は HTTP、WebSocket、CONNECT、MCP、A2A。主に見るのは次の 3 つだ。
- secret、token、credential などの外部送信;
- remote content、MCP response、page 由来の prompt injection;
- SSRF、path traversal、危険な URL 形状、encoding bypass。
これはローカル AI coding workflow ではかなり現実的な話だ。Codex、Claude Code、OpenCode、Cursor、Cline のような tool の危なさは、単に「network に出られる」ことではない。network access、local credential、source code、internal document、MCP tool が同じ実行現場に置かれがちなことにある。最後に人間が diff を review するだけでは、こうした outbound side effect までは拾いきれない。
Pipelock の見方は、network と MCP call を独立した境界で一度通してから、agent に作業を続けさせる、というものだ。
block だけでなく receipt が面白い
この project は、怪しい request を見つけて block するだけの tool ではない。README が繰り返し強調している概念に action receipt がある。mediation layer が実際に検査した内容と allow / block decision に対し、署名付きの証跡を生成する。
ここが重要だ。
local log だけなら、事後に agent、proxy layer、log 自体を信じる必要がある。SDK の return value だけなら、すべての action が本当にその SDK を通ったのかも信じなければならない。Pipelock は証拠を agent process の外側に出し、mediator が署名することで、third party が agent runtime の外で「この request はどんな判断を通ったのか」を検証できるようにしようとしている。
これはいくつかの場面で効く。
- team が agent に network access を許可しつつ、どの request が通り、どれが止まったかを知りたい;
- security team が MCP server の tool call を監査したい;
- CI や sandbox で agent に自動作業させるが、offline verification できる evidence chain を残したい;
- enterprise 環境で、信頼を特定 model や IDE plugin だけに寄せたくない。
つまり価値は「一度の leak を止める」だけではない。agent の egress behavior を、あとから追跡できる object に変えるところにある。
MCP はかなり相性のよい切り口
MCP が持ち込む問題は双方向だ。
agent が tool を呼ぶとき、arguments に出してはいけない内容が混ざるかもしれない。逆に MCP server から返る tool list、tool description、result content が agent を危険な方向へ誘導することもある。Pipelock の README は MCP に対する bidirectional scanning を明示している。client request は DLP を見る。server response は injection を見る。tools/list では poisoned description や session 中の tool 変化も見る。
これは「HTTP URL だけを scan する」より、いまの agent workflow に近い。
多くの developer はすでに filesystem、GitHub、database、browser、Slack、internal API などの MCP server を local client につないでいる。server が 1 つ増えるたびに、agent の action surface は広がる。Pipelock のような tool は、MCP を禁止したくはないが裸のままにもしたくない、という場所に置きやすい。
v3.0.0 の方向性: default をより fail-closed にする
最新 release / CHANGELOG を見ると、v3.0.0 の主眼は派手な UI 追加ではなく、default security posture を締めることにある。
CHANGELOG に出ている方向はわかりやすい。MCP response enforcement は default でより厳しくなる。self-update は signed release manifest を要求する。security posture を弱める config hot reload は拒否される。provider key DLP coverage も強化されている。
もちろん、この種の変更にはコストがある。fail-closed default は、最初の導入時に allowlist、config、false positive 調整を増やしがちだ。ただ security boundary tool としては、「default allow で、事故後に考える」より筋がよい。
向いている人
Pipelock は、次のような人が試す価値のある tool だと思う。
- local AI coding agent を高頻度で使い、agent が network、document、script をよく触る人;
- 複数の MCP server を接続し、tool description、response content、outbound request の境界が気になり始めた人;
- CI、sandbox、team workstation で agent の audit evidence を残したい人;
- traditional web traffic だけでなく、agent egress そのものを観測したい security team。
逆に、たまに agent に CSS を直させる程度の軽い使い方なら、最初から必要な tool ではない。価値が出るのは、agent を高権限な環境に入れていて、検証可能な境界のために設定コストを払う意思がある場面だ。
注意点
第一に、これは魔法のお守りではない。README に出てくる network isolation、sandbox、proxy、MCP wrapper といった経路は、流量をどう Pipelock に通すかをちゃんと設計する必要がある、という意味でもある。Pipelock を通らない request は、当然 Pipelock では守れない。
第二に、open-source core と enterprise directory がある。repository root の license は Apache-2.0 だが、README badge には Enterprise ELv2 も出ている。引用、packaging、redistribution では core code と enterprise feature の境界を分けて見る必要がある。
第三に、security tool には false positive と false negative がある。特に prompt injection、DLP pattern、encoding bypass のような rule は、入れた瞬間に安心するものではない。check、doctor、audit log、receipt を実際の workflow に流し込みながら調整する使い方のほうが現実的だ。
まとめ
Pipelock が面白いのは、AI agent の security boundary は prompt の中だけに書くものではなく、agent 自身の協力だけに任せるものでもない、と割り切っているところだ。
agent が local machine を読み、command を実行し、network に出て、MCP tool を呼べるなら、egress layer には独立した checkpoint が必要になる。Pipelock はそこに scanning、blocking、sandbox、signed evidence を置き、「agent が何をしたか」を chat log や terminal output だけに閉じ込めない。
この tool は agent を賢くするものではない。ただ、agent を現実の workflow に置くための不安をかなり具体的に減らしてくれる。