近年来，AI智能体正以惊人速度从单纯的聊天助手进化为真正能操控操作系统的“数字员工”。这听起来很酷，对吧？然而，随之而来的是传统安全流程难以应对的新风险——提示注入、权限失控、工具滥用，甚至智能体做出意想不到的“越权”行为。问题来了：安全检测，能否不再等到系统上线后才进行？

近日，微软在这一方向上放出大招，开源了两款全新工具——Rampart和Clarity。它们的核心思路非常明确：将AI安全检测从开发流程的后端，大幅前移至最开始的阶段。

微软AI红队创始人Ram Shankar Siva Kumar在博客中直言：“我们开发这些工具，是因为我们坚信AI安全必须成为一项持续的工程学科，而非仅仅是定期检查的节点。实现这一目标的最佳方式，就是将实用的开源工具交到实际构建系统的人手中。”这段话背后的逻辑很简单：安全不应是事后补救，而应贯穿始终的工程实践。

Rampart：将安全测试“嵌入”开发流水线

先看Rampart。从定位上，它更偏向实际操作层面。简单来说，这个框架的作用是帮助开发者把红队发现的问题，转化为可重复执行的测试用例，然后直接嵌入到开发和部署的流水线中持续运行。

Rampart基于微软之前开源的自动化红队框架PyRIT构建。但请注意，两者的思路完全不同——PyRIT解决的是系统构建完成后，由安全研究人员进行黑盒发现；而Rampart则是为工程师在系统构建过程中设计的。这才是关键所在：工程师在构建系统时就能使用它。

具体而言，Rampart能够在应用上线之前，发现包括跨提示注入、不安全数据处理、不安全工具执行等一系列智能体特有的攻击路径。更重要的是，它支持将AI红队的发现转化为可重复的自动化测试，帮助工程师在智能体迭代过程中持续检测回归问题。这相当于为开发流程装上了一个安全“筛子”，随时过滤，而不是等到最后才来一次大扫除。

Clarity：在代码未动之前，先理清安全问题

如果说Rampart聚焦于系统构建阶段的测试，那么Clarity的介入时间则更早——早在代码编写开始之前。

微软将Clarity定位为一款用于审查和验证AI智能体设计决策背后假设前提的工具。通俗地说：在动手敲代码之前，先用它把智能体的预期行为、权限范围、与外部工具的交互方式以及信任边界全部过一遍。这听起来像设计评审，但Clarity做得更系统化、结构化。

Kumar介绍，Clarity可以以桌面应用、网页界面，甚至直接嵌入编码智能体的形式运行。它通过结构化对话，引导工程师完成问题梳理、方案探索、故障分析和决策追踪等环节。有意思的是，这些对话内容会以Markdown文件形式写入代码仓库中的“.clarity-protocol/”目录，像源代码一样提交，可以在Pull Request中审查和进行差异比较。换句话说，安全决策本身也成了可版本控制的资产。

必须指出，Rampart和Clarity并非孤立的产品。它们是微软过去数月来持续构建开源“智能体治理”与安全技术栈的一部分。就在上月，微软已经推出了智能体治理工具包，重点覆盖常规控制、策略执行以及针对AI智能体的OWASP对齐防护能力。所以，你可以将这看作一套组合拳——不是单点解决问题，而是从架构层面系统性地提升智能体安全。

Q&A

Q1：Rampart是什么？它与PyRIT有什么区别？

A：Rampart是微软开源的AI智能体安全测试框架，基于PyRIT构建。两者核心区别在于：PyRIT面向安全研究人员，用于系统构建完成后的黑盒发现；而Rampart面向工程师，在系统构建过程中使用，支持将红队发现转化为可重复的自动化测试，并集成到CI/CD流水线中，实现持续安全检测。

Q2：Clarity工具的主要作用是什么？

A：Clarity是一款在代码编写之前介入的AI安全工具，用于审查和验证AI智能体设计决策背后的假设前提，包括智能体的预期行为、权限范围、与外部系统的交互方式及信任边界。它可以桌面应用、网页界面或嵌入编码智能体等多种形式运行，通过结构化对话引导工程师进行问题梳理与决策追踪，并将结果以Markdown文件形式保存在代码仓库中。

Q3：微软开源智能体安全工具是出于什么考虑？

A：随着AI智能体从聊天助手演变为拥有实际操作权限的系统，传统应用安全流程已无法有效应对提示注入、权限升级、不安全工具调用等新型风险。微软希望通过开源Rampart和Clarity，推动AI安全从定期审查转变为持续的工程学科，并将实用工具直接交给开发者，使安全检测贯穿整个智能体开发生命周期。