工具输入与业务影响不清
直接暴露零散 API 会让调用方难理解必填字段、写操作范围与失败结果。
场景解决方案 / Agent 与 MCP 安全解决方案
MCP 工具访问接入控制
将已发布的连接流整理为 MCP 工具，并用当前已核实的 API Key 方式控制调用入口。
API Key 验证调用凭据，不代表具体员工身份、Agent 委托身份或下游业务权限。
客户问题
把业务工具开放给 Agent 时，需要守住调用与业务权限边界
MCP Server 可连接不等同于工具输入安全、业务授权充分或目标操作成功。
共享凭据容易被误认为用户身份
API Key 可用于接入鉴权，但无法单独说明哪个员工批准了调用或目标数据允许访问到什么程度。
整体思路
先定义工具边界，再鉴权并核查执行链路
经测试发布的连接流可作为 MCP Server 通过 Streamable HTTP 提供工具调用。调用按已核实的 API Key 方式接入；连接流负责其已配置的业务步骤，目标系统仍执行自身权限检查。
- 01Agent Client连接 MCP Server 并发现工具
- 02API Key 鉴权验证调用方持有的接入凭据
- 03数犀 MCP Server按工具输入执行已发布连接流
- 04目标系统校验业务权限并返回结果
员工级授权、DCR、细粒度工具授权和完整 Agent 审计不因 API Key 接入而自动具备；需按实际版本另外核验。
核心任务
定义并发布可调用工具 · 管理调用凭据并检查运行结果
01 / 定义并发布可调用工具
把连接流输入输出和影响说清楚
- 01连接流封装经确认的业务步骤
- 02MCP Tool定义输入、输出与调用边界
- 03测试发布验证工具发现及参数校验
原来怎么处理
Agent 需要调用业务 API 时，开发者要分别理解接口参数、认证方式和业务异常。
数犀如何处理
先把现有 API 编排成输入输出明确的连接流和 MCP Tool，验证必填字段、允许的操作和错误返回后再发布。工具可调用范围应与其业务影响匹配。
用工具发现、必填缺失、错误类型和目标拒绝等请求验证工具定义是否准确。
希望带来的变化
让调用方看到边界清晰的工具入口，减少直接耦合零散接口的工作。
相关能力连接流发布 MCP ServerMCP Tool 定义Streamable HTTP
02 / 管理调用凭据并检查运行结果
分清鉴权结果和业务结果
- 01调用请求携带配置的 API Key
- 02MCP Server验证接入并触发流程
- 03管理员检查执行记录与目标结果
原来怎么处理
调用成功或失败后，管理员可能只知道 API Key 是否有效，无法据此确认具体员工授权和目标数据权限。
数犀如何处理
按已核实的 API Key 方式校验接入凭据，并查看连接流运行记录。密钥保管、轮换和可用范围由项目约定；员工身份和下游授权仍需独立设计。
测试无效密钥、错误输入、目标接口拒绝与超时；分别核验接入鉴权结果、流程日志和目标业务记录。
希望带来的变化
清楚区分“调用者可连接”“流程已执行”和“目标业务写入成功”，方便管理员按层定位问题。
相关能力API Key 接入连接流运行记录目标系统结果核对
改善与验证
用只读工具先验证发现、鉴权与失败边界
先选择低风险工具验证整个调用路径，再评估写操作所需的额外控制。
| 常见处理 | 希望实现的变化 | 试点检查方法 |
|---|---|---|
| 工具范围难管理直接暴露零散 API 会让调用方难理解必填字段、写操作范围与失败结果。 | 希望实现的变化调用工具有明确输入、输出和已批准业务动作。 | 试点检查方法核对 MCP 工具列表、字段说明和测试请求结果。 |
| 接入凭据被当作完整身份API Key 可用于接入鉴权，但无法单独说明哪个员工批准了调用或目标数据允许访问到什么程度。 | 希望实现的变化API Key 仅验证接入凭据，目标系统继续检查业务权限。 | 试点检查方法用无效凭据、错误参数及目标系统拒绝测试三种不同结果。 |
本方案不承诺员工级委托授权、工具级细粒度授权或覆盖所有 Agent 活动的审计；超出已验证接入范围需另行核实。
