智能体MCP网关POC不能只证明请求经过网关。Agent先发现可用工具，再以某个身份调用，工具或网关还可能连接外部目标。三段中的任一处丢失用户、任务或策略上下文，都可能出现“看得到但不该用”“调用被允许但参数越界”“内部权限正确却把数据发到错误目标”。

POC应让同一个身份和任务陆续在穿过发现、调用和出站三道闸门，并在每段加入反例。这样才能验证策略是否贯通，而不是三个功能分别存在。

发现闸门控制模型能看见哪些工具

工具发现决定Agent的候选动作空间。用户无权使用的工具最好不进入候选，测试工具也不应对生产Agent可见。发现策略可结合用户、Agent、团队、环境、用途和工具状态。

准备三个目录项：公共只读、部门受限、已停用或测试工具。用不同身份请求发现，记录返回工具、版本和策略。不可见工具的描述、名称或参数也不应无意泄露敏感能力。

发现结果还要与目录生命周期一致。工具暂停或下线后，旧会话与缓存是否继续保留，Agent是否会按历史计划调用，是POC的关键反例。

调用闸门重新验证动作与参数

发现允许不等于调用授权。调用时目标对象、参数、环境、审批和权限可能已经变化，网关要基于当前上下文重新决策。高风险工具还需区分只读与写入动作。

测试一条正常调用、一条越界对象、一条越界参数和一条审批缺失。观察拒绝发生在转发前，Agent收到可判断结果，网关记录策略版本和原因。拒绝后Agent不应顺利获得改名、换工具或多次重试绕开。

发现决定“可以考虑什么”，调用决定“此刻可以做什么”，两者不能合并成一次静态授权。

出站闸门限制目标、协议和数据

工具调用可能由网关直接访问外部服务，也可能调用内部MCP服务后再出站。POC要画清真正的网络和数据路径，验证目标域、地址、协议、端口或其他企业控制，以及发送的数据类别。

受控出站不只做网络白名单。相同目标的不同路径、重定向、动态地址和参数中嵌入的外部链接都可能绕过意图。平台或周边安全能力需要根据企业规则限制，审计中保留实际目标和结果。

工具若需要访问互联网，应说明用途、数据、凭据和失败方式。不能访问时，Agent应降级或转人工，而不是选择未知代理或替代通道。

三段闸门使用同一上下文才有意义

下图从工具发现进入受控调用，再到受控出站。阅读时关注身份、任务和事件标识是否贯穿三段；如果每段重新生成无关身份，审计无法证明最终请求来自谁。

同一上下文至少包括入口主体、Agent或应用、任务、工具与版本、动作和环境。敏感参数可以只记录摘要，但策略需要的属性不能在中途丢失。

三段证据可以存于不同系统，网关要提供关联。发现日志证明当时看到什么，调用日志证明为何允许或拒绝，出站日志证明实际去了哪里。最终还应关联工具和业务结果。

POC矩阵按身份和异常交叉

纵轴设置普通用户、受限用户、管理员或服务身份，横轴设置正常工具、受限工具、停用工具、参数越界和非法出站。每个单元预先写期望：不发现、发现但拒绝、需审批、允许并记录或阻断出站。

矩阵不必把所有组合跑满，优先覆盖高风险交叉。例如受限用户发现高风险工具、服务身份尝试越界对象、正常工具被诱导访问非批准目标。测试结果要区分发现层、调用层和出站层，便于定位。

真实业务目标不适合测试非法出站时，可以搭建隔离目标，验证网关是否按域名、地址和策略阻断。模拟顺利获得不代表正式网络配置已完成，生产控制仍需安全团队复核。

重点测试上下文丢失与策略变化

第一类断裂是身份在发现后丢失，调用转为共享高权限服务账号。第二类是工具描述或参数变化后，网关沿用旧策略。第三类是审批顺利获得后目标或参数被修改。第四类是出站发生重定向，实际目标不再受原策略约束。

逐项改变一个条件，观察网关拒绝、告警和审计。策略更新后，正在执行和新任务分别如何处理也要明确。立即中止可能影响业务，继续旧策略又可能扩大风险，应由动作后果决定。

网关失败时默认策略要明确

