Agent平台的安全边界-代码执行网络出口与数据外发

摘要

智能体安全不只是提示词攻击，更多风险来自它能做什么：执行代码、访问网络、把数据带出去。本文把风险归为三类边界，分别给出威胁模型与控制手段，并讨论审计设计。2026 奇点智能技术大会（11 月 20-21 日 · 北京万达文华酒店）设有 Agent 安全与 AI Infra 相关议题，会从系统层讨论这类问题。

一、三类边界

三类风险常被合称"Agent 安全"，但控制手段完全不同。混在一起讨论会导致每一项都做得不彻底。

二、代码执行的隔离强度

隔离强度递增：进程 → 容器 → 微虚拟机 → 物理隔离
启动开销递增：毫秒 → 百毫秒 → 秒级 → 分钟级

选择依据是被执行代码的可信度：自己写的代码用进程，模型生成的代码至少用容器，涉及敏感数据的用微虚拟机。用进程隔离运行模型生成的代码，是当前最常见的错误配置。

除了隔离强度，还需要三类上限：CPU 与内存配额、执行时长上限、以及文件系统可写范围。

三、网络出口白名单

内网环境下的默认策略应是全部禁止、按需放行。放行需要记录三要素：目标、用途、有效期。

出口记录示例
目标：api.example.com:443
用途：订单查询
有效期：2026-11-01 至 2026-12-31
责任方：订单中台

白名单需要定期复核，长期未使用的条目应回收。允许任意出站访问的环境，等于把内网暴露在模型的判断之下。

四、数据外发的控制

数据外发有两条路径：进入模型上下文，以及写入日志与记忆。

控制方式是分级：公开数据可直接使用；内部数据需脱敏；敏感数据默认不进上下文，需要时以受控引用方式提供。日志同样要分级，避免为了排查方便而把敏感内容长期留存。

五、审计与追溯

审计需要能回答：谁触发了执行、执行了什么、访问了哪些目标、带出了哪些数据。四项缺一不可。

audit = {
    "principal": actor_id,          # 谁
    "action": "code_exec",          # 做什么
    "targets": ["api.example.com"], # 去哪
    "data_classes": ["internal"],   # 涉及哪级数据
    "trace_id": trace_id,           # 关联链路
}

审计记录应写入独立的、Agent 无法修改的存储。让 Agent 有权限改写自己的审计，等于没有审计。

六、资源耗尽也是安全问题

代码执行的风险不只是越权，还包括把宿主机资源吃光。一个死循环、一段大内存分配、或者一次递归过深，都可能让同宿主的其他任务受影响。

因此资源上限不是性能优化项，而是安全项。CPU、内存、磁盘、进程数与文件句柄都需要设上限，并确保超限时是终止而不是降级。

七、依赖与工具链的信任

智能体常会调用外部包与命令行工具。这些依赖本身可能成为攻击面：版本被篡改、包名被仿冒、或是工具存在已知漏洞。

可行做法是固定依赖版本、使用内部镜像源、并只放行经过审核的工具。运行时允许任意安装依赖，是最容易被忽视的高危配置。

八、提示注入与边界控制的关系

提示注入能让模型产生越界意图，但能否造成实际影响取决于边界是否严密。边界严密时，注入只能影响回答内容，无法触及外部系统。

这解释了为什么平台层应把重点放在边界而不是试图完全过滤注入——过滤永远可能被绕过，而边界是确定的。

九、安全基线的检查清单

建议固化为一份可自动检查的清单：隔离方式是否达到要求、资源上限是否设置、网络出口是否为白名单、敏感数据是否分级、审计是否写入独立存储。

清单化之后，安全基线可以随每次部署自动校验，而不是依赖上线前的人工评审。

十、衔接大会专题

11 月 20-21 日，北京万达文华酒店，2026 奇点智能技术大会设有 Agent 安全相关议题，强调从基础设施而非模型层面设防；C++ 及系统软件技术大会则从沙箱、内存隔离与系统调用过滤角度给出实现方法。

带着"我们的智能体网络出口是全开还是白名单"这个问题去参会，会立刻知道安全基线处在什么位置。

十一、多租户下的边界

多租户平台上，边界还包含租户之间：一个租户的执行不能影响其他租户的数据与资源。

需要三层隔离：执行隔离（不同租户不共享执行环境）、数据隔离（存储与缓存按租户分区）、以及配额隔离（单租户超限不影响他人）。三层中最容易漏掉的是缓存隔离，共享缓存往往成为跨租户信息泄漏的通道。

十二、事故响应

安全事件需要预设响应流程：隔离受影响实例、保留现场、定位开口、修复后恢复。

