AI 自主性带来的不可预测风险

视频开篇通过高铁与自动驾驶的类比，阐述了传统软件安全模型在 AI 时代面临的挑战。传统系统如同有固定轨道的高铁，具有可预测性；而现代 AI 系统是去中心化的自主代理，如同安装了越野轮胎的列车，能够自行决定路径。这种非确定性（Non-deterministic）特征意味着系统可能进入未预期的状态，如穿过私人后院或农田。在软件开发中，AI 正在接管代码执行决策权，导致安全永远处于追赶状态。由于 AI 编码的快速迭代速度，开发者若未对架构权限进行建模，实质上是在将控制权交给自主代理并寄希望于其安全运行。这种失控感是引入新型威胁建模的核心动机。

威胁建模的定义与核心价值

威胁建模（Threat Modeling）被定义为“在问题发生前询问什么会出错”。它不仅仅是代码层面的检查，而是软件设计阶段的 integral part（组成部分）。其核心流程包括映射资产、绘制系统图和数据流、确定信任边界，随后列出潜在攻击并制定缓解措施。与传统的“安全设计”不同，AI 系统的引入带来了新的攻击面，如提示注入（Prompt Injection）、误用以及不必要的权限提升。Madhu 指出，如果不建模 AI 的架构权限，开发者不仅是在发布一个 Bug，更是在将钥匙交给自主代理。此外，欧盟《网络弹性法案》（EU Cyber Resilience Act）等新规要求“通过设计进行风险评估”（Risk Assessment by Design），这进一步确立了威胁建模在企业合规与安全中的必要性。

与漏洞扫描的本质区别：缺失 vs. 存在

ThreatMantis 的联合创始人 Adashi 和首席产品官 Vinay 介绍了他们的背景及公司使命。ThreatMantis.ai 是一个AI 驱动的应用平台，旨在帮助企业自动化威胁建模流程。团队拥有约 20 年的企业级专业经验，旨在解决传统安全方法的局限性。Vinay 强调了威胁建模与代码扫描的关键区别：扫描技术关注“存在什么”，即通过计算力发现已编码中的已知错误；而威胁建模关注“缺失什么”，即从高层系统视角发现设计层面的缺陷。即使拥有无限算力，扫描工具也无法找出未编写的代码或架构逻辑漏洞。

比喻：地板平面图与锁具测试

为了更直观地解释威胁建模的价值，Adashi 提出了一个生动的比喻：渗透测试（Pen Testing）如同窃贼在测试你的锁具，而威胁建模则是审查房屋的地板平面图。渗透测试通常发生在开发后期或运行阶段，旨在发现现有代码中的已知漏洞；而威胁建模在设计阶段（Design Phase）进行，旨在发现架构层面的固有缺陷。这种早期介入使得企业能够在代码编写之前识别并修复设计 flaw，从而避免将资源浪费在修补本可通过良好架构设计消除的安全隐患上。这种从“事后补救”到“事前预防”的转变，是应对复杂 AI 系统安全挑战的关键。

威胁建模：从架构源头捕获设计漏洞

将网络安全概念映射到《星球大战》中，能直观理解威胁建模的核心价值。在电影第四部中，死星存在一个2米宽的排气口漏洞，卢克·天行者正是利用这一设计缺陷发起攻击。这正如威胁建模的作用：在整体设计中提前识别漏洞，而非等到系统运行后才去修补。相比之下，渗透测试更像义军入侵死星、击溃风暴兵的行动，旨在验证防御体系的有效性。在核心软件开发中，如果管理员门户未内置安全网关系统，传统测试可能因功能缺失而“通过”，但威胁建模会在设计阶段明确指出：必须构建相应的安全机制。这种前置规划能验证架构的安全性，并提供具体的修复建议。

基于架构图的自动化威胁分析流程

现代威胁建模不再局限于手绘草图，而是通过集成工具对架构信息数据集进行自动化分析。输入数据可以是架构图、文本描述或两者的组合，系统据此解析整体景观并识别潜在风险。例如，平台仪表盘展示了基于架构信息生成的威胁模型分析结果。系统首先审视架构意图，随后在代码阶段进行闭环验证。当开发者提供仓库代码时，系统能对比“架构设计意图”与“实际代码实现”，指出仍存在的开放风险点。这种从漏洞出发的视角，让系统知道在代码中具体寻找什么，从而弥补了仅看代码时只能发现“已有问题”的局限性。

