传统工业平台的安全模型以人为用户主体。智能体接口引入了新的调用方：持有用户签发令牌的程序客户端，可查询设备、读写点位。2026 年 5 月，网信办《智能体规范应用与创新发展实施意见》发布，"规范有序"与"创新驱动"并重成为智能体落地的治理基调------对工业软件来说，该文件对工业软件的要求可以概括为：平台必须能说明智能体每次调用的授权来源、操作内容与追责路径。
本文分析 DC3 的四层纵深防御，自外向内依次为：
第一层：传输------TLS 全链路
网关对外支持 TLS/SSL 加密通信，内部消息总线与存储连接按部署配置加密。该层保障传输 confidentiality，是基础要求。
第二层：身份------JWT + RBAC，一套身份三个入口
Web 端用户、CLI、智能体客户端，签发走同一个 OAuth 令牌体系（JWT + Spring Security）。角色权限（RBAC）决定"谁能做什么"，MCP 接口的 scope 从 RBAC 投影而来------不为智能体建立独立特权模型。高危操作在令牌层做风险分级：短有效期加 step-up 换取，避免令牌长期有效带来的风险。
第三层：隔离------租户边界刻进数据层
多租户不是"查询时加个 where 条件"那么简单。DC3 把租户隔离做成全链路约束：
- 数据库：每张业务表带租户字段，查询强制带租户范围；
- 缓存：租户数据的缓存键必须包含租户上下文，防止跨租户读到脏数据；
- API：请求进入即解析租户身份，服务间 gRPC 调用携带租户信息；
- 跨服务校验：跨服务取数先验证归属权，再返回或变更。
工程约束为：不提供绕过租户范围的路径------除非数据模型显式定义为全局记录。
第四层：审计------事件全量留痕
命令下发、事件上报、用户操作全量入库：谁在什么时候对哪个设备做了什么。智能体的工具调用同样落在审计链路里------这正是智能体治理要求"可追溯"的工程落地形态。出了问题，账本能翻到具体的一次调用、具体的令牌、具体的授权来源。
四层怎么协同：一个例子
智能体客户端拿着令牌调用 /mcp 查询设备 → 网关验签（第二层）→ scope 检查确认"只读" → 请求携带租户上下文进入数据中心（第三层）→ 查询结果与调用记录入审计（第四层）。任何一层不满足即终止调用。
实事求是的边界
- 安全机制持续演进，渗透测试与漏洞响应流程以仓库 SECURITY.md 为准；
- 审计可追溯不等于零风险------纵深防御的目标是提高攻击成本并保留追责证据；
- 智能体的高危操作（命令下发）始终需要人工确认，辅助分析与自主处置的边界由平台代码约束，不依赖提示词。
仓库 ：GitHub
pnoker/iot-dc3· Giteepnoker/iot-dc3（GVP）文档：docs.dc3.site · 仓库 SECURITY.md · book.dc3.site · demo.dc3.site