AI Agent 权限边界：数据和动作如何受运行时约束

先给结论：企业 AI agent 不能当超级用户——它必须继承用户权限、遵守记录范围与字段级安全，高风险动作要确认，每一步都要可审计。权限不能靠模型自觉，必须靠运行时强制。

企业引入 AI agent 时，最危险的不是它答错一个问题，而是它像一个没有边界的超级用户。

它能查客户、看合同、读报销、改状态、发通知、发起审批。能力越强，越需要回答清楚：它到底继承谁的权限？

它能不能看到普通员工看不到的数据？它能不能修改用户本人不能修改的字段？它能不能直接执行原本需要审批的动作？

这些问题如果回答不清楚，AI 就很难进入核心业务系统。

ObjectOS 的基本原则很简单：AI 可以成为业务助手，但不能成为权限体系之外的超级用户。它读数据、调用动作、触发流程，都应该经过同一套对象、权限、确认和审计边界。

企业 Agent 的权限边界

权限不能靠模型自觉

很多 AI 项目会在提示词里写：

你只能访问当前用户有权限的数据。执行危险动作前必须询问用户。不要泄露敏感字段。

这些要求有必要，但它们不是安全边界。

真正的权限必须由平台执行。模型可以被提醒，但不能被当成权限系统；工具可以被描述，但不能直接绕过业务规则；agent 可以发起动作，但不能跳过确认和审计。

如果一个销售没有权限查看其他区域的商机，AI 也不应该通过“汇总分析”看到这些商机。如果一个员工不能查看同事薪酬字段，AI 也不应该在回答里泄露。如果一个审批需要经理确认，AI 不能因为“理解了用户意图”就直接批准。

企业 AI 的底线是：AI 不比当前用户拥有更多业务权力。

agent 应该继承当前用户的上下文

一个安全的 AI 应用，首先要知道“是谁在问”。

用户在界面里向 AI 提问时，平台不应该只把问题发给模型，还应该把当前用户、角色、组织、租户、权限和请求追踪信息带入工具执行上下文。

这样 agent 查数据时，看到的就是当前用户本来能看到的数据；agent 执行动作时，也只能执行当前用户有资格发起的动作。

这看起来像技术细节，实际是产品体验的基础。

因为业务用户不会接受“同一个问题，在页面上查不到，在 AI 里却查得到”。管理者也不会接受“权限系统管住了人，却没有管住 AI”。

记录范围决定 AI 能看哪些数据

对象级权限只能回答“能不能看客户对象”“能不能编辑商机对象”，但企业还需要回答“能看哪些客户”“能改哪些商机”。

例如：

销售只能看自己负责的客户；
区域经理可以看本区域客户；
财务只能看与预算相关的项目；
客服主管可以看团队工单，但普通客服只能看分配给自己的工单；
外部供应商只能看自己的订单和资质。

这些就是记录级边界。AI 查询“所有高风险客户”时，“所有”必须自动限定在当前用户的可见范围内。

如果 agent 的数据工具直接查数据库，再把结果交给模型过滤，就已经太晚了。正确做法是：平台在查询层就注入记录范围，AI 根本拿不到不该看的记录。

字段级安全防止敏感信息泄露

即使用户能看到一条记录，也不代表能看到所有字段。

客户记录里可能有内部风险评分；商机里可能有底价和利润率；合同里可能有敏感条款；员工服务请求里可能有个人隐私；采购记录里可能有供应商评估细节。

AI 很擅长总结，也正因为擅长总结，它更容易把多个字段里的敏感信息合并成一句看似自然的回答。

因此字段级安全非常重要。用户无权读取的字段，应该在进入 AI 上下文之前就被屏蔽；用户无权修改的字段，AI 也不能通过动作参数悄悄改掉。

这不是“让模型少说一点”，而是“让模型根本拿不到”。

动作权限比数据权限更敏感

读数据已经有风险，做动作风险更高。

企业 agent 可能会执行这些动作：

创建任务；
更新客户阶段；
关闭工单；
发起审批；
发送邮件；
标记合同风险；
批准或退回报销；
删除重复记录。

这些动作不应该因为 AI 发起就自动放行。它们应该和人点击按钮一样，经过动作权限、参数校验、风险判断、必要确认和审计记录。

ObjectOS 里，业务动作由 Action 元数据描述。一个动作是否开放给 AI，需要明确配置；高风险动作还应该进入确认或审批。这让企业可以把 AI 能做什么、必须确认什么、不能做什么分清楚。

人工确认是治理，不是效率障碍

很多团队担心确认会降低 AI 效率。实际上，确认是让 AI 进入真实业务的前提。

一个合理的落地路径通常是：

先让 AI 只读数据、生成建议；
再让 AI 创建草稿、任务和内部备注；
对状态变更、审批发起、外部通知加入用户确认；
对高风险动作使用审批；
最后才把低风险、高频、可回滚的动作自动化。

这样团队既能获得效率，也不会把关键责任直接交给模型。

更重要的是，确认应该发生在平台运行时，而不是只依赖模型说“我会先问你”。当 AI 发起动作时，平台生成待确认项；用户确认后，平台执行动作并记录日志。这才是可审计的企业流程。

审计让 AI 行为可解释

当 AI 进入业务系统，审计问题会变得更具体：

AI 看过哪些对象和字段？
它基于哪些数据给出建议？
它发起了哪个动作？
谁确认了这个动作？
动作修改了哪些记录？
流程在哪个节点暂停或继续？
失败后有没有补救？

这些问题不应该靠聊天记录猜。平台需要把 AI 查询、动作、流程、审批和结果放进同一条追踪链里。

只有这样，业务负责人才能复盘效率提升，合规团队才能检查风险，管理员才能发现异常调用。

评估企业 agent 平台时该问什么

如果你在评估 AI agent 是否能进入业务系统，可以直接问这些问题：

agent 查询数据时，是否继承当前用户权限？
记录级权限是否在查询层执行，而不是事后过滤？
敏感字段是否在进入模型前就被屏蔽？
AI 能调用哪些动作，是显式开放还是自动暴露？
危险动作是否有运行时确认和审批？
AI 操作是否和人工操作进入同一套审计？
管理员能否看到 agent 做过什么、为什么做、谁批准？
系统级权限是否只用于内部任务，而不是普通用户对话？

这些问题比“模型回答得是否流畅”更重要。因为企业 AI 的风险，不在于它不会说，而在于它说了不该说的数据，或者做了不该做的动作。

ObjectOS 的差异

ObjectOS 不把 AI agent 当成一个外接聊天插件，而是让它在业务运行时内工作。

它通过对象元数据理解业务数据，通过权限模型限定可见范围，通过字段级安全保护敏感信息，通过 Action 元数据开放可执行动作，通过流程和审批处理人工确认，通过日志保留完整证据。

这样，AI 可以更接近真实工作，但不会站到权限体系之外。

对企业来说，这才是 AI agent 从演示走向生产的关键：不是让 AI 拥有无限能力，而是让 AI 在正确边界内拥有足够能力。