kontext-cli

当 AI 有了"上帝之手"：Kontext 如何给工具型 Agent 装上安全阀

凌晨三点的惊魂一幕

某天晚上，开发者小李让 Claude Code 帮他在生产数据库上执行一次数据迁移。Claude Code 爽快接受任务，却在执行路径时多走了一步——它"顺带"删除了一个被误认为临时表的归档分区。数据恢复花了整整 8 小时，事后复盘时，没有人说得清到底是 Agent 理解错了指令，还是它根本没有"感知"到这是危险操作。

这并非孤例。随着 Claude Code、Cursor、Copilot Workspace 等工具型 AI Agent 越来越深入软件开发栈，一个根本性矛盾正在浮现：Agent 的能力越强，它能造成的破坏也就越大。一条看似无害的 rm -rf 指令、一封被注入恶意 Prompt 的邮件、一组被悄悄替换的 API 凭证，都可能在 Agent 的放大镜下演变成一场数据灾难。

Kontext 正是在这个背景下诞生的。这是一个开源的运行时安全平台，专为"工具型 AI Agent"（tool-using AI agents）设计，提供精细化权限控制、凭证管理、策略执行和完整的操作审计链。

---

背景：为什么 Agent 安全是 2024 年后最紧迫的工程问题

传统 AI 安全讨论大多聚焦于"模型本身"——Prompt 注入、数据泄露、对抗样本。但当模型被包装成 Agent、获得了工具调用能力之后，攻击面发生了质变：

• 能力错配：Agent 可以读写文件、操作数据库、调用 API、发送邮件，但默认情况下没有任何机制告诉它"什么该做、什么不该做"。
• 指令模糊性：用户的自然语言指令存在歧义，而 Agent 倾向于"尽力而为"，导致行为边界模糊。
• 第三方插件风险：许多 Agent 依赖第三方 MCP（Model Context Protocol）工具，这些工具的安全状态对用户完全不透明。

Kontext 的核心假设是：与其事后审计，不如在执行前设置门卫（Guard）。这是一个从零设计的运行时安全层，类似于 Linux 的 seccomp 或 BPF，但专门面向 AI Agent 的工具调用场景。

---

核心架构：两层安全决策引擎

Kontext 的安全机制分为两个层次，顺序执行：

第一层：确定性策略（Deterministic Policy）

基于预定义规则，对明显的危险行为直接拦截。规则类别包括：

• 凭证访问（如读取 .env、keychain、系统密钥链）
• 直接调用云服务商 API 并携带凭证材料
• 生产环境数据库写操作
• 破坏性持久资源操作（如删除 S3 bucket、销毁云实例）

这是"硬拦截"，非黑即白，不需要模型参与判断。

第二层：概率风险评估（Probabilistic Risk Score）

对于确定性策略放行的行为，Kontext 会将其路由到一个本地 Judge（评判器）进行二次评估。默认使用 llama.cpp 下载的 GGUF 量化模型，运行在本地，不上传任何上下文数据到云端。Judge 输出"允许"或"拒绝"，但决策过程不依赖外部服务。

这种本地优先（local-first）的设计理念是 Kontext 与同类商业产品最显著的差异点——你的代码、工具调用记录、凭证访问日志都不会离开你的机器。

---

本地模式（Guard）：开发者的"沙盒演练场"

Kontext 提供了一个开箱即用的本地安全模式，称为 Guard。在本地模式下：

• 不需要登录，不需要连接 Kontext 云端服务
• 守护进程（daemon）监听在 127.0.0.1:4765 的 Unix 域 socket 上
• 事件数据存储在本地 SQLite 数据库（已做脱敏处理）
• 内嵌一个本地 Web Dashboard，可在浏览器中实时查看 Agent 的行为决策

Guard 模式的决策流程：

Claude Code
  -> kontext hook --agent claude --mode observe
  -> local runtime Unix socket
  -> RuntimeCore
  -> deterministic policy（确定性策略）
  -> probabilistic risk（概率风险评估，通过本地 Judge）
  -> allow / deny
  -> local SQLite（事件存储）
  -> local dashboard（实时可视化）

开发者可以在 observe 模式（只记录，不拦截）和 enforce 模式（真实拦截）之间切换，在真实使用中积累策略规则。

---

凭证管理：把密钥从"明文裸奔"变成"动态授权"

Kontext 另一个杀手级功能是凭证注入（Credential Injection）。在传统工作流中，开发者常常需要将 API 密钥、OAuth Token 等凭证：

• 粘贴到聊天窗口（安全隐患极大）
• 写入 .env 文件（提交到 Git 后难以撤销）
• 硬编码在配置文件（权限粒度过粗）

Kontext 引入了基于 RFC 8693 OAuth 2.0 Token Exchange 的凭证管理机制。Agent 需要访问某个 API 时，不是直接持有凭证，而是通过 Kontext 获取一个短生命周期、最小权限范围的 Token，绑定到当前用户、会话或工作流。这从根本上消除了凭证"裸奔"的问题。

---

技术实现：Go + SQLite + Web 前端

Kontext CLI 完全使用 Go 1.25 编写，核心依赖包括：

• connectrpc.com/connect — gRPC/HTTP2 通信框架
• spf13/cobra — CLI 命令行框架
• modernc.org/sqlite — 纯 Go SQLite 驱动（无 CGO 依赖）
• golang.org/x/oauth2 — OAuth 凭证管理
• google.golang.org/protobuf — Protocol Buffers IDL（通过 buf 管理）

项目使用 buf 管理 Protobuf 定义，服务定义存放在独立仓库 kontext-security/proto，通过 MCP（Model Context Protocol）标准接口与外部 Agent 通信。

前端部分（Guard Dashboard）是一个独立的 React + Vite + TypeScript + TailwindCSS Web 应用，通过 pnpm monorepo 管理，与 Go 后端松耦合。打包时通过自定义脚本将前端资源嵌入 Go binary，发布为一个独立可执行文件。

项目使用 Homebrew 作为 macOS 的官方分发渠道，Linux/Windows 则通过 go build 自行编译。项目根目录提供了完整的 Makefile，包含测试（go test ./...）、构建（go build -o bin/kontext ./cmd/kontext）和端到端测试脚本。

---

支持的 Agent 与局限性

目前已支持：

• Claude Code（主力支持，自助安装 kontext setup 即插即用）
• Claude Cowork（Claude 官方推出的协作 Agent）
• ** Goose、Codex、Cursor**（路线图规划中，尚未发布）

需要注意的是，当前版本主要面向 macOS 环境（LaunchAgent、Keychain 深度集成），Linux 支持需要自行处理 systemd 服务和密钥链适配。

---

一句话总结

Kontext 是 AI Agent 时代的"门卫系统"——它通过确定性策略 + 本地 AI 评判器，在 Agent 执行任何工具调用之前说"可以"或"不行"，同时记录完整审计链，让开发者既能享受 Agent 的效率红利，又不至于在凌晨三点面对数据库废墟。

---

快速上手

# macOS / Linux 一键安装
brew install kontext-security/tap/kontext

# 初始化本地安全模式
kontext setup

# 启动本地守护进程和 Dashboard
kontext start

# 查看本地安全状态
kontext doctor

# 从源码构建
git clone https://github.com/kontext-security/kontext-cli
cd kontext-cli
go build -o bin/kontext ./cmd/kontext
./bin/kontext start

---

数据来源：GitHub 仓库分析（stars: 210★, license: MIT, language: Go, topics: ai-agents, credential-management, security-tools 等）