前面讨论 IT 部门的顾虑时，提到了权限不可控的问题：AI 可能访问不该访问的数据，调用不该调用的接口。这个问题的工程解法，是这篇的主题。
传统方案的做法和代价
在没有本体层的方案里，让 AI 调用业务系统的常见做法是为 AI 单独开发一套机机接口（machine-to-machine API）。
逻辑是清晰的，人机接口是为人类用户设计的，带有会话状态、Cookie、前端验证逻辑，AI 直接调用人机接口会遇到各种障碍；机机接口专门为程序调用设计，输入输出格式规范，鉴权方式简单，AI 可以直接使用。
这个做法在小系统上是可行的。但一个中型的业务系统，人机接口可能有三四百个。如果每个接口都要改造出一个对应的机机版本，开发工作量是可观的，而且维护成本会持续存在，每次业务系统的接口发生变化，机机接口也要跟着更新，两套接口的同步是一个永续的负担。更深层的问题是权限。很多粗糙的机机接口实现会使用一个固定的服务账号鉴权，这个服务账号要么权限太大（能访问所有数据），要么权限太小（某些接口调用不了），很难精确对应"当前操作用户应有的权限"。比如，张三发起了一个查询请求，AI 用服务账号去调，系统看到的是服务账号而不是张三，而是“xxx AI 智能体”，张三没有权限看的数据，AI 可能也能查到。
这不是 AI 的问题，是接口设计和身份传递方式的问题。设计良好的机机接口可以通过 OAuth On-Behalf-Of、Token Exchange、委托作用域等方式保留用户上下文，但如果只是给 AI 一个固定服务账号，"是谁在操作"这个信息还是会被抹掉，除非在开发阶段针对每个环节做大量特殊处理。
"当前用户上下文"是什么
业务系统里的大多数操作，都依赖"当前是谁在操作"这个信息。
一个仓库管理员查库存，系统返回他所在仓库的数据。一个采购员创建采购订单，系统自动填入他的工号作为经办人。一个部门经理审批出库单，系统检查这张单据是否在他的审批权限范围内。这些行为的背后，是系统在每次操作时都知道当前用户是谁，并据此决定能看什么数据、能做什么操作、操作结果记录在谁名下。
这套机制在人机交互场景里运转得很好，因为用户登录之后，系统一直持有这个用户的会话信息，每次操作都隐含地附带了"是谁在操作"的上下文。AI 调用系统时，这个上下文断掉了。AI 不是一个登录了系统的用户，它是一个外部程序，发起的调用没有用户会话附着，系统不知道这个调用代表的是哪个用户。用服务账号鉴权是一种妥协，但它解决不了"当前用户是谁"这个根本问题。
本体层的设计目标，就是在不改造业务系统接口的前提下，完整地重建这个"当前用户上下文"。
本体层怎么做到的
在我们的解决方案中，本体层通过活字格低代码平台配套的 CLI 调用业务系统，这个 CLI 在调用时保留的是当前用户上下文，不是一个脱离用户的高权限服务账号。
具体机制可以有几种实现。在活字格生态里，常见方式是工作台和业务系统接入同一套身份体系，用户登录工作台后，本体层通过当前用户代理、短期会话令牌，或者"受限服务身份 + 用户映射"的方式发起调用。这里的关键不是保存用户账号密码，而是让每一次调用都能带上明确的用户主体、会话边界和授权范围。相关令牌需要短期有效、加密保存、绑定会话，并支持过期、刷新和撤销。
之后，每次 Agent 通过本体层调用业务系统，本体层都以这个用户的授权上下文发起请求。从业务系统的权限判断来看，这次请求代表的是一个已认证用户，而不是一个拥有全局权限的 AI 服务账号。系统按这个用户的权限处理请求：他能看的数据才返回，他能做的操作才执行。
在活字格这类可以复用既有人机接口和鉴权机制的系统里，这通常不需要为 AI 另行改造一套机机接口，因为业务系统接收到的请求格式和人机操作保持一致。但这不意味着审计上要把 AI 代理隐藏起来。更好的做法是：权限判断沿用用户身份，审计链路同时记录用户主体和 AI 代理主体。
这意味着什么
这个设计的工程价值，要放在对比里才能看清楚。
- 粗糙的机机接口方案：开发三四百个机机接口，维护两套接口，用固定服务账号鉴权，权限是粗粒度的，操作日志记录的是服务账号而不是真实用户。
- 本体层方案：尽量复用既有人机接口，减少单独机机接口改造；调用时带上当前用户上下文，权限和人机操作对齐；审计时同时记录真实用户和 AI 代理。
对 IT 部门来说，后者在安全模型上比固定服务账号方案更容易治理，不是更宽松。AI 通过本体层调用系统，首先受到当前用户权限约束；在此之外，本体层还加了白名单约束，只有在白名单里的接口才能被 AI 调用。即便这个用户在系统里有权限调用某个接口，如果这个接口不在白名单里，AI 也调不了。这个特性是第四篇里讨论的 IT 部门顾虑的直接回应：AI 的权限边界不应该比人类用户更宽，而且可以通过白名单进一步收窄。对于写入、删除、外发、批量操作这类高风险动作，还应该叠加参数约束、操作限额、人工确认和异常中止机制。
审计日志的完整性
这个设计的另一个收益是审计日志的可读性。
粗糙的服务账号方案里，操作日志里的主体是服务账号，比如ai_service_account。审计人员看到一条"ai_service_account 在 14:23 查询了采购订单表"，不知道这次查询是哪个用户发起的，是什么任务触发的，出了问题也无法追溯到具体的人。
本体层方案里，审计日志应该同时保留两个主体：subject=zhang.san，表示权限判断和业务责任归属于张三；actor=ai_workbench或actor=agent，表示这次操作是由某个数字员工代理执行。审计人员看到这条记录时，既知道它代表哪个用户的权限上下文，也知道它不是张三手工点击产生的，而是一次 AI 代理调用。
两层日志合在一起，构成了一个完整的审计链路：用户说了什么、AI 做了什么判断、实际调用了什么接口、这次调用代表哪个用户、由哪个 Agent 执行、系统返回了什么、最终呈现给用户的是什么。这条链路的完整性，是企业 IT 治理的基础要求之一。
一个需要注意的边界
这个方案有一个前提：用户在工作台登录时，工作台和业务系统之间要能建立可靠的身份映射。如果业务系统用的是独立的账号系统，和工作台的登录体系没有打通，当前用户代理或委托授权就需要额外的适配工作。
在活字格生态里，这个前提通常更容易满足。活字格自带用户管理，或者可以对接企业的统一身份认证（LDAP、SSO），工作台和业务系统共享同一套用户体系，当前用户上下文就比较容易传递。如果企业的系统存在多套身份认证体系，需要在部署阶段评估统一认证的改造成本，这不是本体层设计的缺陷，而是企业 IT 基础设施的历史问题，独立于 AI 工作台的引入而存在。
从"能不能用"到"该不该信任"
IT 部门对 AI 系统的顾虑，通常分两个层次。第一层是"能不能用"，也就是 AI 调用系统在技术上行不行得通。第二层是"该不该信任"，也就是 AI 的行为是否在可控范围内，出了问题是否有迹可查。
粗糙的机机接口方案解决了第一层，但在第二层留下了空白。服务账号权限宽泛，日志不可追溯，IT 部门没有办法回答"AI 到底做了什么"这个问题。设计良好的委托授权接口也可以解决这些问题，但需要额外建设身份传递、作用域控制和审计关联机制。
本体层方案的价值，是把这些治理能力集中到一个控制面里。调用技术上可行，权限跟随真实用户，日志能同时关联用户和 Agent，白名单控制额外的操作边界。这四个特性合在一起，才构成了一个 IT 部门可以评估和放行的安全模型。
第四篇说 IT 部门和业务部门的矛盾根源是"企业对 AI 行为缺乏治理能力"，本体层是这个问题在工程上的具体回答。
