AI-Infra-Guard MCP 动态信息收集 Agent 提示词工程:基于 tools 描述的可追溯服务画像与攻击面预判
2026/9/18 12:34:24 网站建设 项目流程

AI-Infra-Guard MCP 动态信息收集 Agent 提示词工程:基于 tools 描述的可追溯服务画像与攻击面预判

【免费下载链接】AI-Infra-GuardA full-stack AI Red Teaming platform securing AI ecosystems via Agent Scan, Skills Scan, MCP scan, AI Infra scan and LLM jailbreak evaluation.项目地址: https://gitcode.com/GitHub_Trending/ai/AI-Infra-Guard

导读

本文深入剖析 AI-Infra-Guard 仓库中 mcp-scan 模块的动态扫描提示词模板——MCP 服务动态信息收集提示词。该模板驱动 LLM Agent 对运行中的 MCP(Model Context Protocol)Server 进行第一阶段的"信息收集",在不触碰副作用工具的前提下,仅凭工具名称、描述与输入/输出形态,产出一份可追溯、可复用的服务概览与安全风险面报告。读完本文,你将掌握该提示词的完整设计逻辑、报告章节规范、只读探测边界,以及它在四阶段动态分析流水线中的实际调用位置与运行方法,可直接用于对自有 MCP Server 做安全评估的前置侦察。

一、定位:动态分析流水线的第一块基石

mcp-scan 的 Agent 支持两类扫描路径:对源码目录的静态扫描agent.scan),以及针对运行中 MCP Server动态分析agent.dynamic_analysis)。动态分析的入口在 agent.py,由四个阶段串联而成:

阶段模板职责
1agents/dynamic/project_summary.md(本文主角)基于 tools 描述生成信息收集报告,为后续阶段提供"项目概览"上下文
2agents/dynamic/malicious_behaviour_testing.md恶意行为检测,生成威胁清单
3agents/dynamic/vulnerability_testing.md漏洞测试用例生成与执行
4agents/dynamic/general_analyzing_prompt_template.md基于前序报告与调用记录做漏洞整理,输出<vuln>XML

从 agent.py 可以看到,阶段 1 的输出被写入result_meta["readme"],同时以ctx_key1("信息收集报告"/"Info Collection Report")传入阶段 2 与阶段 3,作为后续测试与分析的上下文基底。也就是说,信息收集质量直接决定后续威胁映射、测试用例生成与漏洞判定的上限——这是整条流水线"先知己、后知彼"的关键步骤。

二、模板的核心设计原则:四条不可逾越的边界

提示词开篇即定义本阶段的角色与信息来源,其设计可用四条原则概括:

1. 信息来源以 tools 描述为绝对主体。模板明确要求"信息来源以 MCP server 的 tools 描述为主(即系统提示词中提供的<mcp_tools>工具描述块)",Agent 必须从工具的名称、描述、输入/输出形态中提炼"项目概览信息"。这一约束来自动态分析的系统提示词 system_prompt.md,其中声明{mcp_tools}占位符会被远程 MCP 服务器的工具描述填充,且 Agent 可以通过call_mcp_tool工具调用这些远程工具。换言之,信息收集的"食材"就是 MCP 服务器自己暴露的工具清单。

2. 结论必须可追溯。对"项目类型/用途/集成点/暴露面"的任何结论,都必须能在报告中引用具体工具名称作为依据。这从根本上杜绝了模型幻觉式推测,保证了审计报告的可复核性。

3. 最小化动态探测。如需补充信息,只允许调用只读、低风险的探测型工具(语义如 list / describe / get / read / status / health / ping),并须记录调用与结果;严禁调用任何可能产生副作用的工具(写入/删除/执行/支付/转账/修改配置/部署等)。这是安全评估的底线:侦察阶段不允许对目标造成任何状态变更。

4. 安全视角前置。仅基于工具能力与描述,识别高风险能力(文件读写、命令执行、网络访问、凭据处理、上下文共享等)与潜在攻击面,为后续审计提供线索。这一步与后续阶段的 MCP01-MCP10 风险框架形成呼应(详见下文第五节)。

三、输出要求详解:五章结构的"信息收集报告"

模板规定输出为一份 Markdown 格式的MCP 服务信息收集报告,要求"读者(对项目一无所知)能快速理解服务能力与风险面"。若输入数据中存在相关信息,必须包含以下章节:

项目概述

  • 基础信息与项目定位:项目类型、核心功能、业务价值及用户群体;
  • 技术架构与实现方案:高层次描述整体设计。

技术分析

  • 编程语言与技术栈:主要语言、框架、库和工具;
  • 接口与能力清单:基于 tools 描述汇总"工具能力矩阵",模板建议以表格列出tool_name、用途、输入、输出、是否只读;
  • 代码风格指南:代码规范、格式化工具或约定(如 linter 配置);
  • 数据处理与存储方案:数据流、数据库或文件处理方式;
  • 网络通信接口设计:API、协议或外部集成点。

安全评估

  • 权限需求与访问控制:身份验证、授权机制;
  • 数据处理安全性:输入验证、加密措施;
  • 网络暴露面分析:外部接口风险;
  • 潜在安全隐患:基于代码模式识别的弱点;
  • 安全注意事项:从文档或注释中提取的明确安全提示。

开发与运维细节

  • 测试说明:测试策略、覆盖范围及测试文件位置;
  • 功能模块清单:主要组件、依赖关系及敏感操作识别点;
  • 部署流程:如何构建和发布项目。

附加信息

  • 其他关键发现:如项目特有的约定或异常结构。

