第19篇在介绍 Agent 执行层时提到过一个安全判断：能自主编写脚本的 Agent，不能简单地直接运行在内网环境里。

这句话容易被理解成一个绝对规则：Agent 只能放在 DMZ，不能放在 LAN。更准确的说法是，关键不在于服务器放在哪个网段，而在于 Agent 是否被赋予了内网通行权。一旦 Agent 能以自己的身份直连数据库、文件共享、内部 API 和其他服务器，它就不再只是一个 AI 应用，而是一个可以被自然语言驱动的自动化执行进程。

事实上，无论部署在哪里，企业级 Agent 都要满足哪些共同安全要求；如果业务上必须把 Agent 放进 LAN，还要增加哪些额外边界。

先从 Agent 的风险说起

Agent 执行层有一个经常被低估的能力：它可以自主编写和执行脚本。用户让 Agent 合并两份 Excel，Agent 可以自己写 Python 脚本完成；用户让 Agent 分析一批日志文件，Agent 可以写 Shell 脚本批量处理。这个能力让 Agent 能处理没有预先封装好接口的临时性任务，也是它区别于固定 Workflow 的重要优势。但同一个能力，也让 Agent 的风险模型和普通聊天机器人完全不同。一个能执行脚本、读写文件、访问网络、调用工具的 Agent，如果同时拥有内网访问能力，Prompt Injection、插件投毒、错误推理、权限配置错误都可能被放大成真实的系统风险：横向移动、敏感数据外传、越权写入、批量删除，甚至接管宿主机。

这不是杞人忧天。围绕 OpenClaw 的公开安全预警、OpenClaw 官方安全文档，以及 OWASP 对 LLM 应用风险的分类，都指向同一个结论：不能把安全寄托在“模型会判断什么该做、什么不该做”上。提示词只能提供软约束，真正的硬边界必须来自网络隔离、身份认证、工具白名单、沙箱、权限校验、人工审批、日志审计和应急开关。

所以，讨论 Agent 放在哪里，本质上不是讨论哪台机器更方便，而是讨论它被诱导或攻破之后，能碰到什么。

DMZ 部署和 LAN 部署

默认推荐的部署方式，是把 Agent 执行层放在 DMZ 或独立的 Agent Zone。

在这个网络拓扑里，Agent 可以访问被允许的 LLM API、MQTT Broker 和对象存储，但不能主动直连内网业务系统。业务系统仍然部署在 LAN 内部，各自运行 MQTT Client，主动连接受控 Broker，订阅对应 Topic，接收调用指令并返回结果。整个过程由内网业务系统主动发起出站连接，不需要为了 Agent 调用而在内网边界开放入站端口。MQTT Broker 和对象存储的位置可以根据企业条件选择：公网托管、专有 VPC、BYOC、自管 Broker 或企业专有对象存储都可以。关键不是“必须公网”或“必须私有化”，而是所有通信都经过受控通道，所有身份和权限都能被显式管理。

LAN 部署也不是绝对不能做。某些企业出于数据主权、离线运行、专线环境、内部模型调用或合规要求，可能要求 Agent、Broker、对象存储和业务系统都部署在内网。但 LAN 部署不能理解成“把 Agent 放进业务网段，像普通内网服务一样信任它”。在零信任视角下，内网位置本身不构成信任。Agent 即使在 LAN 内，也必须被放进独立隔离区，而不是拿到一张可以访问整个内网的通行证。

两种部署方式的共同安全要求

无论 Agent 部署在 DMZ 还是 LAN，下面这些要求都不是可选增强，而是企业级 AI 工作台的安全基线。

身份不能被简化成一个 AI 服务账号

CUI 界面需要接入企业 SSO、MFA、RBAC 和会话管理。Agent 调用业务系统时，业务语义上应该始终区分 subject=user 和 actor=agent/workbench：真正的数据权限来自当前用户，Agent 只是代为执行，不能变成一个拥有全局权限的高权限服务账号。这一点和第21篇讨论的“当前用户上下文”是一致的。

通信通道要按最小权限开放

Agent、Broker、业务系统客户端之间要使用强认证，条件允许时使用 mTLS 或客户端证书。MQTT Broker 要按应用、用户、会话或租户配置 Topic 级 ACL，Agent 只能发布和订阅自己负责的 Topic，业务系统客户端也只能访问自己的 Topic 范围。网络上能连通，不等于业务上可以随便调用。

业务调用要在运行时再次校验

