文章总结： Cisco开源FoundrySecuritySpec提出AI安全测试核心在于验证闭环而非模型本身，通过定义Orchestrator等8个Agent角色协同工作，结合130项功能需求和11条宪法原则构建可验证、可审计的安全评估系统，解决模型输出不可信问题并实现检测-预防-编码指导的完整闭环。 综合评分： 89 文章分类： 安全建设,AI安全,安全工具,技术标准,解决方案

别迷信模型了：Cisco开源Foundry Security Spec，用8个Agent角色+11条铁律告诉你——AI安全测试的核心不是模型，是模型周围的验证闭环

原创

逍遥 逍遥

昆仑AI安全实验室

2026年5月18日 23:08 广东

在小说阅读器读本章

去阅读

2026年5月12日，Cisco做了一件与其说是“开源代码”、不如说是“开源思想”的事——他们把内部打磨多年的Foundry Security Spec正式发布在GitHub上，面向整个行业开放。

这并非又一个AI安全工具。这是一套规范、一套蓝图、一套“如果你想用AI做安全测试，应该怎么搭系统”的架构指南。Cisco首席安全官Anthony Grieco在公告视频里说了句很直白的话：“网络安全是团队运动。我们所有人都必须走到一起，为更好的集体防御而协作。这是我们把知识分享出去、提高所有人水平的一种方式。”

Foundry Security Spec到底做了什么？一句话概括：它告诉你，问题不在模型，在模型周围缺失的系统。

Omar Santos，Cisco的杰出工程师，在官方博客里把这件事说得更透彻：“每个有前沿LLM访问权限的安全团队都至少尝试过同一件事——把代码仓库丢给模型，让它‘找漏洞’。结果通常是一堵无边无际、无法验证的输出墙，其中夹杂着敏锐的洞察和幻觉生成的漏洞，你既不知道错过了什么，也不知道什么时候算完成。Foundry Security Spec是这种混乱的解毒剂——它用编排、角色和护栏把模型包裹起来，让检测、验证和覆盖范围在设计阶段就确定好，而不是在聊天窗口里临时凑合。”

本文不做概念科普，直接拆Foundry的架构、八个Agent如何协同、130条功能需求从何而来、11条宪法原则怎么“长”出来的，以及它所指向的一个更深的产业趋势。

一、先说清楚：Foundry解决的是什么问题

Cisco选择开源Foundry，不是心血来潮。

Omar Santos描绘了一个几乎每个安全团队都经历过的场景：拿到一个内部代码仓库，听说GPT-5.5-Cyber或Claude Mythos能自动化挖洞，兴冲冲把代码扔进去，结果模型哗啦啦吐出一百多个“漏洞”——其中三分之一是幻觉，三分之一是真漏洞但严重性乱标，剩下三分之一混杂在一起根本筛不过来。团队花了两周人工验证，发现真正能落地的严重漏洞只有三个，而这三个早就可以用静态分析工具扫出来。

这就是Foundry要解决的三个核心痛点。安全团队不缺能挖洞的AI模型，缺的是把模型输出转化为“可验证、可审计、能递交给CISO”的完整工作流。安全评估的“完成信号”——什么时候算测完了、哪些代码路径覆盖了、哪些还没碰——完全缺失。安全审计要求的“溯源链”——这个漏洞是谁发现的、怎么验证的、谁批准关闭的——无从建立。

Santos在博客里下了断语：“一个是好玩的Demo，另一个是你敢在CISO和审计师面前defend的安全评估系统。差距是天壤之别。”Foundry Security Spec要做的，就是把“好玩的Demo”变成“工业生产系统”。

二、八个Agent角色：Foundry怎样把“一个模型”变成“一条流水线”

Foundry把“AI安全测试”这个概念拆成八个明确的Agent角色，每个角色有精确的输入、输出和功能需求。注意，是角色定义，不是代码实现。你可以用子进程循环、基于图的流水线、无服务器函数、或自定义框架来实现它们——Cisco给的是“形状”，实现是你自己的事。