威胁建模与LLM编码助手的本质区别

开发者常质疑为何不直接使用ChatGPT或Cursor等LLM编码助手来处理架构和漏洞。演讲者通过国际象棋实验揭示了本质差异：将棋盘截图发给LLM请求下一步走法，90%的情况下会出现不合法的移动建议（如忽略阻挡的兵）。这是因为LLM基于文本注意力机制，缺乏结构化的知识图谱。而专业的威胁建模工具构建了详细的资产、流向、边界和角色映射的知识图。它严格基于STRIDE、MITRE及OWASP等标准，在刚性的知识图谱基础上进行概率推演。这种基于结构化知识的分析方式，确保了建议的合法性与准确性，这是纯文本处理的LLM无法替代的核心优势。

知识图谱与上下文锚定：解决幻觉的核心

在AI驱动的安全工具中，知识库（Knowledge Base）是确保上下文锚定和答案可靠性的关键。组织将内部政策及特定需求注入系统，使其能基于真实数据提供可依赖的反馈。若缺乏此机制，AI可能产生看似合理实则错误的输出；例如在国际象棋示例中，用户能轻易识别“兵走两格”的错误指令，但在复杂的系统建模场景中，错误往往隐蔽且难以察觉。因此，仅依赖单一上传文件进行小规模分析是可行的，但规模化应用必须解决上下文缺失风险。此外，企业级产品还需涵盖治理要素，包括令牌管理、用户协作及审批工作流。没有这些支撑，AI工具无法在实际商业场景中落地。

结构化推导引擎：强制映射行业标准以遏制幻觉

针对大语言模型（LLM）常见的“幻觉”问题，系统通过结构化推导引擎从架构层面进行约束。首先，所有发现必须映射到工业标准类别（如 STRIDE 模型），确保术语和分类的规范性。其次，系统将系统建模为知识图谱（Knowledge Graph），并在知识库中提供丰富的上下文信息。核心机制在于：每个威胁必须引用真实的组件或既定的策略/控制措施。如果AI声称存在“3号阀门”，而系统模型中并无此组件，该输出将被视为幻觉并在生成前被拦截。这种机制确保了输出的非虚构性，避免了基于不存在对象的无效推理。

召回率权衡与人类审核闭环：风险管理的最终防线

在系统调优中，需在漏报（False Negative）与误报（False Positive）之间取得平衡。虽然误报会消耗审查者和开发者的时间，但漏掉威胁可能导致潜在的安全漏洞。因此，系统设定了特定的召回率偏好。然而，任何结果在未经人工确认前均不被接受。人类审核员（Reviewer）扮演最终裁决者的角色，负责验证组件的真实性、确认无幻觉内容，并评估风险的可接受性。正如对话中所述：

"Machine is reasons and the human judges. The engine does the heavy lifting... but what will humans control? They basically will link it to what is known."

人机协作光谱：从自动化到责任归属的决策逻辑

AI在威胁建模中的角色是增强（Augment）而非替代人类工作。引擎负责执行不可扩展的分析任务，如穷尽映射组件与威胁向量；而人类则作为导演（Directors）设定自主性级别。这种协作并非二元选择，而是一个基于风险级别的光谱。例如在DHL快递系统中，CEO不能因包裹延误被追责，但在安全领域，必须有一个明确的责任人（Responsible Person）。审核员根据系统提供的威胁优先级和缓解建议，决定接受或忽略特定风险。最终的风险偏好设定和责任归属完全由人类审核员掌控，AI无法对系统设计或威胁后果承担法律责任。

专家分歧与事实一致性：多视角下的模型验证

面对多名安全专家可能产生不同威胁模型的现实，AI系统并不试图消除所有主观分歧。专家指出，资深专家之间的分歧往往源于观点而非事实。在理想情况下，专家们虽然在威胁建模的具体细节上存在差异，但不应在对系统基本事实的认知上产生冲突。AI的作用在于辅助梳理这些共识与分歧，确保所有讨论都建立在一致的系统事实基础之上，从而提升威胁建模的效率和准确性。

