Agent 运行时防护：沙箱、权限模型与命令拦截

Agent 安全不能只依赖模型自觉。

模型可以生成计划，也可以解释风险，但真正决定能不能执行命令的，必须是运行时安全层。

这篇文章讨论一个 Agent 运行时防护系统应该怎么设计。

一、核心原则

运行时防护的核心原则是：

模型负责提出动作，安全运行时负责判断动作是否允许。

也就是说，即使模型说“这个命令是安全的”，运行时仍然要独立检查。

一个基本执行链路可以设计成：

Agent 生成工具调用
运行时解析工具参数
策略引擎评估风险
低风险直接执行
中风险记录并执行或提示
高风险要求用户审批
禁止行为直接阻断
结果进入审计日志

二、权限模型

Agent 的权限不应该是“全有或全无”，而应该拆成细粒度 capability。

常见 capability 包括：

filesystem.read
filesystem.write
process.execute
network.connect
plugin.invoke
secret.read
remote.control
system.modify

每个 capability 都可以绑定范围。

例如文件权限：

{
  "filesystem.read": {
    "allow": ["$WORKSPACE/**"],
    "deny": ["$HOME/.ssh/**", "$HOME/.aws/**", "**/.env"]
  },
  "filesystem.write": {
    "allow": ["$WORKSPACE/**"],
    "deny": ["$WORKSPACE/.git/**", "$HOME/**"]
  }
}

网络权限：

{
  "network.connect": {
    "allow": ["github.com", "registry.npmjs.org"],
    "confirm": ["*.internal.company.com"],
    "deny": ["unknown"]
  }
}

命令权限：

{
  "process.execute": {
    "allow": ["git status", "npm test", "npm run build"],
    "confirm": ["npm install", "pip install", "curl", "brew"],
    "deny": ["sudo", "rm -rf /", "launchctl", "schtasks"]
  }
}

实际工程里不能只做字符串匹配，最好解析命令结构。

三、命令风险分级

命令可以按风险分成四类。

低风险

一般只读、可逆、限定在工作区：

ls
pwd
git status
git diff
npm test
npm run lint

中风险

可能修改工作区或安装依赖：

npm install
pip install
cargo update
git checkout
git clean
修改配置文件

高风险

可能影响系统、凭证或外部数据：

sudo
curl | sh
chmod -R
rm -rf
launchctl
schtasks
读取 .env
读取 ~/.ssh
上传压缩包

禁止

明显破坏性或无法合理解释的行为：

删除根目录
读取并上传私钥
绕过系统安全策略
禁用审计
修改安全工具配置

高风险不一定全部禁止，但必须给用户明确上下文：

Agent 想做什么
为什么需要做
会访问哪些文件
会连接哪个网络地址
是否可回滚

四、文件系统隔离

Agent 的默认工作范围应该是 workspace，而不是整个用户目录。

文件系统策略建议分层：

默认允许当前工作区读
默认允许当前工作区写
默认拒绝工作区外写
默认拒绝敏感目录读
特殊目录需要用户授权

敏感路径包括：

~/.ssh
~/.gnupg
~/.aws
~/.kube
~/Library/Keychains
%USERPROFILE%\.ssh
%APPDATA%
.env
.npmrc
.pypirc
shell history

文件隔离不能只发生在 UI 层。因为 Agent 可能通过子进程间接访问文件，运行时需要在命令执行前做预判，在执行中做监控。

五、网络出站控制

数据外泄通常需要网络。

Agent 的网络控制可以按目标域名、端口、进程和插件维度做策略：

允许访问包管理器和代码托管平台
内网地址按企业策略控制
未知外部域名触发审批
上传行为触发更高风险评级
插件网络权限单独授权

需要重点识别：

curl
wget
scp
rsync
nc
自定义脚本发请求
npm/pip postinstall 网络请求

如果能做到网络代理层统一审计，会比只拦命令更可靠。

六、用户审批设计

审批不是弹窗越多越安全。

好的审批应该具备三个特点：

解释清楚风险
给出最小授权范围
支持一次性授权

例如：

Agent 请求读取 /Users/me/project/.env
原因：运行测试需要数据库连接配置
风险：该文件可能包含密钥
授权范围：
- 仅本次读取
- 仅允许读取变量名，不显示变量值
- 拒绝

审批要避免“永久允许所有操作”。这会让权限模型失效。

七、审计闭环

运行时防护不仅要拦，还要记。

审计日志建议包含：

task id
用户 id
模型请求
工具名称
工具参数
策略评估结果
用户审批结果
执行开始和结束时间
退出码
脱敏后的输出摘要

日志要能回答两个问题：

安全事件发生时，发生了什么？
产品误拦时，为什么会拦？

这对安全运营和产品体验都很重要。

八、工程架构

一个简化架构可以是：

Agent Planner
    |
Tool Call Request
    |
Security Runtime
    |-- Command Parser
    |-- Policy Engine
    |-- Secret Detector
    |-- Approval Manager
    |-- Audit Logger
    |
Sandbox Executor
    |
Tool Result

其中 Security Runtime 是核心边界。任何工具调用都应该经过它。

九、Roadmap 中的位置

在 AI 终端安全 Roadmap 里，运行时防护是从“风险认知”走向“工程控制”的关键层：

我会把 Agent 的执行权限拆成文件、进程、网络、插件、凭证、远程控制等 capability，由运行时安全层统一拦截工具调用。模型只负责提出动作，策略引擎独立判断是否允许。低风险动作自动执行，高风险动作要求用户审批，敏感路径和危险命令默认阻断。同时对命令、文件、网络和插件调用做审计，并对日志进行脱敏。

这层能力决定了 AI Agent 能否在真实终端环境里既可用又可控。