AI Agent 数据安全边界：如何在企业权限内工作

先给结论：可上线的 AI agent 必须像一个受控用户：继承用户身份，权限落到对象、记录、字段和动作；先只读再执行，高风险动作要审批可回滚，每步可审计。真正的区别是：它是受控用户，还是影子管理员。

很多企业讨论 AI agent 时，第一反应是问：

它能不能接 CRM、ERP、工单、合同、订单这些真实业务系统？

这个问题问得还不够准。更关键的问题是：

它以谁的身份访问？能看什么？能改什么？出问题时能不能知道它做过什么，并立刻停下来？

如果这些问题没有答案，agent 越聪明，风险越大。它会变成一个披着 AI 外衣的“影子管理员”：能跨系统查数据、能调用工具、能修改记录，但不受任何人的岗位权限约束。

企业级 agent 的目标不是让 AI 获得超级权限，而是让它在清晰边界内帮助用户完成工作。

AI Agent 的安全边界

第一层边界：agent 必须继承用户身份

agent 不应该拥有一个独立的万能账号，更不应该直接拿数据库管理员权限。

它应该代表当前登录用户行动。销售只能看自己负责的客户，agent 也只能看这些客户；客服只能处理自己队列里的工单，agent 也只能在这个队列内查询和建议；工程师不能看合同金额，agent 也不能因为“需要分析”就绕过去。

这条规则看似简单，却决定了整个系统是否可控：

用户离职，agent 的访问能力随之消失；
用户转岗，agent 的可见范围随权限变化；
用户无权访问的记录、字段和动作，agent 也无权访问；
审计日志可以把每次 agent 行为关联回真实用户。

不要把这件事交给提示词。提示词可以提醒模型“不要越权”，但真正可靠的边界必须由运行时权限系统强制执行。

第二层边界：权限要落到对象、记录、字段和动作

企业权限不是一句“允许访问 CRM”就够了。

一个安全的 agent 需要同时尊重四类边界：

对象级权限：用户是否能访问客户、订单、工单、合同这些对象。

记录级权限：用户能访问哪些具体记录，例如自己的客户、所在区域的订单、某个团队的工单。

字段级权限：用户能不能看合同金额、成本、身份证号、内部备注等敏感字段。

动作级权限：用户能不能创建任务、修改阶段、关闭工单、发送报价、调整折扣、变更权限。

很多 agent 项目失败，不是模型不够好，而是权限模型太粗。系统只知道“这个 agent 可以查客户”，却不知道它不能查所有客户，不能读取敏感字段，不能执行高风险动作。

ObjectOS 的思路是把业务对象、字段、动作和权限都变成声明式元数据。agent 不是直接碰表，也不是直接调任意 API，而是通过受控工具在这些元数据定义的边界内工作。

第三层边界：先只读，再建议，再执行

让 agent 一开始就自动修改业务数据，通常不是好主意。

更稳妥的上线节奏是三步：

只读阶段：agent 可以查询和总结数据。例如“找出超过 SLA 的工单”“总结这个客户最近 90 天的问题”“列出可能延期的订单”。它不写入，不触发外部动作。

建议阶段：agent 可以生成待确认的操作建议。例如“建议把这 12 个工单升级为高优先级”“建议给这些客户创建跟进任务”。人确认后再落库。

受控执行阶段：对低风险、边界明确、可回滚的动作，agent 可以自动执行。例如创建内部任务、更新普通状态、补全非敏感字段。高风险动作仍然需要审批。

这个分层很重要。它让企业可以逐步扩大 agent 的权限，而不是在“完全不用”和“全自动执行”之间二选一。

第四层边界：高风险动作必须审批和可回滚

有些动作天然需要更高门槛：

删除记录；
批量修改客户、订单、合同、库存或财务数据；
修改金额、折扣、账期、信用额度；
对外发送正式邮件、报价、合同或通知；
修改角色、权限、组织关系；
调用会产生真实成本的外部服务。

这些动作不能只靠模型判断“应该没问题”。系统需要在执行前展示影响范围、原因和差异，让有权限的人确认。

同时，系统要记录执行前后的状态。出错时至少能撤销、补偿或人工恢复。如果 agent 一次准备改 500 条记录、命中敏感客户、超过金额上限，系统应该自动刹车并升级给人。

审批不是为了拖慢 AI，而是为了让 AI 能进入生产环境。

第五层边界：每一次读取和操作都要可审计

很多传统系统只记录人做了什么，没有准备好记录 agent 做了什么。

但 agent 的行为链更复杂：它可能先读取数据，再做分析，再生成建议，再调用工具，再等待确认，最后修改记录。出了问题，如果只能看到“某条记录被改了”，远远不够。

审计至少应该回答这些问题：

谁触发了这次 agent 任务；
agent 读取了哪些对象和记录；
哪些字段被隐藏或拒绝访问；
调用了哪些工具和动作；
生成了什么建议；
哪些动作被人确认，哪些被自动执行；
执行前后数据如何变化；
哪些步骤失败、越权或升级审批。

审计不是事后甩锅，而是让团队有能力逐步放宽权限。没有审计，企业只能保守地把 agent 关在业务系统外面。有了审计，IT 和业务团队才能知道哪些场景已经稳定，哪些场景还需要人守着。

一个判断标准：它是受控用户，还是影子管理员？

评估一个企业 agent 架构，可以问 6 个问题：

agent 是否以真实用户身份运行？
它是否继承对象、记录、字段和动作权限？
它是否通过受控工具访问数据，而不是直接读取整库？
它是否支持只读、建议、执行的分级授权？
高风险动作是否需要审批、可回滚、可刹车？
每一次读取、建议和修改是否可审计？

如果答案大多是否定的，这不是企业级 agent，而是一个新的安全盲区。

ObjectOS 的立场

ObjectOS 默认接受一个现实：真正有价值的 AI 一定会进入业务系统。

它需要读客户、订单、工单、合同和审批；它需要理解业务对象之间的关系；它也需要在授权后推动流程。但它不能绕过企业已有的身份、权限、审批和审计。

所以 ObjectOS 把对象、字段、流程、权限和动作都放进统一元数据层，让 agent 通过这层结构工作。AI 能更接近真实业务，同时每一步都有身份、有边界、有记录。

企业不缺会聊天的 AI。企业缺的是能安全使用业务数据、能被授权、能被审计、能随时停下来的 AI。