AI 代理出事故时，问题很少出在单个防护组件没做，而是隔离边界和监控判定不在同一层。已经披露的案例呈现同一个形态，安全组件确实告警了，数据还是流出去，因为真正承载数据的通道没被同一个判定拦住。典型例子是某个办公套件里的代理，安全遥测标记了可疑的工具调用序列，代理仍然通过已连接的邮件工具把内容发到外部地址。
隔离失效发生在哪几层
代理的隔离面比普通服务多，它同时持有模型上下文、工具凭据和网络出口。失效位置有三处。文件与命令层，代理能执行 shell 或写文件，同一台机器上却挂着长期有效的凭据。网络层，HTTP 出站被限制，DNS 解析仍然开放，把数据编进子域名就能通过递归查询送出去。工具层，代理连接了邮件、日历、代码仓库这类有发信能力的系统，工具权限没有跟随会话状态收窄。这一层最容易忽略，工具是正常业务功能，看起来不像出口。
监控为什么拦不住已经发生的事
监控的典型问题是看得到行为、看不到数据。日志记下了工具调用名称和参数摘要，却没记录参数里是否夹带了从别处读取的内容。安全组件标记序列可疑，策略层只把它当告警而非阻断条件，告警进队列，数据继续外流。要真正拦住，需要在工具出口做一次统一授权判断，并让这个判断有能力直接拒绝。
怎么按层收紧代理权限
收紧的顺序从权限最小化开始，越靠近数据出口的控制越优先。
- 给代理分配专用短时凭据，限定作用范围和有效期，不共用运维账号的长期密钥。
- 文件系统改成只读加临时目录，需要写出的结果由外部流程取走。
- 出站默认拒绝，白名单同时覆盖 HTTP 与 DNS，禁止访问元数据地址和内网管理面。
- 工具调用走统一网关，按会话状态判断该次调用是否允许，有发信能力的工具单独加强。
- 记忆写入和长期存储纳入同一套授权，避免一次注入被固化下来反复生效。
监控要采集什么才算有效
有效的监控要把行为和数据流关联起来。可采集的项包括代理进程发起的每一次出站连接目标、工具调用的完整参数与返回、从读取内容到外发之间的调用链、记忆或长期存储的写入记录。判定规则要能表达跨步骤条件，比如某个会话在读取外部文档之后短时间内调用了发信工具，这类组合应该直接命中阻断策略。只按单点阈值报警的系统，挡不住把动作拆成多步的攻击。
隔离强度的选择标准
隔离强度要和代理的实际能力匹配，过度限制会让功能不可用。
- 只做内部检索问答、不接触外部内容的代理，重点放在输入检查与输出过滤。
- 会读取用户文件和网页的代理，必须禁止输出触发出站请求，工具调用纳入独立授权。
- 能自主执行命令、自行安装依赖的代理，需要完整沙箱、只读挂载和出口白名单。
- 代表用户操作邮件、仓库、工单的代理，有发信能力的工具要单独隔离，凭据按最小范围签发。
常见问题
问，做了容器隔离是不是就够了。容器限制的是进程与文件系统，挡不住代理通过工具或 DNS 外发数据。
问，告警很多会不会掩盖真实问题。告警量与有效性不是一回事，关键是阻断策略能不能直接生效，只告警不阻断等于没有最后一道闸。
问，如何验证隔离是否生效。可以在受控环境里让代理尝试访问外部地址、写入长期记忆、调用发信工具，观察每一步是被拒绝还是记录后放行。