Agent 与自动化 4.0 · 优秀 2026-09-21 · 文章

Restricting AI Agents When No Human Is Watching

文章讨论无人值守 AI agent 的安全约束:有用的 agent 往往同时具备私有数据访问不可信内容暴露和对外通信三项能力(即 lethal trifecta),有人监督并不能消除风险,无人监督时安全路径必须由系统本身强制执行作者基于在云开发容器中运行后台编码 agent 的生产实践给出三层防御:一是生产凭证不入容器,生产系统经 MCP/API 网关暴露为受控操作,容器只持有身份,被提示注入也拿不到真实密码;二是对网关看不到的行为(读写文件执行 shell调用本地工具)做运行时监控与执行前拦截,hooks 烧进镜像且非特权运行,agent 无法自行关闭;三是单向出口限制会话一旦接触敏感数据源,后续出口即锁定到该工作流预先批准的目的地,agent 仍可继续工作,但数据无法流向任意端点

打开原文回到归档

Restricting AI Agents When No Human Is Watching:无人值守 agent 的三层防御

原文链接: https://a16y.ai/blog/securing-ai-agents-when-no-human-is-watching
作者: Ariel Shiftan(Autonomous / a16y.ai)
发布: 2026-09-21

有用的 agent 往往同时具备三项能力:访问私有数据、接触不可信内容、对外通信。三者并存即 Simon Willison 的 lethal trifecta——prompt injection 或脱轨行为可以把一次坏决策放大成数据外泄或危险操作。作者指出有人在键盘旁并不能消除风险(编码 agent 照样会从外部 bug report 读到恶意指令);而无人值守运行时更难控制:没有人拒绝意外的 tool call、没有人发现 agent 走偏、没有人提前终止会话。作者团队自己在云开发容器里跑后台编码 agent 查生产问题、改代码、开 PR,结论是:没人盯着时,安全路径必须由系统本身强制执行。

三层防御:

1. 给访问权,不给生产凭证。 生产系统经 MCP/API 网关暴露为受控工具,数据库/日志凭证留在网关后面,容器只持有可请求已批准操作的身份。网关可强制只读、检查参数再转发;宽凭证的权限不会自动变成 agent 的权限。容器里根本没有可被注入套出的密码——「让 agent 打印密码一万次也没用」。 2. 盯住网关看不见的部分。 agent 还会读写文件、跑 shell、调本地工具,这些都不经过网关,所以 agent 同时向运行时引擎上报,tool call 在执行前评估。容器镜像里烘焙 hooks 且以非特权运行,agent 无法自己改配置关掉监控。 3. 单向 egress 限制,破坏 trifecta。 一旦 agent 触碰被管理员声明(或自动检测)为敏感的数据源,该会话即被限制:之后只能与该 workflow 预先批准的目的地通信,不能再访问任意网站、新发现的远程工具或未知 endpoint。规则是确定性的——不需要判断 agent 是否已被注入、行为是否恶意;「我们不检测坏会话,我们拆掉它外传数据要走的路」。agent 仍可继续干活:推理生产数据、跑测试、推分支、开 PR。

落地上的关键取舍:规则不是「什么都不许出去」(那会让 agent 没用),而是「不许经过任何未预先批准的目的地出去」;敏感源由管理员声明而非逐个推断,避免把一个问题变成另一个分类问题。

判断:文末三问值得直接搬进无人值守 agent 的设计评审——agent 能否不持有凭证就触达敏感系统?网关之外的动作谁管?碰过敏感数据之后还允许跟谁通信?第三条的「确定性状态切换」比依赖检测准确率的设计更符合无人值守场景的容错要求。

备注:摘要基于 a16y.ai 原文全文抓取(opencli web read)。