同一批动作契约同时投影为 Web 控制台、内嵌 AI 助手与 MCP 工具，三条通道的身份来源不同； 进入执行环节之后，三者适用同一套判定。本文按顺序拆开执行管道的各道环节， 逐一说明每道环节拦截的对象。
关于 AI 能否操作资产系统，讨论通常以承诺的方式收尾：由厂商声明不会越权，或要求把该声明写入合同条款。 这类表述无法被验证，因为它指向模型的行为，而行为不可被证明。
可被检查的是另一性质的问题：系统中是否存在一条绕过审批即可写入的路径。若存在， 任何关于自觉与约定的说明都只是补充措施；若不存在，越权即成为一段走不通的调用， 而非需要防范的风险。
EAMX 不提供第二个写入口。全部写操作经由统一执行管道完成，权限判定、预演、人工确认、幂等与审计 均在该入口内部执行，与调用方是 Web 控制台、内嵌 AI 助手还是经 MCP 接入的外部 Agent 无关。
系统内不存在「给界面用的接口」与「给 AI 用的接口」之分。动作契约是唯一的操作面， 其中每条动作同时向三条通道开放，通道之间只有身份来源的差别。
| 通道 | 谁在使用 | 身份来源 | 进入管道后 |
|---|---|---|---|
| Web 控制台 | 业务人员 | cookie JWT | 同一套能力定义与判定维度 |
| 内嵌 AI 助手 | 系统内的对话式操作 | 请求级上下文 | 同一套能力定义与判定维度 |
| MCP Server | 外部 Agent | API Key | 同一套能力定义与判定维度 |
以下各节按此次序展开。每节的写法相同：先说明该环节做什么，再说明它拦截的对象是什么。
它防的是调用参数与动作定义不符。语言模型生成的入参在形式上是完整的， 字段类型、必填项与取值范围却未必符合该动作的定义。校验在入口处完成， 不符合模式约定的调用在此终止，业务逻辑与数据库不会先收到无效参数再回滚。
该模式来自动作契约本身，三条通道共用同一份。客户端在参数拼接、转义与字段映射上的错误同样在此暴露， 不因调用方是 Agent 而获得例外。
依据：动作契约的入参模式定义与统一执行管道入口处的校验环节。
它防的是以超出授权的数据集执行。判定按组织、角色、资源类型、动作类型与数据范围五个维度进行， 与 Web 端使用的是同一份能力定义。角色在系统内的授权记录只有一份， 界面显示、接口放行与工具清单均由该记录生成。
因此不会出现 Agent 可改而人工不可改，或相反的情形。数据范围以条件规则实现， 条件在后端被取出并注入查询语句；前端只承担显隐，实际放行以后端注入条件后的结果为准。
依据：能力定义文件与统一执行管道内部的权限裁决环节。五个判定维度的展开见 《CASL 同构权限系统》。
它防的是审批的内容与将要执行的内容不一致。Agent 提交审批时给出的是自然语言描述， 描述与动作参数之间可能存在偏差，而审批人只能依据眼前的材料作答。
预演在执行前返回将要发生的变化——哪些字段将变为哪个值、哪些关联记录随之改变——且不产生任何写入。 审批人看到的是预演结果，据此决定是否确认，判断依据由描述转为结果。
依据：dryRun 预演的返回结构与统一执行管道的预演环节。
它防的是不可逆动作被自动执行。改账、报废与权限变更等高风险动作在动作定义上标注确认要求， 未携带确认的调用一律拒绝执行。该标注属于动作自身的属性，不由调用方选择，也不因通道不同而放宽。
由此形成一条边界：确认要求不可被配置取消。取消人工确认等同于取消审批，本系统不提供该项配置。 Agent 可以完成这些动作的前期准备与预演，执行仍须由有权限的人确认。
依据：动作契约中高风险动作的确认标注与执行管道内部的审批校验环节；审批与业务代码的分离方式见 《审批工作流引擎》。
它防的是重试造成的重复入账。自动调用会因超时、断连与重试机制被提交多次， 同一笔业务由此产生两条记录，这是 AI 参与企业系统操作时较常见的风险点。
调用携带幂等键时，同一次调用只生效一次，重复提交返回首次执行的结果。 人工操作用户连点两次的可能性很低，自动调用不受此限制，故该环节的约束对象主要是后者。
依据：幂等键（idempotencyKey）的实现记录与执行管道的幂等环节。
它防的是事后无法认定责任环节。每次写入记录通道、身份、动作、参数与结果， 可回答该条资产状态由谁、在何时、通过哪条通道修改。
记录口径与人工操作一致，Agent 代操作同样落在记录之内。审计不设两套格式， 人操作与 AI 触发之间的差别只体现在通道字段的取值上。
依据：执行管道的审计写入环节，字段包含通道、身份、动作、参数与结果。
上述环节的排列得出一个可以直接陈述的结论：外部 Agent 没有独立的判定路径，也没有可以跳过的环节。 「不取得特权」由此是架构的结果，而非一项需要事先约定的承诺。
权限判定在服务端完成：工具清单由服务端按账号权限生成，客户端拿到的清单即为服务端的授权结果， 前端不存在可绕过的调用路径，客户端也没有可试探的对象。 可核验的是该清单与站内所述的动作契约总数（247 条）、业务域覆盖（35 个）是否一致。
权限判定、预演、确认与审计均在唯一写入口内部完成，三条通道没有各自实现安全约束的余地。 需要讨论的因此落在路径是否存在这一处，而非自主执行的范围由谁声明——该路径不存在。
actionRegistry）与统一执行管道（executeAction）的环节划分；CASL 能力定义的共用方式；高风险动作的确认标注动作契约总数、业务域覆盖与审计记录口径，均无需采信本页陈述： 登录页内演示账号，由贵方自有客户端导出工具清单即可逐项比对。