cplt - AI coding agent に kernel sandbox を重ねる
AI coding agent の risk は、「間違った code を書く」ことだけではありません。Agent は command を実行し、file を読み、package manager を動かし、build script を起動できます。README、issue、dependency script、MCP tool に含まれる prompt injection に誘導される可能性もあります。Chat UI の確認 button だけでは、subprocess や local credential の境界を十分に守れません。
今日紹介する navikt/cplt は、その問題に向けた tool です。Rust 製の single-binary sandbox wrapper で、GitHub Copilot CLI、OpenCode、Gemini CLI、Antigravity CLI、Pi、または通常の shell を制限された environment で実行できます。Agent は project directory の code を編集できますが、SSH、cloud provider、Kubernetes、Docker、password store などの sensitive directory を読みづらくし、localhost service や危険な Git operation への access も抑えます。
公開時点の GitHub search result では、約 87 stars、13 forks。主な言語は Rust、license は MIT です。Repository は 2026-04-09 に作成され、最近の update は 2026-06-15 です。GitHub releases の latest redirect は 2026.06.15-083243-168c1cb を指していました。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| Repository | navikt/cplt |
| 位置づけ | AI coding agent 向け local sandbox wrapper |
| Stars | 約 87 |
| Forks | 13 |
| 主な言語 | Rust |
| License | MIT |
| Latest version | 2026.06.15-083243-168c1cb |
解いているのは local agent の trust boundary
多くの team は今、agent を developer machine で動かし、real repository の中で test、dependency install、file edit、commit generation を任せています。効率は高いですが、その分 local environment が agent process とその subprocess にさらされます。
cplt の approach は、development flow を完全な VM や Docker に移すことではありません。既存の CLI agent の外側に OS-level restriction を重ねます。
cplt -- -p "fix the tests"
cplt --agent opencode
cplt --agent shell
cplt exec -- npm installmacOS では Apple Seatbelt / SBPL、Linux では Landlock LSM と seccomp-BPF を使います。README の説明はかなり具体的です。Project directory は主な workspace として使えますが、credential directory、sensitive file pattern、SSH agent socket、localhost outbound connection、443 以外の port などは制限されます。Agent が prompt injection によって ~/.ssh を読もうとしたり local service を探索しようとしたりしても、process は system-level restriction に当たります。
これは「model に悪いことをしないよう頼む」のとは別の防線です。前者は prompt と product interaction、後者は process が実際に file を開けるか、socket に接続できるか、binary を実行できるかという境界です。
Policy を repository に入れられる
cplt は per-repo policy を support しています。Team は .cplt.toml を生成して commit し、project に必要な permission を明示できます。たとえば特定 port、JVM attach、Docker access などです。Developer は初回実行時に明示的に trust します。
この design は team use に向いています。Agent permission が、各自の shell にある見えない長い argument ではなくなります。Reviewer は repository がなぜ特定の sandbox exception を必要としているかを確認でき、security team も default deny の template を作りやすくなります。
README には command-level guard もあります。git と gh の high-risk operation、たとえば push、merge、release、delete などを制限できます。Agent が「test を直す」task の中で、これらの操作を黙って実行する必要はほとんどありません。事後に git reflog を見るより、あらかじめ auditable な boundary にしておく方が扱いやすいです。
Default protection は現実的な漏れ道を見ている
cplt の block list は具体的です。単に「more secure」と言うより参考になります。Default で意識している exposure surface は次のようなものです。
- SSH、GPG、cloud provider、Kubernetes、Docker、1Password、Terraform などの credential directory。
- Project 内の
.env*、.pem、.keyなどの sensitive file pattern。 .git/hooks、.git/config、.gitmodulesなど、persistence や Git behavior hijack に使われ得る場所。/tmpや cache directory に書き込んだ binary を後から実行する動き。- SSH agent socket、localhost outbound connection、non-HTTPS port access。
- Package manager lifecycle scripts と environment variable injection の risk。
すべての project がこれらを同時に抱えるわけではありません。ただ、coding agent が越えやすい境界はまさにここです。Agent は developer と同じように tool を実行できますが、machine にどんな long-lived credential があるかを本当に理解しているわけではありません。cplt は「project directory は書ける」と「machine 全体を読める」を分離します。
Docker や VM の replacement ではない
重要なのは、cplt 自身が過剰な主張をしていないことです。README と security document には limitation が明記されています。
macOS 側の file rule は強い一方、Apple が deprecated としている sandbox-exec に依存します。Linux 側は Landlock のために kernel 5.13+ が必要で、完全な TCP port filtering にはより新しい kernel が必要です。また Landlock は、allowed directory の中の subpath を macOS と同じ粒度で deny できません。Project は、完全に分離された filesystem や process namespace が必要なら Docker や VM にはまだ価値がある、と明示しています。
むしろここが cplt の見どころです。これは「ultimate security」ではなく、実用的な middle layer を選んでいます。会社支給 laptop では Docker が使えないこともあり、remote disposable environment をすぐ整えるのも難しい場合があります。その一方で、Homebrew や release binary で入れられ、normal CLI と近い startup cost で使える sandbox は、daily workflow に入りやすいです。
既存 agent tool との関係
cplt は別の coding agent ではありません。Agent launcher と policy layer に近い存在です。README では GitHub Copilot CLI、OpenCode、Gemini CLI、Antigravity CLI、Pi、通常 shell が対象として挙げられています。つまり、使う agent はそのままで、entrypoint を cplt に変えるだけです。
この positioning は gradual adoption に向いています。Team は model、IDE、CI を同時に変える必要がありません。まずひとつの repository で試せます。
cplt init --write
cplt trust accept --all
cplt config set git_guard.enabled true
cplt config set gh_guard.enabled trueそのうえで、どの test、build、package manager command が block されるかを観察し、必要なものだけ allow します。Security tool は、最初から development environment の全面変更を求めると回避されがちです。cplt の利点は、agent entrypoint に default restriction を置きながら、必要な escape hatch も残していることです。
向いている場面
cplt は、次のような team や個人に向いています。
- Local repository で CLI coding agent をすでに使っている。
- Agent や subprocess に SSH、cloud、Kubernetes、Docker、package manager credential を読まれたくない。
- Agent permission を口頭ルールではなく repository policy にしたい。
git push、gh pr merge、release などの high-risk command を agent が自動実行するのを避けたい。- Full VM / Docker sandbox はまだ重いが、裸の agent 実行より boundary を増やしたい。
唯一の security boundary として扱うべき tool ではありません。High-sensitivity code を扱う project や、threat model が strong isolation を要求する場合は、remote disposable environment、container、VM、より狭い credential、CI-side validation も検討すべきです。cplt は、daily local agent use に実用的な protection layer を足す tool として見るのが現実的です。
まとめ
navikt/cplt は、AI coding agent 導入後の現実的な問題を捉えています。Agent は便利になるほど real development environment に近づきます。そして real development environment には、気軽に読まれたり呼ばれたりしてはいけない long-lived permission が多すぎます。
cplt は Rust single binary と OS kernel sandbox を使い、project は書ける、credential は読めない、network は制限される、Git の high-risk command は control される、という boundary を組み合わせます。Copilot、OpenCode、Gemini CLI などを daily development flow に入れている team なら、まずひとつの repository で試し、どの permission が本当に必要で、どれが裸の tool 実行で暗黙に exposed されていただけなのかを見る価値があります。