Prompt Injection 防不住时，怎样把 AI 编程 Agent 关进最小权限“隔间”？QuantmLayer 实战
让 Claude Code、Codex 一类编程 Agent 直接操作本地仓库，效率很高，但它们默认继承的是启动它们的 shell 权限。这个事实比“模型会不会写错代码”更需要优先处理：一个被错误指令诱导的 Agent，理论上能读取当前用户可见的 SSH 私钥、云端凭据与配置文件，也能访问网络、拉起进程或耗尽机器资源。
QuantmLayer 是一个面向 Linux 的 Rust 安全运行时，项目采用 Apache-2.0 许可证。它的思路不是判断模型的意图，也不声称能识别 prompt injection；它把边界下沉到运行时：即使 Agent 的任务上下文已经被污染，进程仍只能访问策略明确允许的文件、网络地址和可执行程序。对需要让 Agent 在真实本地工作树中修改代码的团队，这是一种介于“直接在宿主机运行”和“把代码同步到远程沙箱”之间的选择。
先区分：模型层防护与动作层约束
提示注入、错误目标和不可靠工具描述发生在模型与上下文层。它们当然值得处理，但仅靠提示词规则无法替代操作系统权限边界。QuantmLayer 的定位是动作层：它限制被启动进程最终能做什么，而不是判断请求本身是否恶意。
README 描述的隔离单元综合了 Linux namespace、挂载隔离、seccomp、cgroup 和网络控制。实际效果应理解为一组可组合的墙，而不是一句“安全沙箱”的口号：挂载规则可让工作区之外的敏感路径不可见；网络策略把出站访问限制在允许范围；cgroup 用于资源限制；seccomp 则限制系统调用面。项目也提供针对 MCP 的配置重写与请求检查入口，适合把“能启动 MCP 服务”与“允许它执行什么状态变更”分开管理。
这和远程云沙箱并不互斥。远程沙箱把执行移动到另一台机器，适合运行不可信生成代码；QuantmLayer 的目标则是让 Agent 在本机真实代码、已有工具链和工作目录旁运行，同时缩小它获得的宿主机能力。前者减少本机资产暴露，后者减少本地协作时的默认权限，两者应按任务风险组合，而非互相替代。
从内置 Agent 配置开始，而不是先写大策略
首次试用不要直接让 Agent 修改重要仓库。先在一次性测试目录安装，并让工具报告这台 Linux 主机能启用哪些隔离层：
curl -fsSL https://raw.githubusercontent.com/quantmlayer/quantmlayer/main/scripts/install.sh | sh ql doctor ql agent claude
ql doctor 很关键。不要因为工具安装成功，就假定所有内核控制都已生效。README 明确说明，Linux 是主要执行环境；Windows 与 macOS 需要在已有 Linux 环境中运行实际隔离单元，例如 WSL2 或轻量 Linux VM。不同内核、用户命名空间策略与权限配置会改变最终可用的墙。
上面的 --audit run.jsonl 适合保留一次运行的审计线索，但日志不能替代复核。它回答的是“发生过什么”，而不是“这项操作是否应该被允许”。对写代码任务，仍要保留 Git diff、测试输出和人工审查作为独立证据。
用学习模式生成最小权限草案
手工列出一个 Agent 所需的每条文件和网络权限，很容易过宽，也容易漏掉依赖。QuantmLayer 提供“先观察、再执行”的路径：先从一个固定、可复现的任务收集行为，再把结果作为策略草案检查。
ql learn --out agent.yaml -- ./my-agent build ql run --profile agent.yaml -- ./my-agent build ql run --observe --strict --profile agent.yaml -- ./my-agent build
这不是“学习一次就永久安全”。依赖升级、构建脚本修改、包管理器缓存位置变化，都可能令旧策略失效。更稳妥的流程是把 agent.yaml 和任务入口一起纳入代码审查：每次扩宽允许范围，都要能指出是哪一个新依赖、哪条构建步骤或哪项外部服务所需。对生产凭据，不应因为某次学习过程访问过就顺手加入白名单。
MCP：同时限制进程与工具调用
MCP 服务是第三方进程，通常由客户端以当前用户权限启动。因此“Agent 被隔离”不自动等于“它启动的 MCP 服务也被隔离”。QuantmLayer 的 mcp wrap 可改写 MCP 配置，让 stdio 服务进入隔离单元；mcp gateway 则在 JSON-RPC 流上检查工具调用，并可对状态变更工具设置显式门槛。
ql mcp wrap .mcp.json --in-place --gateway --gate delete_file ql mcp gateway --gate delete_file --audit gw.jsonl --
这里的 delete_file 只是一个由团队定义的门槛示例，不是自动识别所有危险工具的万能开关。上线前应核对服务公开的工具 schema、实际副作用和需要授权的操作；网络型 MCP 还需要根据真实域名配置访问权限，不能靠猜测端点补齐策略。
需要正视的部署边界
内核级隔离并不意味着零配置。README 提到，在部分 Ubuntu 版本或特定 HWE 内核上，AppArmor 会限制非特权程序在用户命名空间中的能力。如果隔离墙无法应用，正确行为应是停止任务并排查，而不是退回成未隔离运行。团队应把 ql doctor 的结果纳入机器准入检查，并为需要的 rootless AppArmor 配置或受控的特权执行方式建立明确流程。
更严格的内容寻址执行控制依赖 BPF-LSM 和 IMA，并需要 root 与满足条件的 Linux 内核；它不是每台开发机默认都有的能力。资源限制也可能需要 root 或 cgroup delegation。换言之，策略文件写得再漂亮，也不能替代对实际主机能力的验收。
项目 README 还提供可复现的攻击基准与测试说明，列出文件、资源、进程、网络及执行面等多类场景。阅读这些结果时应把它们当成特定环境与配置下的工程证据，而不是跨所有主机的安全保证；先在自己的内核、Agent、MCP 和仓库条件下复跑关键验证，才知道实际保护到了哪里。
把策略变更当作一次权限变更
策略维护最容易失败的地方，不是命令写错，而是把“临时让它跑通”误当成长期授权。建议为每个策略变更保留最小的变更说明：哪个任务需要新增访问、访问的是哪个目录或域名、它在什么验收命令下被观察到、移除后会影响什么。这样，agent.yaml 不只是机器生成的副产品，而是能够进入代码评审的权限清单。
实践中还应把学习与执行拆到不同阶段。学习阶段可以在脱敏副本或无生产凭据的环境中运行；执行阶段只带完成任务必需的目录和凭据。网络白名单也应按服务域名和用途拆分，避免因为某个包管理操作需要联网，就把任意出站访问都交给 Agent。遇到策略拒绝时，优先确认任务是否真的需要该能力，再决定扩宽规则；不要为了消除一次失败而关闭整层隔离。
对团队协作而言，这种记录还有额外价值：新成员可以从策略和审计结果理解自动化任务的权限边界，安全审查也能聚焦在少量可读配置上，而不必从一段漫长的 Agent 对话里猜测它曾经做过什么。
适合什么场景
如果 Agent 只做单文件修改、没有外部工具访问，先用普通代码审查与最小权限账号可能更简单。QuantmLayer 更适合这些情况：Agent 需要在真实本地仓库运行；团队要接入多个 MCP 服务；任务会拉取依赖或调用工具；以及你希望把“允许的动作集合”作为可审阅配置保存下来。
一个务实的落地顺序是：从低风险仓库跑 ql doctor；用一次固定构建生成策略草案；以 observe/strict 发现额外访问；再把 MCP 服务逐个接入并给有副作用的工具加门槛。这样得到的不是“不会被注入”的承诺，而是一条更可靠的工程原则：当 Agent 出错或被诱导时，它能够造成的后果应被预先缩小到任务所需的最小范围。