Orchestrator（编排器）： 整个系统的总调度。它不挖洞、不验证。它做的是：接收安全评估请求→验证请求合法性→将评估任务分发给Detector。它检查资源配额和API速率限制，在整个管道运行期间持续监控Detector的输出边界。

Indexer（索引器）： 当评估目标是大规模代码库时，Indexer负责提前建立索引——哪些文件需要扫、哪些测试文件可以跳过、哪些第三方库标记为“已知安全”。它给Cartographer提供结构化的输入清单。

Cartographer（制图师）： Foundry体系中最具特色的Agent。它的核心职责不是找漏洞，而是绘制目标系统的“安全攻击面地图”——哪些API端点暴露了、哪些数据流跨越了信任边界、哪些组件使用了已知高危库。Detector拿到这张地图后不再盲目扫描，而是按图索骥，大幅减少幻觉和无意义的输出。

Detector（检测器）： 这是唯一直接调用AI模型的Agent。它在一个受限沙箱中运行——不直接访问生产环境、不修改文件、不被允许写入任何东西。它的输入是Cartographer的攻击面地图加Indexer的索引清单，输出是一组初步发现，全部带有置信度分数和推理链。

Triager（分类器）： 接收Detector输出的原始发现，执行第一轮筛选：去重（同一个漏洞被Detector以不同方式报告了三次，合并为一个）、严重性重标（基于Cisco内部漏洞分类体系）、优先级排序。

Validator（验证器）： 这是Foundry架构中最关键的Agent，也是解决“模型幻觉”问题的核心防线。它用确定性规则——CodeQL查询、Semgrep规则、正则匹配——对Triager筛选后的发现进行二次验证。Validator不依赖概率模型，每一步验证都有明确的真假输出。它把幻觉发现、误报、无法复现的漏洞全过滤掉。

Coverage-Guide（覆盖度引导器）： 它跟踪已覆盖的代码路径和攻击面区域，向Orchestrator反馈哪些区域还没被Detector扫过，触发补充扫描。它的核心输出是一个“完成信号”：当覆盖率达到预设阈值且新的扫描不再产生有价值的发现时，系统可以宣布评估完成。

Reporter（报告器）： 负责把经过验证的发现打包成人类可读的报告——按严重性排序、附验证证据、含修复建议、可审计的溯源链。

这八个角色不是无序排列的。Orchestrator启动→Indexer准备→Cartographer绘图→Detector扫描→Triager筛选→Validator验证→Coverage-Guide确认覆盖→Reporter输出报告。每一步都有明确的输入输出契约。任何一个角色的输出不合格，下游角色有权退回上游重做。这套角色分工的本质，是把“人类安全专家的决策流程”固化为“AI可执行的Agent流水线”。每个角色只做一件事，边界清晰、可独立测试、可替换。

三、130项功能需求：每一个都带着“为什么存在”的解释

Foundry Spec不是一堆空洞的角色描述。每个角色都绑定了细粒度的功能需求，总共约130项，每项都附有inline rationale——解释这条需求为什么存在、不遵守会导致什么后果。

比如：Detector必须为每个发现输出置信度分数，Validator的验证结果必须可复现（相同输入→相同输出），Coverage-Guide的覆盖阈值必须由操作员定义，不能由AI自主设定。所有发现从检测到验证到报告的完整溯源链必须可审计。

这些需求不是Cisco拍脑袋想出来的，而是从其内部安全团队多年的生产事故中提炼出来的。当一个Detector发现因为缺乏置信度分数导致团队在假阳性上浪费了两周、当一个漏洞的严重性因为缺乏统一分类体系而被误标为“低危”导致延迟修复——每一条功能需求背后都有一个真实的生产故障。

四、11条宪法原则：从血泪教训中长出来的“铁律”

Foundry的第二份核心文档是一份“宪法”——11条不可侵犯的原则。

Cisco官方明确表示，每一条原则都对应一个他们自己曾经犯过、诊断过、修复过的生产错误。这些原则同时写给AI Agent（如Claude Code或Codex）和人类开发者读——工程师如果想偷懒放宽某条原则，必须先读完这条原则下面写着的“上一次违反这条原则导致的后果”，再决定要不要冒这个险。