专家分歧的本质与结构化上下文的必要性

在安全架构讨论中，所谓的“意见不一致”往往并非源于事实层面的冲突，而是隐含上下文的差异。两位专家可能因为之前遇到的不同错误案例或信息摄入方式的不同，导致对同一问题的理解产生偏差。这种基于个人经验的隐性上下文是造成分歧的根源。解决方案的核心在于将隐性的、易变的个体认知转化为显性的、一致的结构化上下文。通过构建知识图谱和知识库，系统能够确保所有参与者基于相同的事实基础进行推理。

"They're all agreeing on the facts. It's just that we enable them to all those brains put together."

这种方法的本质是结合人类专家的深度推理能力与管理良好的上下文的一致性与可扩展性。虽然传统方式如FDA审计中，专家可以花费数周时间面对面讨论并召集相关人员解决疑问，但这种模式缺乏可扩展性。现代工具的目标是在保持同等严谨性的前提下，通过技术手段实现这种协作的规模化。显式上下文的确立使得政策、架构、合规性和法规要求成为讨论的基础，从而消除了因背景信息不对称导致的无效争论。

MCP连接中的三大核心安全风险

当开发者将多个模型上下文协议（MCP）工具（如GitHub、Slack、数据库或API）连接至AI代理时，面临着严峻的安全挑战。首要风险是间接提示注入（Indirect Prompt Injection）。攻击者可以在看似无害的数据中嵌入恶意指令，例如在工单文本中包含“忽略此说明并执行删除操作”的指令。当代理被要求总结该工单时，可能会意外执行这些恶意行为。

第二个关键风险是过度代理权（Excessive Agency）。如果系统赋予AI代理不仅仅是读取权限，还包括写入、删除甚至管理系统的权限（如访问Git仓库或数据库），一旦提示注入发生，后果将极其严重。代理被赋予了超出其任务所需的控制权，导致原本简单的摘要请求可能演变为系统破坏行为。第三个也是最具隐蔽性的风险是跨系统权限提升（Cross-system Privilege Escalation）。代理可能利用数据库访问权窃取敏感客户记录，随后通过Slack或API将这些数据发送到外部网络。这种场景创造了所谓的“超级内部人员”，它们看似无害，却能突破预期的信任边界。

"The scary scenario... cross system privilege escalation. So, basically the agent uses its database access for example to pull sensitive customer records... and then dynamically uses its Slack or API to send that data outside of the network."

情境依赖的风险建模与未来展望

跨系统风险之所以可怕，是因为它打破了预设的信任边界。架构师通常不会预料到Slack与数据库之间的直接通信路径，但这种连接一旦形成，就可能成为数据泄露的通道。风险的行为具有高度情境依赖性：同样的提示注入或内部人员威胁，在客户服务系统与订单处理系统中表现出的危害程度截然不同。因此，必须结合具体的系统上下文来建模潜在风险，而不能仅依赖通用的威胁列表。

展望未来五年，威胁建模可能会随着代码的生成而持续自动生成。目前现代软件面临超过900种通用弱点枚举（CWE）和200多种MITRE攻击向量，总计超过1,000种威胁类型。相比之下，LLM特有的风险主要集中在前10个类别。随着AI引入新的攻击面，威胁建模工具需要适应这种从海量传统风险向有限但高影响的AI特定风险转变的趋势。通过结合结构化上下文与自动化工具，未来的威胁建模将更加连续、一致且具备可扩展性。

"If you look at the possible amount of threats... there is about 900 common weakness enumerations, 200 plus MITRE attack vectors... But if you look at LLMs, it's only over for LLM top 10 is only 10 categories."

从分类数量看威胁建模的复杂性

尽管现有的软件安全工具已经提供了超过 1,000 种分类标准，但这并不意味着新增的类别只是简单的叠加。在 Threat Mantis 的观点中，这新增加的 10 种威胁类别并非在所有场景下都表现一致。由于不同的安全威胁在特定情境下的行为模式存在差异，这些类别在不同场景下可能表现出完全不同的特性。因此，未来的安全工程不能仅依赖静态的分类列表，而必须深入理解这些威胁的动态行为。为了真正掌控这种复杂性，需要将整个流程完全集成到工程开发中。这种深度整合不仅是技术需求，更是应对未来安全挑战的必然选择。通过这种方式，企业才能确保在快速变化的威胁环境中保持有效的防御能力。