本体层生成的白名单不能只在配置阶段看一次，而要在每次调用前做运行时检查。业务系统还要校验参数类型、取值范围、对象归属、部门权限、金额上限、批量大小和操作频率。写入、删除、导出、批量处理、权限变更、财务类操作，不适合一开始就全自动放开，应该叠加人工确认或更严格的审批策略。

插件、凭证和文件要当成新的边界

第三方插件要按不可信代码处理，只从可信来源安装，尽量使用签名、版本固定和显式白名单。密钥不能出现在提示词、日志、本体配置、工作目录和 Agent 可读文件里，应使用专门的密钥管理机制、短期凭证和轮换策略。Agent 生成的文件如果进入对象存储，需要加密、短生命周期、用户绑定下载、访问日志、文件类型和大小校验，避免把对象存储变成新的风险入口。

日志和应急开关要从第一天就准备好

Agent 执行日志、工具调用日志、MQTT 连接日志、Topic 发布订阅日志、Broker ACL 拒绝日志、对象存储访问日志、CUI 登录日志和业务系统调用日志，都应该能通过会话 ID、用户、Agent、应用和本体版本关联起来。出现越权 Topic、异常出站、连续调用失败、异常文件上传、短时间大量读取、高风险工具调用时，应触发告警，并能快速禁用某个 Agent、应用、Topic、工具或命令。

LAN 部署的额外安全要求

如果企业最终决定把 Agent 放进 LAN，安全要求不能比 DMZ 少，只能更多。因为 LAN 部署减少了网络绕行和外部依赖，但也缩短了 Agent 到核心业务资产之间的距离。

Agent 不能进入业务系统所在网段

LAN 内也应该划分独立的 Agent Zone，把 Agent、Broker、对象存储、日志组件与业务数据库、ERP、文件服务器、域控、代码仓库等核心资产隔离开。默认策略应该是访问拒绝，只开放明确需要的目标、端口和协议。换句话说，LAN 部署不是把 Agent 放进内网大平层，而是在内网里再划出一个受控隔离区。

网络层不能允许“Agent 身份”访问内网

不要给 Agent 配置域账号、全量 VPN、共享数据库账号、通用堡垒机账号或可以访问多个系统的长期凭证。Agent 即使在 LAN 内，也不应该以自己的身份直连数据库、文件共享或内部管理接口。更稳妥的模式仍然是 Agent 通过受控 Broker、API Gateway 或业务代理发出请求，由业务系统在当前用户上下文和自身权限体系内执行。

内部 API 也要经过受控入口

如果确实存在必须调用的内部 API，不应开放“任意内网 HTTP 访问”。应通过专门的 API Gateway 或业务代理限制方法、路径、参数结构、对象归属、调用频率和返回字段。能读的接口与能写的接口要分开授权，写操作要有人工审批、幂等控制、回滚记录和业务审计。

出站访问要防止数据外传

LAN 部署下尤其要管理 Agent 到外部的出站连接。调用外部 LLM、外部对象存储或外部工具服务时，应通过统一出口代理，做访问白名单、内容脱敏、传输加密、日志审计和流量告警。对高敏数据场景，应优先选择私有化模型、专有网络连接或企业可控的模型服务。

无关的内网发现能力要关闭

Agent 所在区域不应该开放不必要的 mDNS、广播发现、端口扫描、内网爬取和 SSRF 路径。它不需要“知道内网里有什么”，只需要访问被授权的少数受控端点。知道得越多，出事时能造成的影响范围就越大。

运维通道也要单独治理

运维人员管理 Agent 服务器，应通过堡垒机、MFA、短期凭证、命令审计和操作录像完成。禁止从办公网或个人终端直接登录 Agent 服务器，也禁止从 Agent 服务器反向登录其他内网服务器。Agent 区域要纳入补丁管理、漏洞扫描、配置基线和安全巡检，不能因为它是“AI 实验环境”就降低运维要求。

小结

DMZ 部署和 LAN 部署不是“安全”和“不安全”的二选一。DMZ 是默认更容易控制风险半径的部署方式；LAN 部署可以存在，且部署和运维更便利，但必须付出额外的隔离、身份、出站、代理和运维治理成本。无论放在哪里，都不要让 Agent 拿到内网通行权。正确的架构不是让 Agent 像人一样登录内网到处操作，而是让它通过受控通道表达意图，让业务系统在当前用户上下文、白名单、参数校验和审计机制下执行动作。

网络隔离不能替代业务治理，业务治理也不能替代网络隔离。两者叠加，才是企业级 AI 工作台应该具备的安全基线。

---