网关、策略服务、身份服务或审计系统不可用时，是拒绝、只允许低风险工具，还是走应急通道？不同工具可以有不同默认策略，但必须事先定义。高风险写入不应在关键控制不可用时自动开放。

故障测试要确认已放行请求和排队请求如何处理，恢复后是否重复调用，日志缺口如何标记。若网关恢复导致策略状态不一致，应暂停相关工具而不是继续猜测。

策略不可用、身份缺失、出站目标无法确定或审计完全中断时，高风险调用应有可执行的停止路径。

放行结论按工具风险分层

POC顺利获得可以只覆盖某些身份、工具、动作和目标。低风险只读工具先放行，高风险写入待审批与出站补齐。不要因为网关产品总体顺利获得，就默认新工具自动顺利获得；工具仍需自己的准入。

相关MCP、Agent和AI基础设施内容可浏览 AI基础设施分类；整体方案信息可在核验后查看 AI解决方案。下一步用一个真实任务走完整三段，并复跑一项策略变化。

关键规则变更后，还应让受限身份复跑旧任务，确认缓存与在途上下文没有绕过新策略。

网关自身故障恢复后，应复跑允许、拒绝和非法出站样本，确认身份缓存、凭据和策略版本重新一致。

放行范围应精确到身份、工具、动作和目标，新增工具不能因为网关总体顺利获得就自动继承三道闸门结论。

新工具的首次放行也应独立保留身份、动作、目标和审计样本。

还需由安全角色复核实际出站目标与审计记录，并把未覆盖协议和异常列入下一轮测试。网关总体顺利获得不能替新增工具、身份或目标自动放行。

POC结束后应保存三道闸门的允许与拒绝样本，形成网关升级和新工具准入的回归基线。每次身份、策略、路由、凭据或出站规则变化，都按影响重跑相关样本，由工具所有者、安全与Agent团队分别确认。

最终范围要可执行。

常见问题

工具能被发现但不能调用算POC失败吗？

不一定。发现和调用可以有不同权限，某工具对用户可见但需审批或更高授权是合理设计。关键是状态清楚，Agent不会把可见误解为可执行，用户也能知道下一步需要什么。

• 检查发现结果是否包含适当的使用条件而不泄露敏感细节
• 调用时重新评估身份、动作、对象、参数和审批
• 拒绝后停止或申请授权，不反复尝试替代路径
• 审计能关联发现、调用决定和最终任务结果

如果工具本不应被该用户知道，发现本身就是失败；若设计允许可见但受限，则调用拒绝可以视为控制正确生效。

还需用同一入口身份和任务标识串联发现、调用与实际出站，确认当前答案覆盖的是哪道闸门及其失败后的默认策略。

受控出站需要验证哪些异常？

至少验证未批准目标、地址或域名变化、重定向、参数携带敏感数据、凭据失效和出站控制不可用。具体协议与网络检查由企业架构决定，POC重点是实际目标和数据没有偏离策略。

• 使用隔离的非法目标验证转发前阻断
• 检查重定向或动态目标是否重新评估
• 对敏感字段做脱敏、阻止或审批
• 出站失败时确认Agent不会选择未知替代通道

任何测试都应在授权环境中进行。无法在正式网络模拟时，保留结构相同的隔离验证，并将生产网络与安全配置列为上线前条件。

还需用同一入口身份和任务标识串联发现、调用与实际出站，确认当前答案覆盖的是哪道闸门及其失败后的默认策略。

三项验证为什么必须使用同一身份？

因为发现、调用和出站共同构成一次委托。若发现使用用户身份，调用变成高权限服务账号，出站又只记录网关身份，最终无法证明谁授权了什么，也可能在中途扩大权限。

同一身份不一定是同一个技术令牌，而是可追溯的委托链：入口主体、Agent、工具调用和目标系统执行主体之间有明确映射。POC应从任一段日志回到原任务，并确认策略使用了正确属性。

策略回归应保留允许与拒绝两类样本，防止修复误拒绝时意外放开非法出站。

还需用同一入口身份和任务标识串联发现、调用与实际出站，确认当前答案覆盖的是哪道闸门及其失败后的默认策略。