同一个动作在不同通道被调用时，权限判定与审计记录走的是同一套规则。
| 身份通道 | 谁在用 | 看得见多少 | 审计口径 |
|---|---|---|---|
| Web 控制台 | 人类用户 | 按角色授权 |
三者完全一致 —— 同一动作、不同入口，权限判定与操作日志不分叉。 这是"可核验"的技术前提：如果三个入口各有一套权限逻辑，就无法证明任何一个入口的边界。 |
| 内嵌 AI 助手 | 对话式操作者 | 按当前登录身份授权 | |
| MCP 工具 | 外部 AI 客户端 | 按接入凭证授权 |
GET /mcp/tools → 247 items
auth: readonly → tools: 由端点返回
你问 AI：你能看见几个工具？
这一节是整页最有说服力的部分——权限判定的位置与高风险动作的确认机制，决定了边界在哪里。
一个系统的安全能力，最直观的证据不是它声称通过了什么认证，而是 它在什么情况下会主动限制自己。
在 EAMX 里，权限不是在界面上"隐藏按钮"，而是在动作契约层被判定。 判定的时机在工具清单生成阶段：清单由服务端按账号权限生成， 客户端拿到的清单即为服务端的授权结果。
界面隐藏是表现层的事情，绕过界面就能试出来。契约层判定是结构性的： 调用方拿到的清单由服务端生成，未被授权的动作不在其中，也就不存在可试探的对象。
① 用演示账号接入后，让 你的 AI 报出工具清单，与本站所述的动作契约总数（247 个）、业务域覆盖（35 个）逐项比对——数得对，说明这份清单确实来自系统本身。
② 试着提交一个高风险动作（如资产处置）：系统会要求人工确认后才执行。这两步都不需要相信我们任何一句话。
三个通道（Web / AI 助手 / MCP）共用同一套动作契约，因此审计日志不会分叉。 这在集团场景下很关键：无论操作是通过界面点出来的，还是通过 AI 对话触发的， 审计轨迹都能还原到同一个人、同一个时间点、同一个动作。
演示端点使用的是独立隔离的演示数据，与任何客户正式环境不连通。你接入看到的只有示例数据。
任何支持 MCP 协议的 AI 客户端都可以。也提供 HTTP 接口，可直接用 curl 或 Postman 调用。
遵循 MCP 协议标准，主流支持 MCP 的客户端均可接入。我们不做客户端绑定。
是。演示环境独立部署、独立数据库、独立凭证体系，不与生产环境共享任何资源。