数字员工（Agent）部署在企业内网，为了完成业务，我们必须授予它权限。但这带来了一个核心矛盾：如何确保数字员工不会利用企业内网便利和赋予的权限，对业务系统进行破坏或越权操作？

要解开这个死结，传统的防火墙已无能为力，我们必须引入一种新的安全模型——零信任（Zero Trust）。

零信任解决什么核心问题

传统安全模型默认“进了大门就是自己人”。防火墙、VPN、机房网段，解决的是位置信任。但在零信任视角下，内网 IP、ServiceAccount、甚至长期 API Key，都不能单独作为通行证。

零信任的核心逻辑是 “永不信任，始终验证”。在工程落地中，它要求同时满足四条铁律：

1. 先认人，再认事：

每次访问必须明确：谁在请求？以什么身份？访问什么资源？

2. 授权跟任务走：

权限按资源、动作、时效发放。任务结束或会话过期，授权即刻终止，而非等待密钥轮转。

3. 秘密不进大脑：

长期口令、Refresh Token、下游密钥，严禁出现在提示词、对话上下文或 Agent 代码中。运行时需按需置换为短效令牌。

4. 先裁决，后执行：

工具调用前，必须由确定性策略进行拦截判断，而非指望模型自觉。事后审计需能还原“用户-Agent-实例-任务”的完整链路。

它解决了边界模型无法防御的三大风险：

• 横向移动： 攻击者进入企业内网后随意游走。

• 身份冒用： 利用同一套账号或密钥互相伪装。

• 权限残留： 人走了、任务停了，但票据和实例权限依然存在。

为什么数字员工必须用零信任

数字员工不是简单的聊天机器人。它有负责人、有工作空间，且能代表员工调用系统。这导致安全对象从单一的登录用户裂变为必须严格拆解的“身份三元组”：

1. 人（Human）：

企业 SSO 中的员工，是权限的上界和责任主体。

2. 数字员工（Agent）：

平台里的业务实体，定义了“谁创建、谁管理、挂了哪些工具”。

3. 运行实例（Workload）：

真正运行的工作负载。

如果这三者混用一套长期密钥，将暗含身份互替的风险： 员工 A 的 Agent 可能冒用员工 B 的身份操作，或者离职员工的 Agent 仍在后台幽灵运行。

此外，数字员工有四个不同于人类的风险特征，决定了它不能只为数字员工办一张工卡了事：

• 无人值守的代办风险：它能在人不在场时执行任务。必须通过委托机制解决：业务主体以登记为准，无许可不授权，严禁匿名代办。

• 上下文记忆风险： 模型会读取提示词和会话历史。密钥一旦进入上下文，就等于进入了不可控的记忆。因此，凭证必须留在代理和保险库中，按需注入短票。

• 权限扩散风险： 子 Agent 或并行任务不能继承比父级更高的权限。下游权限只能保持或收窄，严禁越权派活。

• 生命周期不同步风险： 人离职有流程，但数字员工休眠可能只是关掉进程。真正的下线必须同步禁用实例身份、撤销委托令牌、解绑专属凭证。

如何与业务深度结合

将零信任植入数字员工的全生命周期，我们需要确保以下五点：

1. 创建：先有负责人，再有身份

数字员工绝非无主进程。创建时必须绑定负责人且支持移交。确保出事知道找谁，人员变动时权限能随名单流转。

2. 运行：工作负载证明“我是谁”

数字员工运行在独立工作空间中。启动时，实例需利用工作负载身份（如SPIFFE ID） 自证清白，流量通过双向认证。获取权限时，用对端身份钉死 Agent，杜绝 A 填 B 的冒用行为。

3. 办事：先登记代表谁，再换短票

无论是用户发消息还是定时任务，都是一次委托意图。系统需记录：“哪位用户允许哪个 Agent，在哪个会话窗口，用他的身份执行任务”。没有有效委托，工具层无法换取执行凭证。

4. 用工具：凭证不过脑，策略先于模型

调用企业 MCP 或受保护资源时，走凭证代理和网关。模型只负责建议调哪个工具，策略引擎负责批准是否能调。 高风险操作（如转账、删库）必须强制弹窗，由人类二次确认。

5. 停权：人在则授权，人离则停权

人员离职、主动下线或长期不在线，安全结果必须一致：后续调用被阻断。

• 离职/禁用： 撤销委托，清理离线材料。

• 委托时效： 授权仅代表一次性或有时效的意图，过期自动失效。

结语

零信任对数字员工而言，不是一套更严苛的登录系统，而是一套智能体代人办事的验证契约。

判断数字员工是否安全，只需问四个问题：

1. 这个数字员工归谁负责？

2. 它现在代表谁？

3. 这一次允许它做什么、做多久？

4. 它停掉以后，能否确认权限彻底消失？

只有当这四个问题都有明确的产品落点，数字员工的安全才不仅仅是一句口号，而是坚实的工程实践。