AI Agent开始代表员工调用工具时，企业内网的风险边界就变了。答错一句话只是表层问题；拿着OAuth令牌读取文件、修改记录，或访问ERP、CRM和财务系统，结果会直接落到业务流程里。
实在智能在2026年6月21日发布的文章中，把能够自主规划、调用工具并执行复杂流程的AI Agent称为“数字员工”。这个称呼很形象，但企业也要看到另一面：它既然能干活，就必须像其他执行主体一样接受授权、隔离和审计。
Tianpan在2026年4月20日的分析提到，一些团队会直接接入OAuth令牌，让Agent获得与触发用户相同的权限范围。被操纵的提示词可能诱导Agent窃取文件，受损的工作流也可能在关联服务中悄悄提升权限。此时，账号有权、Token有效、接口调用成功，业务结果却已经失控。相关风险资料把这类问题概括为“合法动作的非法后果”。
RBAC还能用，继承方式得改
RBAC适合管理职能相对稳定的人类员工。财务、销售、客服各有角色，角色对应一组长期权限。Agent的工作状态更容易变化：同一次对话里，它可能先做只读检索，随后转去执行具备写入能力的代码或业务操作。
如果Agent完整继承用户的Scopes，它能做什么，取决于用户拥有的最大权限，而非当前任务真正需要的最小权限。原来的“用户 → 角色 → 权限”也会拉长为“用户 → Agent → 多个工具或插件 → 核心业务系统”。只要其中一个工具授权过宽，攻击面就会被继续放大。
RBAC可以继续承担部门和岗位的基础授权，但Agent还需要几道额外限制：
- 为Agent建立独立身份，不把员工令牌直接透传给所有工具；
- 按任务授予权限，只开放完成当前操作所需的接口和动作；
- 需要更高权限时采用即时授权，任务完成后收回；
- 修改薪资、变更权限、处理资金等高风险操作，保留人工确认（Human-in-the-Loop）；
- 每次工具调用都留下可追溯的审计记录。
调整后的权限链更接近：
用户身份 → Agent独立身份 → 本次任务授权 → 工具动作 → 业务系统
网关看调用，沙箱管边界
腾讯云介绍的企业级AI Agent安全方案采用了安全运行时沙箱和AI Agent安全网关，并在Agent访问入口部署安全Hook，对模型输入、输出进行检测。
放进企业内网后，一条较完整的调用链可以写成：
用户请求 → 身份校验 → 安全网关 → Agent规划 → 运行时沙箱 → ERP / CRM等业务系统
安全网关首先要确认Token是否有效，还要判断本次任务能否调用这个工具、请求参数是否越界、操作意图是否与用户授权一致。遇到权限变更等敏感动作，网关应暂停调用，转交预设规则或人工审批。Agent返回内容也要经过检查，避免敏感数据未经处理就进入对话窗口。
运行时沙箱负责限制Agent执行代码和调用工具时能够接触的范围，包括文件系统、网络端口和凭证。Agent不应直接运行在企业内网宿主机上。即使遭遇提示词注入，沙箱也能收窄其可访问资源，降低横向触达其他内网服务的风险。
业务系统原有的权限校验仍然要保留。安全网关和沙箱是新增关口，不能成为绕过ERP、CRM自身鉴权逻辑的通道。
给Agent单独发一张“工牌”
Authing关于AI Agent身份与零信任IDaaS的讨论，给出了另一个关键方向：把Agent视为独立身份，而非员工账号的附属进程。
身份解耦之后，系统可以分别判断“谁发起了任务”“哪个Agent正在执行”“当前任务允许调用什么”。Agent默认只持有最小权限。确有需要时，它可以向安全网关提交权限申请，再由预设规则校验；涉及高风险业务的操作，仍由人确认。
这种设计也让审计记录更清楚。发生异常时，企业能够区分用户指令、Agent规划和工具执行分别做了什么，而不是只在日志里看到某个员工账号完成了一串API调用。
数据出口也要设卡
私有化部署能够减少数据发送到外部模型或服务的路径，但它无法自动解决内网越权。如果Agent在企业内部读取了不该读取的资料，再把内容返回给无权查看的人，数据仍然已经泄漏。
因此，DLP数据防泄漏层应放在Agent输出给用户之前。企业可以按照已有的数据分类规则，使用正则匹配和轻量级NER模型识别身份证号、银行卡号、客户身份信息等敏感字段，再执行掩码、截断或阻止输出。
出口过滤也不能替代前面的权限控制。Agent无权读取的数据，应在工具调用阶段就被拦住；已经获得授权的数据，输出时还要再次核对接收者和使用场景。两道关口处理的是不同问题。
全链路审计则要覆盖用户身份、Agent身份、任务、调用工具、请求参数、授权结果和输出处理结果。这样遇到“合法动作的非法后果”时，企业才能还原路径，而不是只知道数据曾被某个账号访问。
私有化部署也要带着安全链路压测
对强调数据不出域的金融和政企场景，私有化部署通常是重要前提。模型、知识库和业务数据留在受控环境中，权限策略、审计日志和合规模型微调也更容易纳入企业现有制度。
代价是安全Hook、权限判断、DLP扫描和日志写入都会增加处理环节。团队在选择vLLM或TensorRT-LLM时，不能只看关闭安全组件后的裸模型吞吐。测试环境应打开完整安全链路，再观察端到端时延、并发稳定性和异常回退。推理引擎的选择，最终要回到企业自己的负载和审计逻辑。
上线前，把这些问题问一遍
- Agent是否拥有独立身份，还是直接继承员工的OAuth令牌？
- 当前任务允许调用哪些工具？读取和写入权限是否分开？
- 权限提升由谁批准，任务结束后能否及时收回？
- 修改资金、薪资和权限等操作，是否强制人工确认？
- Agent执行代码时，文件系统和网络访问是否处于沙箱限制内？
- 输入、工具调用和输出是否全部经过安全网关与DLP？
- 每一笔API调用能否追溯到用户、Agent、任务和授权结果？
企业内网里的Agent应被当作有执行能力的独立主体。它可以规划任务，但不能自行决定权限边界；它可以调用工具，但每次调用都要受到身份、策略、沙箱和审计约束。把这些规则写进系统，比反复提醒模型“不要越权”可靠得多。
