8.0
热点
AI SCORE
技术实践2026-08-19 09:33
AI编程Agent不应默认获得Shell访问权限
dev.to · AI#安全#AI编程#Agent
Editor brief · 编辑速览
深入分析AI coding agent的能力边界问题，指出代码审查等任务不需要shell执行权限，过度授权带来安全隐患。
AI 编程助手正在变得越来越擅长处理真实代码库。
它们可以检查仓库、在多个文件间追溯 bug、提出架构变更建议、编写测试，越来越多地实现完整功能。
但有一个安全问题，我认为我们正在过快略过：
AI 实际上需要多少访问权限才能完成有用的工作？
当我想让 AI 模型审查我的代码时，我通常希望它做这些事情：
理解项目结构；阅读源文件；搜索符号或模式；追溯组件间的交互；识别 bug；审查提议的实现方案。
这些任务本身都不需要无限制的 shell 访问。
然而许多 Agent 工作流将代码访问与以下能力捆绑在一起：
执行 shell 命令；运行 Git；启动进程；读取任意文件系统位置；修改任意文件。
这使得 Agent 变得强大得多。
同时也大大增加了出问题时的爆炸半径。
更强的模型不一定需要更强的权限。
审查认证实现，告诉我你是否发现任何安全问题。
对于这个任务，模型需要的是信息。
它需要读取相关仓库。
但它可能不需要以下权限：
当写出来时这似乎显而易见。
但开发者工具通常将仓库访问和机器访问视为几乎相同的东西。
我想把它们分开。
传统安全工程有一个简单的理念：
给系统只授予完成工作所需的权限。
AI Agent 不应该是例外。
如果我使用一个模型作为审查者，它的权限应该反映审查者的角色。
✓ 列出仓库文件 ✓ 读取已批准的文件 ✓ 搜索仓库
✗ 执行 shell 命令 ✗ 运行 Git ✗ 启动进程 ✗ 读取仓库外的目录 ✗ 任意修改源代码
这不能消除所有风险。
但它把问题从：
"我信任这个 AI 使用我的电脑吗？"
变成了一个窄得多的问题：
"我信任这个 AI 通过这些特定操作检查这个仓库吗？"
这是一个更容易推理的安全边界。
我最近围绕这个理念构建了一个名为 RepoRelay 的开源项目。
RepoRelay 是一个 MCP 服务器，位于 AI 客户端和本地仓库之间。
架构大致是：
AI / ChatGPT
↓
Secure MCP connection
↓
RepoRelay
↓
one explicitly approved repository
RepoRelay 没有暴露通用的 shell 或文件系统 API，而是暴露了一组刻意精简的仓库操作。
只读 surface 本质上是：
open_workspace
list_files
read_file
search_files
重要的不是工具的数量。
而是没有哪些东西。
没有 shell 工具。
没有 Git 工具。
没有进程执行工具。
没有通用的"在任意位置写文件"工具。
已批准的仓库成为了边界。
"一个仓库"听起来简单。实际上并非如此。
基于文件系统路径的安全边界有很多边缘情况。
检查请求的路径是否以：
/approved/repo/
开头是远远不够的。
像这样的工具必须考虑这些事情：
.. 遍历例如，对以下路径的请求：
../../some-other-project/.env
显然应该失败。
但不太明显的逃脱机制同样重要。
因此 RepoRelay 将containment 作为强制执行的安全属性而非提示指令。
AI 不会被告知：
"请留在这个文件夹内。"
服务器应该通过它暴露的工具使离开文件夹变得不可能。
这个区别很重要。
即使在已批准的仓库内，也有一些文件我通常不希望 AI 审查者读取。
最明显的例子是：
仓库也可能包含凭据、私钥或其他敏感材料。
所以"AI 可以读取这个仓库"不应该自动意味着：
"AI 可以读取这个目录下的每一个字节。"
RepoRelay 独立于仓库根边界单独阻止敏感路径类别。
这给你两层保护：
这个路径在批准的仓库内吗？
↓
是
↓
这个文件允许被暴露吗？
↓
是
↓
读取
同样，这不是什么革命性的安全理论。
它是将已有理念应用到 AI 工具中。
这引导我做出另一个设计决策。
我经常使用一个 AI 系统实现代码，用一个更强的模型审查结果。
这是不同的角色。
实现者可能确实需要本地执行能力：
审查者通常不需要。
所以与其给两个 Agent 相同的权限，我更喜欢这样的工作流：
Local coding agent
↓
implements change
↓
repository / commit
↓
RepoRelay
↓
strong reviewer model
↓
review
这也创造了有用的关注点分离。
写代码的模型不一定是判断代码是否好的模型。
但如果审查者需要请求更改呢？
纯只读访问是最干净的安全模型，RepoRelay 支持它。
但我也想尝试一个受限的审查者→实现者工作流。
RepoRelay 可以暴露几个预定的交接文件，而不是允许任意写入。
ChatGPT
↓
NEXT_TASK.md
↓
local coding agent
↓
implements changes
↓
RESULT.md
审查者可以传达接下来应该发生的事情，而不需要获得对源代码树的通用写权限。
这与以下权限完全不同：
"编辑你想要的任何文件。"
目标不是零能力。
目标是有界限的能力。
操作系统级隔离是有价值的，像 RepoRelay 这样的工具不能替代容器、VM、沙箱或正确的系统权限。
那些解决的是更广泛的问题。
RepoRelay 试图在应用层解决一个更窄的问题：
这个特定的 AI 客户端应该能够调用哪些操作？
这些层可以相互补充。
你最终可能拥有：
OS / container sandbox
+
MCP-level capability restrictions
+
repository containment
+
sensitive-file filtering
安全在不依赖单一控制时往往效果更好。
我认为安全导向的项目应该明确说明它们的局限性。
RepoRelay 不是操作系统沙箱。
如果恶意软件已经在你的用户账户下运行，MCP 服务器无法神奇地保护机器其余部分免受该软件侵害。
它也不会使 AI 生成的代码变得安全。
审查者仍然可能漏掉漏洞。
目的更窄：
减少授予 AI 连接本身的权限。
如果任务需要读取四个源文件，给予模型执行任意命令的能力是不必要的额外权限。
随着模型改进，我认为权限设计会变得更加重要，而不是减少。
具有强大权限的弱模型是危险的，因为它可能犯错。
具有强大权限的非常强大的模型值得仔细思考，原因不同：它可以做更多事情。
答案不能简单是：
"模型现在更聪明了，所以给它一切。"
对于这个任务，最小有用接口是什么？
对于代码审查，这个接口可以小得惊人。
而且一旦权限是明确的，它们就更容易检查、测试、审计和推理。
RepoRelay 仍然是一个全新的项目，我正在积极开发安全模型和开发者体验。
它采用 MIT 许可证，在 GitHub 上可用：
你可以通过 npm 安装：
npm install -g reporelay-mcp@latest
我特别感兴趣来自从事 MCP、Agent 安全、本地优先工具和编码 Agent 工作流的人的反馈。
我确信有很多威胁模型假设和边缘情况我还没有考虑到。
这也是我想使其开源的部分原因。
更广泛的问题比 RepoRelay 更大：
当 AI 只需要访问你的代码时，为什么我们要自动给它访问你机器的权限？