这11条原则本质上是Cisco安全团队过去几年在AI辅助安全测试上踩过的所有坑的工程化总结。知道什么不能做，比知道什么能做更值钱。

五、与Project CodeGuard的闭环：检测-预防-编码指导

Foundry不是孤立的。Cisco在2025年10月已开源了Project CodeGuard，并在2026年2月将其捐赠给CoSAI。在Cisco的设计里，CodeGuard和Foundry构成一个“检测-预防-编码指导”的完整闭环。

CodeGuard为Detector提供已知漏洞类型的规则库——确定性规则扫描代码中已知的安全问题。Foundry则在CodeGuard之外增加了两个关键能力：一是AI驱动的探索性漏洞发现，Detector利用LLM的推理能力发现CodeGuard规则库未覆盖的新型漏洞或目标特有的弱点；二是验证闭环，当新漏洞被Validator确认为真后，Foundry将其转化为新的CodeGuard规则纳入后续扫描，同时可选地转化为安全编码指导，前移到开发阶段。

这个闭环的意义在于：安全评估不再是一次性的“找洞→修洞”，而是一个持续学习、持续进化的系统。每一次评估都在让规则库更强，每一次误报都在让验证更精准。

六、更深一层的信号：整个行业正在形成共识

如果把Foundry Security Spec放在2026年AI安全全景图中看，Cisco并不是孤例。

Parallax架构提出“认知-执行分离”，将AI推理系统和执行系统彻底解耦——推理系统产生意图，独立的验证器检查意图后才允许执行。OpenParallax参考实现在280个对抗性测试用例中，默认配置下拦截98.9%的攻击（零误报），最高安全配置下拦截100%。

Sovereign Agentic Loops提出模型发出结构化intent并附理由，控制平面在对比真实系统状态和策略后才允许执行，在云基础设施原型中拦截93%的不安全意图于策略层，剩余7%通过一致性检查拒绝。

RSAC 2026上Infotech的分析师指出一个残酷事实：85%的企业在实验AI Agent，只有5%敢把它们投入生产——阻碍因素不是技术，是治理。

所有这些架构和数据的底层逻辑完全一致：AI Agent安全的核心问题不是模型有多强，而是模型和真实世界之间有没有一道可靠的验证屏障。Foundry Security Spec正是这道屏障的标准化蓝图。

七、写在最后：安全评估的范式拐点

Cisco这次开源，表面上是发布了一套Agent规范，更深层的信号是整个AI安全产业正经历一次根本性的范式转移。

过去两年，安全行业把几乎所有注意力都放在了模型能力上。GPT-5.5-Cyber能不能独立完成渗透测试？Claude Mythos能不能自主挖0day？但Cisco用Foundry清楚表达了另一个观点：模型能力再强，如果没有验证闭环，输出就是不可信的。Santos的论断最为直接：“一个完整的智能体系统是那种混乱的解毒剂。”

从商业模式和技术演进的角度看，Foundry的发布标志着AI安全正在从“模型军备竞赛”转向“系统架构竞赛”。下一个阶段的竞争，不再是看谁的模型能挖出更多漏洞，而是看谁的验证流水线能更准确地区分“真正的漏洞”和“模型幻觉”。

Omar Santos最后的话值得每个安全从业者记住：“即使底层的AI系统发生变化，编排、检测和验证这些核心功能仍然需要。无论你用的是当前的大语言模型，还是未来的推理智能体。”

Cisco把内部安全团队的工程经验变成了一套公共品。如果你正在思考怎么把AI嵌入安全测试流程，Foundry Security Spec不一定是唯一的答案，但它一定是一个值得认真研究的起点。

而那个更关键的问题——你的AI挖出来的漏洞，你敢信吗——Foundry给出了一个工程上可验证的回答：别信模型，信验证闭环。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：昆仑AI安全实验室 逍遥 逍遥《别迷信模型了：Cisco开源Foundry Security Spec，用8个Agent角色+11条铁律告诉你——AI安全测试的核心不是模型，是模型周围的验证闭环》