值得注意,"工具能力矩阵"中的"是否只读"一列,正是把安全视角落到结构化产出上的关键设计——它让高风险能力(如文件读写、命令执行)在报告里一目了然,直接服务于后续阶段挑选探测目标。

四、事实边界:不可确认即标注"无相关信息"

模板在注意事项中给出了三条刚性纪律:

  1. 报告内容必须严格基于输入数据,本阶段优先引用工具名称与工具描述作为来源依据;
  2. 语言简洁、客观,避免主观推测;无法从 tools 描述得到的信息,必须明确标注"无相关信息/无法从 tools 描述确认"
  3. 只读探测需留痕:如进行了只读探测调用,必须在报告中列出调用的工具、参数、返回摘要与结论

这三条纪律共同构成了"证据链闭环":结论 → 工具依据;补充信息 → 只读调用记录;缺失信息 → 显式标注。它保证了信息收集报告既是"画像",也是可审计的"案卷底稿",避免把猜测当事实传递给下游漏洞检测阶段。

五、源码佐证:阶段如何被装配与执行

动态分析的信息收集阶段由 ScanPipeline.execute_stage_dynamic 驱动,其装配过程清晰地体现了提示词模板的地位:

  • 模板经prompt_manager.load_template("agents/dynamic/project_summary")加载为 Agent 的 system instruction;
  • Agent 以BaseAgent实例化,名称即"信息收集 Agent",携带主 LLM、专用 LLM(thinking/coding)与ToolDispatcher
  • 用户消息为"请进行信息收集,进行MCP动态扫描",随后追加由阶段 2/3 报告构成的上下文数据;
  • 阶段 4 使用 general_analyzing_prompt_template.md 中的MCP 特定风险评估框架对最终漏洞归类:包含 MCP01–MCP10 十类 MCP 特定风险(Token 泄露、权限蔓延、工具投毒、供应链攻击、命令注入、提示注入、认证授权不足、审计缺失、影子服务器、上下文过度共享),外加 Name Confusion、Rug Pull、Tool Shadowing 三类补充风险。信息收集阶段识别出的"高风险能力"(文件读写、命令执行等),正是这些风险维度在工具层面的落点。

与之配合,远程工具的执行依赖 mcp_tool 工具模块 与ToolDispatcher(其构造参数mcp_server_url/mcp_headers在 agent.py 中传入),后者负责把 Agent 生成的call_mcp_tool调用转发到目标 MCP 服务器并取回结果。

六、实战:如何运行动态信息收集扫描

动态分析模式由 main.py 中的--server_url参数启用:当该参数存在时,Agent 调用dynamic_analysis(prompt)而非静态scan()。运行示例(参见 README.md):

# 对运行在 http://localhost:8000/sse 的 MCP Server 做动态分析 python main.py \ --server_url "http://localhost:8000/sse" \ --prompt "Test tool poisoning vulnerabilities"

常用配套参数:

参数说明默认值
--server_url远程 MCP Server 地址(SSE/流式端点),启用动态分析None
--header自定义 HTTP 头(key:value),可多次指定,用于携带鉴权信息[]
--model/-mLLM 模型名deepseek/deepseek-v3.2-exp
--api_key/-kAPI Key,缺省时回退到环境变量LLM_API_KEY/OPENAI_API_KEY/OPENROUTER_API_KEY来自环境变量
--language报告语言zh/enzh
-o FILE结果保存为 JSON 文件None

配置优先级为:CLI 参数 > 环境变量 > 代码默认值。建议配合--header "Authorization: Bearer xxx"传递目标 MCP 服务的鉴权头;若目标服务无鉴权,则信息收集报告中的"权限需求与访问控制"章节可直接标注"无法从 tools 描述确认",这本身就是一个值得记录的安全观察点。

七、落地建议与进阶用法

  1. 把报告当作下游测试的输入清单:信息收集报告中的"工具能力矩阵"(含只读标识)应直接映射到阶段 3 的"威胁 → 工具映射"(threat-to-tool mapping),识别出能读取 secrets/config、返回用户可控文本、执行命令、拉取远程内容或操纵上下文的工具,作为测试用例的优先目标。
  2. 善用"无相关信息"标注:模板刻意允许不确定性显式存在,这比硬凑的推测更有利于下游漏洞判定的准确性;阶段 4 的严格过滤规则(排除正常业务功能、框架默认行为、无实际危害项)也依赖上游信息的真实性。
  3. 保持探测只读:任何绕过最小化探测约束的行为(如调用写/执行类工具做验证)都会污染目标状态,应通过--header与任务约束双重控制;如需更激进的验证,应交给后续恶意行为检测阶段在受控沙箱内完成。
  4. 自定义场景main.py支持-p/--prompt注入自定义扫描提示词,可在不修改模板的前提下追加聚焦指令(例如"重点识别文件读写类工具的暴露面"),模板本身的章节骨架与纪律约束仍然生效。

通过"工具画像 → 能力矩阵 → 攻击面线索"这一层层收敛的信息漏斗,MCP 动态信息收集提示词模板让安全评估在零副作用的前提下完成对目标的全面摸底,是 AI-Infra-Guard 对 MCP 生态做系统性风险评估的第一道工序。

【免费下载链接】AI-Infra-GuardA full-stack AI Red Teaming platform securing AI ecosystems via Agent Scan, Skills Scan, MCP scan, AI Infra scan and LLM jailbreak evaluation.项目地址: https://gitcode.com/GitHub_Trending/ai/AI-Infra-Guard

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询