问题
在 Cursor 中开启 Auto-review Run Mode 的用户，同时维护个人仓库和生产/客户仓库，但该设置是应用级的，无法按工作区区分，导致“生产或客户仓库也无法单独使用 Allowlist 或每次询问”。写入型 MCP 服务器（工单更新、部署、云变更）同样没有独立于 shell Run Mode 的运行策略，无法在 Auto-review 会话中强制每次询问。AnythingLLM 用户面临类似问题：MCP 授权是全局的，“authorizes all Agent enabled Threads across all Workspaces”。Grok bot 用户也抱怨 connector 应用“request write access in the OAuth grant with no way to configure the scope”。共同痛点：把执行权交给 AI 代理后，缺少细粒度的权限边界。
目标用户
在 Cursor、AnythingLLM 等工具中让 AI 代理连接 MCP 服务器的开发者，尤其是同时操作生产/客户仓库的个人开发者和小团队。信号均来自开发者社区论坛与 GitHub Issues，属于典型的 prosumer/小团队自服务人群；单条讨论互动量不高（最高 16 分、10 评论），说明需求真实但当前声量偏小。
解决方案
- 本地 MCP 网关/代理：客户端（Cursor 等）把 MCP 服务器地址指向网关，网关再转发到真实服务器，对上层完全透明
- 按 workspace 的策略配置：策略以可提交到 git 的文件形式存在，团队共享；UI 明示当前生效的作用域
- 按 MCP 服务器的运行策略：每个服务器可独立设为 always ask / 分类器审核 / allowlist；只读服务器可直通，写型服务器强制逐条审批
- 审批卡机制：所有变更类调用（写操作）弹出审批，批准范围可选 this session / this workspace / global，参考信号 3 提出的“确保所有 POST/PUT/PATCH/DELETE 调用必须经过用户确认”
- 审计日志：记录每次被拦截与放行的调用，便于事后追溯
AI 的角色：网关本身不做智能决策（MVP 阶段规则优先），但为后续的 Auto-review 式分类器留出接口，可对灰区操作做风险分级。
为什么是现在
信号显示行为正在变化：Auto-review 这类“让代理自动执行”的模式已经上线并被日常使用，写入型 MCP（部署、云变更、工单更新）正在接入代理会话，用户开始在生产/客户仓库场景暴露权限边界问题，并在 2025-2026 年集中提出 per-workspace、per-MCP 策略的需求——代理获得执行权是新增风险，权限治理是随之而来的新缺口。
MVP 范围
第一版只做：本地 MCP 网关 + 按 workspace 的策略文件 + 对写类 MCP 工具调用的逐条审批卡。明确不做：Grok bot 等 connector 的 OAuth scope 改写、Auto-review 分类器本身、AnythingLLM 深度集成。
风险
- 平台依赖：四个信号全是针对 Cursor、AnythingLLM、Grok bot 官方的 feature request，官方随时可能原生实现，机会窗口短。
- 协议风险：依赖 MCP 协议与 Cursor 客户端行为，协议或客户端更新可能破坏网关兼容性。
- 采用摩擦：用户需要把 MCP 服务器指向网关并改配置，门槛不低。
- 信任与责任：产品本身是安全边界，一旦审批逻辑出漏洞（写操作漏拦），信誉损失大。
- 无付费证据：所有信号 willingness_to_pay 均为 none，商业化路径不明。
已有产品
| 产品 | 定位 | 价格 |
|---|---|---|
| Cursor IDE | 痛点的主要来源平台，Auto-review Run Mode 目前只有应用级设置，官方补齐该功能将直接吞掉机会 | — |
| AnythingLLM | MCP 授权目前为全局生效，社区已提出按 workspace 划分工具权限的需求 | — |
| agent-airlock | 被用户在相关讨论中提及，方向上与 MCP 读写隔离接近 | — |
信号证据
这张卡片依据的原始讨论。摘录保持原文，点“原文”查看上下文。
Cursor 论坛 · Ideas9月30日功能请求▲ 00 条评论
“I want to use more of the connector apps on grok bot but a lot of them request write access in the OAuth grant with no way to configure the scope.”
用户希望对 grok bot 的 connector 应用有更细的 OAuth scope 控制,以及可配置的固定 approval 机制,避免写操作未经确认就被执行。原文
Cursor 论坛 · Ideas9月30日功能请求▲ 0
“+1, this is needed for MCP servers that can write.”
Cursor 缺少按工作区和按 MCP 服务器配置 Auto-review 运行模式的机制，尤其是对可写入的 MCP 服务器。原文
Cursor 论坛 · Ideas9月29日功能请求▲ 01 条评论
“A write-capable MCP (ticket updates, deploys, cloud mutations) should always ask, even when the rest of the session is on Auto-review.”
MCP 服务器没有独立于 shell Run Mode 的运行策略,写入型 MCP(工单更新、部署、云变更)无法在 Auto-review 会话中强制每次询问。原文
Cursor 论坛 · Ideas9月29日功能请求▲ 01 条评论
“A personal repo can stay on Auto-review. A production or client repo should stay on Allowlist, or ask every time.”
Auto-review Run Mode 在 Cursor 中是应用级别的,无法按工作区设置不同的安全级别,导致生产或客户仓库也无法单独使用 Allowlist 或每次询问。原文
GitHub Issues · Mintplex-Labs/anything-llm5月20日功能请求▲ 1610 条评论
“Current implementation requires the MCP tool flow to manage auth to the external service in the chat context using tool parameters, or via global env supplied in AnythingLLM config that authorizes all Agent enabled Threads across all Workspaces for each configured MCP server.”
AnythingLLM users want workspace- and user-scoped MCP agent tool access instead of global auth across all workspaces.原文