AI agent が実際の workflow に入ると、risk は「少し間違った code を書く」だけでは済まない。より厄介なのは tool を呼べることだ。File を読む、shell を走らせる、issue を触る、production resource にアクセスする、credential を使う。Prompt で「慎重にやって」と伝えるだけでは足りない。危険な action が発生する境界は自然言語ではなく tool call だからだ。

今日見るのは kontext-security/kontext-cli。これは AI agent 向けの runtime governance layer という位置づけだ。Local hook で tool-use event を受け取り、action が実行される前に policy decision を行い、allow、deny、または would-deny の結果を local authorization ledger に記録する。Managed deployment では、redacted record を Kontext dashboard に export することもできる。Install path は Homebrew から始まる。

brew install kontext-security/tap/kontext
kontext setup
kontext doctor

GitHub repository API、README、Releases、Tags、default branch commit history、docs/coverage.md を 2026-08-05 時点で確認すると、kontext-security/kontext-cli は 210 stars、7 forks。主要言語は Go、license は MIT。Repository created time は 2026-04-05 09:12:57 UTC、latest push は 2026-08-05 09:31:51 UTC。Default branch の現在の latest commit は 812284a、commit time は 2026-08-05 09:31:29 UTC、commit message は chore(main): release 1.0.0 (#432)。最新 GitHub Release と最新 Git tag はどちらも v1.0.0 で、release published time は 2026-08-05 09:31:52 UTC。

プロジェクト概要

項目内容
リポジトリkontext-security/kontext-cli
位置づけtool-using AI agents 向け runtime governance / authorization CLI
Stars210
Forks7
主要言語Go
ライセンスMIT
作成日時2026-04-05 09:12:57 UTC
Latest push2026-08-05 09:31:51 UTC
現在の default branch commit812284a、2026-08-05 09:31:29 UTC
最新 GitHub Releasev1.0.0、2026-08-05 09:31:52 UTC
キーワードagent security、policy enforcement、audit ledger、credential management、CLI、Go、MCP

扱っているのは、tool 実行直前の一秒

Kontext の考え方は分かりやすい。Agent が tool を呼ぼうとしたら、まず local runtime を通す。その runtime が event を記録し、action を分類し、deterministic policy を適用し、結果を ledger に書く。Synchronous pre-action hook を持つ agent なら、実際の実行前に止められる。Blocking しない、あるいはまだ enforcement を開かない場面では、observe mode で would-allow / would-deny を記録する。

この境界は「あとから log を眺める」より実用的だ。Agent が destructive shell command を実行しようとする、sensitive file を読もうとする、data を外部 service に export しようとする、production resource へアクセスしようとする。こうした action では、発生後ではなく発生前に判断したい。README の flow も明確で、agent の tool call が hook から daemon に渡り、local policy が allow、deny、または would-decision を返し、それが local authorization ledger に記録される。

Developer team にとっての価値は、危険な command を止めることだけではない。Agent behavior の chain of custody を残せることも大きい。誰がどの agent に何をさせ、tool input は何で、policy はどう判断し、結果はどうなったのか。Incident が起きたとき、chat log から推測するのではなく、tool call ledger から事実を見られる。

Observe mode が現実的な default

Security tool は、最初から厳しすぎると workflow を壊しやすい。Kontext の現在の姿勢はかなり現実的だ。まず observe、次に enforce。Observe mode は developer の action を止めず、policy が本来どう判断したかを記録する。Team はしばらく運用し、false positive と本当に止めるべき action を見極めてから enforce mode を有効にできる。

Agent tool ではこの段階が特に重要だ。「危険」は固定の command だけで決まらない。rm -rf dist は build workflow では妥当かもしれないが、rm -rf ~/.ssh はまったく違う。ある token への access は deploy flow では必要でも、普通の refactor では suspicious だ。Kontext の deterministic rules は、destructive commands、sensitive files、production systems、data exports、credential access など既知の boundary を扱う。v1.0.0 release には local risk annotation / guardrail LLM の path も出てくるが、README は local model が optional setup step だとも説明している。つまり、LLM judge だけが安全線ではない。

ここがこの project の面白いところだ。Security decision をすべて model に任せるのではなく、説明しやすい policy boundary を先に置き、曖昧な risk detection を補助として扱っている。

Credential を prompt に入れない

多くの agent workflow で脆いのは credential だ。Agent に GitHub、Linear、cloud service、internal API を触らせるために、developer は token を environment variable や config file に置きがちだし、最悪の場合は chat context に貼ってしまう。Kontext の README と repository topics は credential management / secret management を強調している。狙いは、scoped credential を runtime boundary で渡すことであって、agent に大きな鍵を長く持たせることではない。

Project docs が示す方向は、短命で least-privilege、user や workflow に紐づいた credential を、tool が本当に必要とするタイミングで使えるようにすることだ。Managed deployment をすぐ採用しないとしても、この設計は重要な問題を思い出させる。Agent security は「prompt を漏らさない」だけではなく、credential lifecycle、access scope、audit evidence の問題でもある。

すでに agent に GitHub、issue tracker、CI、cloud resource を触らせている team なら、この credential boundary は「token を project .env に置いて、agent が乱用しないと信じる」より保守しやすい。

支持状況は matrix を見る必要がある

README は docs/coverage.md を agent support matrix の source of truth としている。現在の main branch の matrix では、Claude Code は session start/end、pre-tool-use、post-tool-use を記録し、pre-tool-use で block できる。Claude Cowork は hook protocol level で supported。Codex も live support に入っており、session start、pre-tool-use、post-tool-use、user-prompt-submit、stop を記録し、pre-tool-use は block 可能、post-tool-use と user-prompt-submit も block result を受け取れる。

ここは明確に書くべき点だ。「ある agent を support する」は logo を並べることではない。Kontext 自身も、どの lifecycle event が runtime に届くのか、そのうちどれが action を止められるのか、install method は何かを説明する必要があると言っている。Self-serve setup は現在 macOS path で、local daemon と Claude Code / Codex hook config を入れる。Codex 側では hook を trust する必要もある。その他の agent は compatible hook adapter で runtime に接続できるかもしれないが、matrix に event contract と enforcement behavior が document され test されるまでは正式 coverage ではない。

つまり、Kontext は agent security boundary を本気で扱いたい team 向けであり、「install すればすべての AI tool が自動で安全になる」と期待する user 向けではない。

v1.0.0 が示していること

今回の v1.0.0 release 自体にも情報がある。Release notes の breaking change は legacy managed sessions の廃止。追加項目には risk annotation、endpoint-config v2、doctor が source revision で build を識別する変更、managed daemon 内の guardrail LLM、observe-mode bash risk classifier、optional local risk model setup が並ぶ。

特に engineering detail として面白いのは doctor だ。Agent security tool 自体の daemon version と CLI version がずれていると、「install したように見えるが実際には守れていない」状態になる。Latest commit は build identity を扱い、version string だけでなく source revision で daemon と CLI の一致を確認する方向に直している。この種の detail は product copy には出にくいが、developer machine で長く動く tool にはかなり効く。

Caveat

第一の caveat は platform と hook の現実的な boundary だ。Self-serve install は現在主に macOS で、他の environment では managed deployment や self-hosted path を確認する必要がある。Agent ごとに exposed hook event が違うため、enforcement capability も一律ではない。Record できることと、すべての event を block できることは同じではない。

第二の caveat は、project がまだ若いことだ。Repository は 2026-04-05 作成で、v1.0.0 に到達しているとはいえ、stars と forks はまだ小さく、open issues と PR も活発に動いている。Team の強制 security path に入れる前に、observe mode でしばらく走らせ、rules、hooks、daemon lifecycle、dashboard export、local ledger が自分たちの flow に合うか確認したほうがよい。

第三の caveat は、tool があっても security ownership は消えないこと。Kontext は runtime gate と audit evidence を提供できるが、policy そのものは team が保守する必要がある。どの directory が sensitive か、どの command が high-risk か、どの credential を agent に渡せるか、どの action に human approval が必要かは、自分たちで決める話だ。

まとめ

kontext-security/kontext-cli が面白いのは、agent security を「model に気をつけろと言う」段階から、「tool call 前の local authorization path」に移しているところだ。Agent が command を実行し、file を読み、credential を使い、外部 system を変更できるなら、この boundary は今後さらに重要になる。

Claude Code、Codex、または hook を公開できる agent を本格的に使っているなら、Kontext は watch list に入れてよい。Sandbox、permission management、code review を置き換える silver bullet ではないが、実用的な空白を埋めている。Agent が手を動かす前に、audit 可能で、configure できて、必要なら止められる runtime policy があるべきだ。

リポジトリ：https://github.com/kontext-security/kontext-cli