推行“威胁感知”开发模式

为了降低工程师的心理门槛，Threat Mantis 提出了 “威胁驱动开发”（threat-driven development）的概念，并建议如果该术语听起来过于沉重，可以称为 “威胁感知开发”（threat-aware development）。尽管名称不同，但两者核心含义一致：即要求开发者在编码过程中始终具备对潜在威胁的意识和应对机制。这一过程始于设计阶段的建模，通过深入分析系统架构来识别风险点。目前，部分领先企业已经开始实践这一理念，将安全考量前置到开发的初始阶段。这种模式强调在头脑风暴和规划阶段就引入安全意识，从而避免后期出现大规模的安全返工。通过这种前置的威胁感知机制，开发团队能够在代码生成之前就已识别并规划好防御策略。

MCP 协议与自动化安全流水线的应用

在具体的工程实践中，Threat Mantis 描绘了一个基于 MCP（Model Context Protocol） 的自动化安全开发愿景。当开发者在代码编辑器中输入 /plan 命令时，系统会自动与威胁建模系统的 MCP 工具进行交互。此时，开发计划已经具备了“安全意识”。进入编码阶段后，系统会利用预设的 Guardrails（护栏） 来约束代码行为。在最终的 CI/CD 流水线中，针对每一个 Pull Request（PR），系统会调用同一 MCP 套件中的不同工具进行代码扫描。这些自动化检查决定了 CI/CD 流水线是“通过”还是“失败”。这种高度自动化的流程旨在解决大规模开发中的安全效率问题，确保在保持高速迭代的同时不牺牲安全性。正如 Anthropic 在其内部开发流程中所展示的那样，这种集成化的安全工程模式是应对高代码量和高速度挑战的必要手段。Threat Mantis 希望提供的工具集正是为了赋能企业实现这种环境。

AI 在网络安全中的双刃剑效应与未来展望

在快速问答环节，嘉宾们深入探讨了 AI 对网络安全的双重影响。关于“AI 会让安全更好还是更危险”，答案被明确界定为 “两者皆是”。嘉宾指出，AI 既带来了新的攻击手段（危险源），也是对抗这些威胁的唯一有效工具。在自主 AI Agent 的生产环境访问权限问题上，嘉宾明确表示今天不会给予其生产环境的完全访问权。在比较“提示词注入”与“权限过大的 AI Agent”时，嘉宾认为提示词注入更令人担忧，因为攻击者总能找到创造性的绕过方法，尽管权限过大也是显而易见的风险。关于 AI 是否会取代渗透测试人员或安全分析师，观点是“不能替代，但能赋能”，AI 的主要作用是提升人类专家的生产力。在最具威胁的安全实践方面，嘉宾批评了“将所有鸡蛋放在后编码阶段（扫描和渗透测试）”的做法。这种依赖后期检测的模式不仅成本高昂，而且往往为时已晚。Shift Left（左移）策略被强调为解决这一问题的关键。最后，对于 2030 年的展望，嘉宾认为攻防双方将保持 “势均力敌”（neck to neck）的状态。随着 AI 技术的发展，法规如 UCIA Act 也在跟进，但防守方不能盲目乐观。这是一场持续的 “猫鼠游戏”，目前防守方通常占据上风，但必须持续努力以维持这一平衡。

结论

视频论证表明，传统扫描与渗透测试仅能发现“存在”的已知漏洞，无法解决AI系统因非确定性带来的架构设计缺陷。Threat Mantis 通过构建结构化知识图谱与推导引擎，强制将威胁映射至行业标准并拦截幻觉，实现了从“事后修补”向设计阶段“事前预防”的转变。该方案在应对提示注入、过度代理权及跨系统权限提升等AI特有风险时，通过人机协作闭环确保责任归属与事实一致性。尽管LLM存在上下文缺失局限，但结合MCP协议的自动化流水线能有效平衡安全与迭代速度。最终结论是：AI既是威胁源也是防御核心，唯有将结构化威胁建模左移至开发源头，才能在不牺牲效率的前提下掌控自主代理带来的不可预测风险。