Kontext CLI：给 AI agent 工具调用加一层运行时安全门
AI agent 真正进工作流之后，风险通常不在“它会不会写错一段代码”这么简单。更麻烦的是它能调用工具：读文件、跑 shell、访问 issue、碰生产资源、拿 credential。靠 prompt 告诉 agent “请小心一点”不够，因为危险动作发生在工具调用边界，而不是自然语言边界。
今天看的是 kontext-security/kontext-cli。它把自己定位成 AI agent 的 runtime governance 层：通过本地 hook 接收 tool-use event，在动作执行前做策略判断，把 allow、deny 或 would-deny 结果写进本地 authorization ledger，并且可以在 managed deployment 里导出脱敏记录到 Kontext dashboard。安装入口是 Homebrew：
brew install kontext-security/tap/kontext
kontext setup
kontext doctor按 GitHub repository API、README、Releases、Tags、默认分支 commit history 和 docs/coverage.md 在 2026-08-05 能核验的公开信息，kontext-security/kontext-cli 当前有 210 stars、7 forks。仓库主语言是 Go，许可证是 MIT。仓库创建于 2026-04-05 09:12:57 UTC，最近 push 是 2026-08-05 09:31:51 UTC。默认分支当前最新提交是 812284a，提交时间 2026-08-05 09:31:29 UTC，提交信息是 chore(main): release 1.0.0 (#432)。最新 GitHub Release 和最新 Git tag 都是 v1.0.0，Release 发布时间是 2026-08-05 09:31:52 UTC。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | kontext-security/kontext-cli |
| 定位 | 面向 tool-using AI agents 的 runtime governance / authorization CLI |
| Stars | 210 |
| Forks | 7 |
| 主要语言 | Go |
| 许可证 | MIT |
| 创建时间 | 2026-04-05 09:12:57 UTC |
| 最近 push | 2026-08-05 09:31:51 UTC |
| 当前默认分支提交 | 812284a，2026-08-05 09:31:29 UTC |
| 最新 GitHub Release | v1.0.0，2026-08-05 09:31:52 UTC |
| 关键词 | agent security、policy enforcement、audit ledger、credential management、CLI、Go、MCP |
它处理的是工具调用之前的那一秒
Kontext 的核心思路很直接：agent 想调用工具时，先经过一层本地 runtime。这个 runtime 记录事件、分类动作、应用确定性策略，再把结果写入 ledger。支持同步 pre-action hook 的 agent，可以在真正执行前被拦下；不适合阻断或还没打开 enforcement 的场景，则先用 observe mode 记录 would-allow / would-deny。
这个边界比“事后扫日志”更有用。比如 agent 想执行 destructive shell command、读取敏感文件、把数据导出到外部服务、访问生产资源，策略应该在动作发生前给出答案。README 里把这个流程写得很明确：agent 发出 tool call，hook 交给 daemon，本地 policy 决定 allow、deny 或记录 would-decision，最后写入本地 authorization ledger。
对开发团队来说，这个模型的价值不只是“挡危险命令”。更重要的是它给 agent 行为留下链路证据：谁让哪个 agent 做了什么、工具输入是什么、策略怎么判、结果如何。出了问题时，你不需要从聊天记录里倒推上下文，而是从工具调用账本里看事实。
Observe mode 是务实的默认值
安全工具很容易一上来就把工作流卡死。Kontext 当前的默认思路比较现实：先 observe，再 enforce。Observe mode 不打断开发者动作，但会记录策略原本会怎样判断。团队可以先跑一段时间，看哪些规则误伤、哪些动作确实需要硬拦，再打开 enforce mode。
这对 agent 工具尤其重要，因为“危险”并不总是固定命令。rm -rf dist 在构建脚本里可能合理，rm -rf ~/.ssh 就完全不同；访问某个 token 在部署流程里可能必要，在普通代码重构里就可疑。Kontext 的确定性规则可以处理已知边界，例如 destructive commands、sensitive files、production systems、data exports 和 credential access；v1.0.0 release 还提到本地 risk annotation / guardrail LLM 路径，但 README 也说明本地模型是可选步骤，不应把它当成唯一安全线。
这也是我觉得它值得写的地方：它没有把安全判断全部交给模型，而是先用策略边界把可解释的部分做掉，再把更模糊的风险识别作为补充。
凭据不是塞进 prompt 的
很多 agent workflow 最脆弱的地方是 credential。为了让 agent 访问 GitHub、Linear、云服务或内部 API，开发者常常把 token 放进环境变量、配置文件，甚至直接贴进聊天上下文。Kontext 的 README 和 repo topic 都强调 credential management / secret management，它的定位是把 scoped credential 注入运行时边界，而不是让 agent 长期持有一把大钥匙。
项目文档里提到的方向是：用短期、最小权限、与用户或 workflow 绑定的 credential，在工具真正需要时交给 agent 可用的路径。即使不马上采用完整 managed deployment，这个设计也提醒了一个关键问题：agent 安全不是“别泄漏 prompt”这么窄，它还包括 credential 生命周期、访问范围和审计记录。
如果团队已经在让 agent 调 GitHub、issue tracker、CI 或云资源，这种 credential boundary 会比“把 token 放进项目 .env，然后相信 agent 不会乱用”更像一个可维护的工程方案。
当前支持面需要看矩阵
README 明确说 docs/coverage.md 是 agent support matrix 的 source of truth。当前 main 分支里的矩阵显示：Claude Code 支持 session start/end、pre-tool-use、post-tool-use，并且 pre-tool-use 可阻断；Claude Cowork 在 hook protocol 层面支持；Codex 也已经列入 live support，记录 session start、pre-tool-use、post-tool-use、user-prompt-submit、stop，其中 pre-tool-use 可阻断，post-tool-use 和 user-prompt-submit 也可以接收 block result。
这点要写清楚，因为“支持某个 agent”不能只看 logo。Kontext 自己也强调，支持意味着要说明哪些 lifecycle event 会到达 runtime，哪些 event 能阻断动作，以及安装方式是什么。比如 self-serve setup 目前是 macOS 路径，会安装本地 daemon 与 Claude Code / Codex hook 配置；hook 还需要在 Codex 里被 trust。其他 agent 可以通过兼容 hook adapter 接入 runtime，但没有在矩阵里文档化和测试前，不应当算作正式覆盖。
换句话说，它适合愿意认真处理 agent 安全边界的团队，不适合期待“装上之后所有 AI 工具自动安全”的用户。
v1.0.0 的信号
这次 v1.0.0 release 本身也有信息量。Release notes 里列出 breaking change：retire legacy managed sessions。新增项包括 risk annotation、endpoint-config v2、doctor 用 source revision 识别 build、managed daemon 运行 guardrail LLM、observe-mode bash risk classifier，以及可选本地 risk model setup。
这里最有工程味的是 doctor。Agent 安全工具如果自己 daemon 版本和 CLI 版本不一致，就会出现“看起来装了，实际上守不住”的状态。最新提交专门处理 build identity，用 source revision 而不只是 version string 判断 daemon 是否和当前 CLI 匹配。这类细节不会出现在产品口号里，但会决定工具能不能长期跑在开发者机器上。
Caveat
第一个 caveat 是平台和 hook 现实边界。自助安装当前主要是 macOS，其他环境要看 managed 或自建部署方式。不同 agent 暴露的 hook event 不一样，所以 enforcement 能力不是统一的；能记录，不等于每个事件都能阻断。
第二个 caveat 是它还很年轻。仓库 2026-04-05 创建，虽然已经到 v1.0.0，但 star 和 fork 仍然不大，open issues 和 PR 还在活跃变化。把它放进团队强制安全链路之前，最好先在 observe mode 跑一段时间，确认规则、hook、daemon lifecycle、dashboard export 和本地 ledger 都符合自己的流程。
第三个 caveat 是安全职责不会因为有工具就消失。Kontext 可以提供 runtime gate 和 audit evidence，但策略本身仍然要有人维护。哪些目录算敏感、哪些命令算高风险、哪些 credential 可以给 agent、哪些动作必须人类审批，这些都需要团队自己定义。
总结
kontext-security/kontext-cli 有意思的地方，是它把 agent 安全从“提醒模型要小心”移到了“工具调用前的本地授权路径”。当 agent 能跑命令、读文件、拿凭据、改外部系统时，这个边界会越来越重要。
如果你已经在认真使用 Claude Code、Codex 或其他能暴露 hook 的 agent，Kontext 值得放进观察列表。它不是替代 sandbox、权限管理或代码审查的银弹，但它补上了一个很实际的缺口：agent 每次动手之前，应该有一层可审计、可配置、能阻断的 runtime policy。