新边界在工具发现处
Agent 启动后问服务器：你有什么工具？服务器回答的列表，就是这一次任务的能力集。列表被加一项，能力就加一项，不必改业务代码，也不必重新发版。
MCP 安全 · 工具发现、权限与供应链CHENGDU, CN / 2026
MCP 不是插件。
它是新的执行平面。
MCP 让 Agent 在运行时发现工具、携带上下文、调用本地或远程服务。对工程团队，这像统一插头；对安全团队，企业攻击面多了一层网关看不见的东西：工具目录。评审如果还停在“这个模型供应商在名单里”，会漏掉真正执行的那一端。夜船有明把 MCP Server 安全测试纳入标准化 AI Agent 安全评估：核对接线来源、凭证落点、工具表能否在运行时增减，并用 KUROSHIO 作为验证引擎留下可复核的发现与调用证据。
这页写给谁
- 正在把内部搜索、工单、代码仓库接到 Agent 的平台与集成团队
- 需要审批第三方 MCP 或公开目录服务器的安全与供应链负责人
- 要确认 MCP 权限没有超过任务范围的 AppSec、红队与 CISO 办公室
01问题
问题
过去，接入一个内部系统要过应用、账号、网络和接口评审。现在，一条 MCP 配置可能同时完成发现、鉴权和调用。能力不再只写在业务代码里，而写在服务器当场申报的工具表上。
评审停在模型供应商
名单里有模型厂商，不等于执行端受控。真正调用内部系统的，往往是 MCP 进程、它持有的令牌，以及运行时才出现的函数。
名字像官方，不表示发布通道受控
公开市场里的“方便服务器”会很快进入开发者笔记本，再进入内部试用。同名服务、不同实现，Agent 只看见工具表变了。
MCP 把第三方运行时嵌进了 Agent
发现过程信任的是服务器声明，而不是企业已经审过的接口清单。服务器如果说自己能导出，模型就可能当真。
02风险
风险
钥匙还在、门换了：开发环境指错地址、配置仓库改了一行、同名包发了新版本、内部 DNS 被污染，结果都一样。业务系统不必被攻破，数据已经可以离开原处。
同名服务，不同权限边界
搜索 MCP 仍叫 internal-search，工具列表却多出导出接口。搜索凭证一旦也能驱动导出，替换服务器只是把这条能力亮出来。
凭证顺着工具链流动
为了让搜索好用，团队常把内部 API 令牌直接交给 MCP 进程。谁能改 MCP，谁就能用这把令牌做事。Agent 并不持有最小权限，MCP 持有。
工具表热更新等于未审批的权限变更
善意的版本更新同样能扩大攻击面。增减一项工具，应按权限变更评审，而不是热更新后靠模型自己适应。
返回值进入下一轮调用
工具结果里如果带着密钥或个人信息，下一轮对话还可能把它们再送去模型，或填进另一个工具的参数。
第三方 MCP 是供应链问题
代码来源、更新通道、数据驻留、崩溃时日志去哪里，都应当成新的集成方来问。来源说不清的 MCP，按未授权软件处理。
03怎么测
怎么测
MCP 安全测试不是再扫一遍主机。要按任务剧本看：实际注册了哪些函数、凭证给到哪一层、发现过程能否审批。夜船有明的标准化 AI Agent 安全评估把这一层收进范围，KUROSHIO 负责规划、探索、工具调用和证据。
- 01
先确认来源，再确认能力
服务器由谁维护，镜像或二进制如何固定，更新谁批准。把 MCP 列入资产清单，与 CI 里的第三方 Action、生产里的 sidecar 同类处理。
- 02
启动后列出真正的工具表
逐项看读还是写、是否出站、是否执行命令、是否接触密钥。只听介绍说“这是搜索插件”不够，要看实际注册出来的函数并存档。
- 03
凭证按工具裁剪
给任务发牌，不给服务器发万能钥匙。搜索令牌不该具备导出、删除或管理权限，也不能被其他工作区复用。
- 04
把发现和调用记成审计对象
事后要能回答：当时模型看见了哪些工具，是谁提供的，入参从哪里来，能不能被外部文本填充，记录有没有和用户、任务对齐。
- 05
用受控剧本验证替换与漂移
在授权的隔离环境中观察同名服务、工具表增减和版本更新会不会扩大权限。KUROSHIO 留下的是路径和是否被策略拦住，而不是对生产数据的破坏。
05交付物
交付物
评估结束时，未参与搭建的人也应能看懂：数据从哪进来、从哪出去、哪一把钥匙过大。缺证据的演示，不计入评估完成。
MCP 资产与信任边界图
模型、Agent、MCP 服务器、账号、外部输入和内部系统画在一张图上，标出来源、运行位置和数据驻留。
工具表与权限对照
实际注册函数、读写与出站属性、所持凭证、是否超出当前任务说明书。热更新通道单独标注。
供应链与来源结论
维护方、版本钉死方式、更新审批、公开目录风险。来源说不清的项，明确写成上线阻塞。
攻击路径与验证证据
何种发现或替换，经过哪一次工具调用，到达何种结果。附输入摘要、工具请求与返回、策略是否拦截，可供第三人复核。
修复建议与复测
固定来源和版本、工具表变更走审批、按工具裁凭证、补齐发现与调用日志。对已修复项用同一条路径再走一遍。
管理层摘要
两页内说明测了哪些 MCP、最重要的三件事、建议的上线条件。KUROSHIO 承担证据段，不上线决定本身。
06评估怎么进行
评估怎么进行
KUROSHIO 作为验证引擎承担规划、探索、工具调用和证据。范围确认与是否上线，仍由你们决定。
- 01收资产：MCP 来源、版本、安装审批、运行位置与凭证落点
- 02列工具表：实际注册函数、读写与出站、与任务范围对照
- 03走受控剧本：搜索、导出倾向、来源替换、工具表变更
- 04交证据与上线条件：固定版本、审批变更、裁剪凭证、复测结果
查看 KUROSHIO 工作台
在交互演示中切换范围、探索、验证和报告四个阶段，了解授权范围、任务编排、关联证据与报告摘要如何组织在同一工作台。内容使用示例数据，展示通用评估流程。
07常见问题
开始之前。
01MCP 安全测试和传统接口评审有什么不同？
接口评审看的是已经登记的 API。MCP 的能力表来自运行时发现，服务器可以在不改业务代码的情况下增减工具。测试必须对着实际注册出来的函数、凭证和更新通道，而不是介绍页上的“搜索插件”。
02公开目录里的 MCP 能不能直接给生产 Agent 用？
不应只凭名字。要能说清维护方、版本如何钉死、数据驻留、凭证范围和退出方式。来源说不清的，按未授权软件处理。评估把这些条件写成上线开关，而不是事后补防火墙。
03评估会不会在我们的生产 MCP 上做破坏性操作？
标准化评估在书面授权范围内进行。导出、删除、出站这类高影响动作默认在隔离或只读条件下验证；需要写操作时事先确认。KUROSHIO 留下调用请求与是否被策略拦截的证据，不对生产数据做破坏。
把 MCP 当成新的集成层来评估。
夜船有明提供标准化 AI Agent 安全评估。MCP 安全是其中的执行平面：来源、权限、工具表与调用证据。KUROSHIO 作为验证引擎，把发现过程变成可审阅的路径。从你正在接入的那一个服务器开始。