其中"保留现场"常被忽略——工程师的第一反应是重启恢复服务，但这会销毁判定所需的状态。流程中必须明确先取证再恢复。

十三、供应链与依赖审计

智能体的依赖链是隐形的攻击面。一个被篡改的包、一个仿冒的命令行工具，都可能在执行环节造成越权。

供应链审计要固定版本、使用内部镜像、并定期扫描已知漏洞。运行时允许任意拉取依赖的环境，等于把入口交给外部。审计记录应包含依赖清单，便于事后追溯。

十四、最小权限的落地

最小权限不是口号，而是逐项收敛。智能体能读哪些数据、能调哪些工具、能去哪些网络，都应从默认全禁开始逐步放开。

落地的难点在于业务方总希望一次性全开。平台需要用"先开再评估"替代"先禁再申请"，把默认态设为安全，开口变成需要理由的例外。

十五、安全与效率的平衡

安全控制必然带来摩擦，摩擦过大会被业务绕开。平衡点是把控制放在高影响环节，低影响环节尽量透明。

例如网络出口全禁会严重影响可用性，更务实的做法是高频可信目标自动放行、低频目标走审批。控制强度应与风险等级匹配，而不是一刀切。

十六、事件复盘模板

每次安全事件后应产出一份复盘：发生了什么、开口在哪里、为什么没拦住、修复了什么、如何预防。

复盘模板要可复用，避免每次从零写。模板化能保证关键问题不被遗漏，也让不同事件之间可以横向比较，识别系统性弱点。复盘的价值不在追责，而在防止复发。

十七、沙箱逃逸的攻防视角

隔离不是绝对安全的，攻击者会尝试逃逸到宿主机。评估隔离强度时要假设对方有意愿突破，而不是假设对方守规矩。

防御思路是纵深：即使一层被突破，还有下一层。微虚拟机之上再叠加资源上限与网络约束，单一薄弱点不会直接造成全局失陷。定期做红蓝对抗能暴露真实盲区。

十八、安全基线的持续验证

安全基线写出来不等于生效，需要持续验证。每次部署后自动跑一遍检查清单，比年度审计有效得多。

验证要能失败并阻断发布。如果检查项不达标只告警不阻止，基线会慢慢被绕过。把关键项设为硬门禁，其余项做趋势监控，是更可行的组合。

补充问答

问：沙箱越强是不是越好？

答： 不是，隔离强度与启动开销成正比。全用最强隔离会让高频短任务变得不可用。合理做法是按代码来源分级，而不是全局使用同一等级。

问：内网访问完全禁止行不行？

答： 多数场景不可行，智能体常需要访问内部系统。可行的是默认禁止加按需放行，并要求每条放行都有记录与有效期，形成可审计的开口。

问：怎么检测数据外发？

答： 在网络出口做内容检测与流量分析，结合数据分级标记。对异常外发流量设置告警，并在超过阈值时自动阻断，而不是只记录。

问：模型自身的安全对齐够不够？

答： 不够。对齐降低的是模型产生危险意图的概率，不能阻止一个被诱导的模型执行越界操作。系统边界是最后一道也是唯一确定的一道防线。

问：安全审计会不会记录过多数据？

答： 会，需要权衡。建议在审计中记录数据分级与目标，而不是记录完整内容；需要内容时通过受控引用按需调取，并留下调取记录。

问：小团队怎么做安全基线？

答： 从网络出口白名单与资源上限两项做起。这两项投入最小、收益最直接，能挡住大多数造成实际损害的场景。

问：审计日志本身如何防篡改？

答： 写入 Agent 无权修改的独立存储，并采用只追加的写入模式。同时定期做完整性校验，发现被改写立即告警。审计存储的权限应高于被审计对象。

问：安全与合规有什么关系？

答： 合规是外部要求，安全是内部能力。合规通常规定要做什么，安全决定怎么做得住。满足合规不一定安全，但安全基线扎实的通常能顺利通过合规审查。
问：零信任和 Agent 安全是一回事吗？

答： 不是。零信任是架构理念，Agent 安全是具体落地场景。零信任的「永不信任、始终验证」非常适合作为 Agent 边界设计的指导方针。

问：安全投入怎么衡量回报？

答： 用未发生的事衡量最难，所以改用覆盖度：应管控的开口有多少已被管控、基线检查通过率、以及高危配置归零的速度。覆盖度是可观测的代理指标。

大会信息
2026 奇点智能技术大会 + C++ 及系统软件技术大会
时间：2026 年 11 月 20-21 日
地点：中国·北京万达文华酒店
大会报名：点击报名，领取大会PPT资料

立即报名，锁定 Lukasz Kaiser Keynote 与 70+ 场演讲完整资料！