ThinkWatch

ThinkWatch：一站式企业级 AI 网关与 MCP 安全管控平台

开篇：从一次"AI 助手"失控说起

某天下午，公司的 AI 助手突然以员工"张三"的名义，往 GitHub 仓库里 push 了一段可疑代码。上游 GitHub 的审计日志清楚地记录着"张三"的身份——可实际上，张三根本不知道这件事发生了。这是经典的 MCP 工具权限滥用 问题：AI 助手持有的是管理员授予的高权限 Token，却没有任何机制让工具知道"谁在真正调用它"。

ThinkWatch 正是为解决这类问题而生的。它是一个自托管的 AI API 与 MCP 网关，部署在企业内网，所有 AI 请求和 MCP 工具调用都必须经过它。网关负责统一认证、权限管控、PII 脱敏、流量审计和成本核算——就像堡垒机（Bastion Host）管理服务器 SSH 访问一样，ThinkWatch 管理整个组织的 AI 访问。

背景：企业 AI 落地的安全盲区

随着 Claude Code、Cursor、Copilot 等 AI 编程工具在企业中普及，一个新的安全问题浮出水面：这些工具需要访问 GitHub、Notion、Slack 等第三方服务，而授予它们的 Token 往往是高权限的。没有一层网关，企业根本无法追踪"谁用 AI 做了什么"，也无法防止敏感数据通过 AI 工具泄露。

现有方案存在明显缺陷：

• 直接使用 OpenAI API：没有 MCP 支持，无法管控工具调用
• 通用 API 网关：缺少针对 AI/MCP 的专用功能（PII 脱敏、MCP 工具权限、用户身份映射）
• 无审计：操作不留痕，合规审计无法通过

ThinkWatch 填补了这个空白，定位为 AI 访问层面的企业级管控平台。

核心功能：三层防护体系

第一层：身份与访问控制

ThinkWatch 支持对接任意 OIDC 身份提供商（Zitadel、Okta、Azure AD 等），AI 请求经过网关时，会用企业目录中的真实用户身份去访问上游工具。这意味着 GitHub 的审计日志会显示具体操作人，而非一个共享的管理员账号。

同时，ThinkWatch 内置了 5 种内置角色（Admin、Developer、Viewer 等），每个 MCP 工具都可以按角色和按 API Key 分别授权。用户可以将自己的 GitHub Token、Notion Token 等通过 OAuth 或个人令牌的方式关联到 ThinkWatch，令牌在传输和存储时全程加密。

第二层：安全防护

每个经过网关的请求，都会接受多层安全检查：

• PII 脱敏：邮件地址、电话号码、银行卡号等敏感信息在请求发出前被替换为占位符，响应返回后还原，包括流式响应
• 危险指令拦截：模型回复中的工具调用指令会与规则库匹配，阻止危险操作
• Unicode 攻击防护：隐藏字符和提示注入攻击会被记录或直接拒绝
• 频率限制与预算管控：按用户、角色或 API Key 设置 QPS 上限、月度预算，避免资源滥用

第三层：审计与合规

所有请求和工具调用都会被写入 ClickHouse 审计日志，包含请求体（可配置大小阈值，超大请求自动上传至 S3 兼容存储）、用户身份、调用的工具、响应状态等信息。审计日志支持企业合规场景的留存要求。

技术架构：Rust + 微服务的性能与安全

ThinkWatch 的核心由 Rust 语言编写，采用 Workspace 微服务架构，分为以下几个核心 crates：

• gateway：AI API 网关，处理 OpenAI 兼容的 /v1/chat/completions 等接口，将请求转发给上游 LLM 提供商（OpenAI、Anthropic、Google Gemini、Azure OpenAI、AWS Bedrock）
• mcp-gateway：MCP 协议网关，解析 MCP 工具调用请求，进行权限校验和身份映射
• server：Web 管理控制台（Console），提供 React 前端 + 管理 API
• auth：认证与授权模块，处理 OIDC、TOTP、JWT 等
• common：共享类型定义和工具函数

前端采用 React 构建，后端存储使用 PostgreSQL（元数据）、Redis（缓存、会话）和 ClickHouse（审计日志）。

容器化与部署

部署方式非常灵活：

• Docker Compose 一键部署：适用于中小规模团队，docker compose -f deploy/docker-compose.yml up -d 即可启动完整栈（包含 PostgreSQL、Redis、ClickHouse、Nginx）
• Helm Chart：适用于 Kubernetes 生产环境，有 production 级 values 配置示例
• 手动二进制部署：支持从 GitHub Releases 下载预编译二进制或自行 cargo build

需要注意的是，生产环境部署涉及多个外部依赖（PostgreSQL、Redis、ClickHouse），且需要通过 bash deploy/generate-secrets.sh 生成密钥并配置 OIDC Provider，部署门槛属于中等水平，适合有 Docker 和基础设施经验的团队。

使用场景与门槛

场景	说明
团队 AI 工具管控	所有 AI 编程工具（CURSOR/Claude Code）通过 ThinkWatch 代理，强制审计
MCP 工具安全	企业内部 MCP 服务器（如内部 Notion、Confluence）通过 ThinkWatch 对外暴露，限制外部访问
合规审计	金融、医疗等合规要求严格的行业，记录所有 AI 操作
成本分摊	按部门/用户统计 AI 调用成本，避免滥用

上手门槛方面，Docker Compose 部署约 30-60 分钟（不含环境准备），需要手动配置 OIDC Provider 和生成密钥。对于开发者而言，使用 ThinkWatch 的门槛很低：应用只需要将原来指向 OpenAI 的请求改为指向 ThinkWatch 的网关地址（:3000），API 完全兼容 OpenAI 格式，无需修改代码。

局限与挑战

尽管功能完善，ThinkWatch 也存在一些局限：

• Rust MSRV 要求较高：最低支持 Rust 1.85（2024 Edition），部分老系统可能无法直接编译
• OIDC 配置复杂度：需要企业有现成的身份提供商，对小型团队有一定门槛
• 存储依赖较多：PostgreSQL + Redis + ClickHouse 三种存储缺一不可，运维成本不低
• 社区规模有限：目前 Star 数约 800+，项目较新，生态和插件还在建设中
• 非完全零配置：docker-compose 虽是"一键"，但必须先生成 .env.production 并配置外部服务，不是开箱即用

行业意义与趋势

ThinkWatch 代表的，是 AI 安全访问控制这一细分领域的兴起。随着 AI 编程工具在企业中的渗透，**"AI 堡垒机"**的需求会越来越强烈。类似的产品还有：

• Portkey：云端 AI 网关，更偏向观测和追踪
• Aerfaloop：轻量级 MCP 安全代理
• Gateguard：新兴开源 MCP 网关项目

ThinkWatch 的差异化在于：完整的自托管方案 + MCP 原生支持 + PII 脱敏 + 企业级审计，在当前开源生态中功能最为全面。

总结

ThinkWatch 是一款针对企业 AI 访问安全管控的开源利器，通过在 AI 工具和企业上游服务之间架设一层网关，实现了身份映射、权限管控、PII 脱敏、审计日志和成本分摊五大能力。对于已经在使用或计划大规模部署 AI 编程工具的企业来说，它是目前开源生态中功能最完整的企业级 MCP 安全网关解决方案。

一句话评价：ThinkWatch = AI 领域的"零信任网关"，让每一次 AI 操作都有据可查、有权可控。