把 AI 安全前移到开发流程

传统软件安全测试往往在开发后期进行。但 AI Agent 的行为复杂且可能不断变化，如果只在发布前检查一次，很容易遗漏问题。

微软提出的思路是：让安全成为工程流程的一部分。

在这种模式下：

• 设计阶段使用 Clarity 识别潜在风险
• 开发阶段用 RAMPART 自动化测试这些风险
• 任何发现的漏洞都会转化为长期回归测试

这样安全测试就不再是一次性的审核，而是持续运行的工程机制。

RAMPART：为 AI Agent 提供持续对抗测试

RAMPART（Risk Assessment and Measurement Platform for Agentic Red Teaming） 是一个专门针对 AI Agent 的测试框架，用来把正常场景和攻击场景都写成可重复运行的测试。

与 pytest 深度集成

RAMPART 采用 pytest‑native 设计，这意味着工程师可以像写普通 Python 单元测试一样编写 AI Agent 的安全测试。

这些测试可以直接加入企业常见的 CI/CD 流水线，与应用测试一起自动执行。

好处是：

• 工程团队无需学习新的测试体系
• 安全测试可以随代码变更自动运行

将攻击场景写成测试用例

RAMPART 的核心能力之一是把潜在攻击模拟为测试场景，例如：

• 提示注入攻击（诱导模型忽略原始指令）
• 试图绕过安全策略的请求
• 危险工具调用（如执行恶意 shell 命令）
• 数据外泄尝试（访问或发送敏感信息）

开发者可以为每种场景编写测试，检查 AI Agent 是否拒绝请求或安全处理输入。

把红队发现变成回归测试

安全团队或红队测试中发现的漏洞，通常只是一次性的报告。RAMPART 的设计目标之一，就是把这些发现 永久化为自动化回归测试。

例如：

• 如果发现某个提示注入能绕过防护
• 就可以把该攻击写成测试
• 以后每次构建都会自动检测是否再次出现

这样漏洞不会在未来的代码更新中悄悄复现。

处理 AI 的“概率性行为”

与传统软件不同，AI Agent 的输出具有一定随机性。

一次测试通过并不意味着系统永远安全。

RAMPART 的做法是 反复执行高风险场景测试，观察行为在多次运行和多个版本中的变化，从而更早发现安全退化或回归问题。

在 CI/CD 中自动拦截风险

当 RAMPART 集成到持续集成系统后，企业可以对以下变化设置自动安全门控：

• Prompt 或系统指令修改
• 模型版本更新
• 新接入工具或 API
• 新增数据源或检索系统
• 安全策略变更

如果某次改动导致测试失败，构建可以在部署前被自动阻止。

Clarity：在写代码前就讨论安全

如果说 RAMPART 是测试工具，那么 Clarity 更像是一个结构化的设计讨论框架。

微软把它描述为一个 “设计决策的结构化思考工具（structured sounding board）”。

它会引导团队在开发前思考一系列关键问题，例如：

• 这个 Agent 应该做什么任务？
• 哪些任务必须 明确拒绝？
• 它需要访问哪些工具或权限？
• 哪些滥用或攻击场景是合理可能的？
• 在上线前需要哪些保护措施和测试？

这些问题能帮助团队在早期就暴露潜在风险，而不是在系统上线后才发现设计漏洞。

用于事故复盘与系统改进

Clarity 不只用于前期规划，也适用于 事故后的复盘分析。

例如：

• RAMPART 测试失败
• 或 AI Agent 在生产环境出现异常行为

团队可以回到 Clarity 框架重新审视设计假设：

• 是否遗漏了某些风险？
• 哪些安全控制没有设计？
• 是否需要新增测试场景？

随后，这些新发现又可以转化为 新的 RAMPART 回归测试，不断强化系统安全。

为什么这对企业 AI 很重要

在企业环境中，AI Agent 往往拥有广泛能力，例如：

• 读取内部文档
• 调用业务 API
• 执行自动化脚本
• 与员工或客户交互

如果遭遇提示注入或工具滥用，可能带来真实的业务或安全风险。

通过 Clarity（设计阶段风险分析） + RAMPART（持续对抗测试） 的组合，微软试图推动一种新的开发模式：

把 AI 安全变成持续工程实践，而不是上线前的一次性审核。

在 AI Agent 越来越自主的背景下，将安全思维直接嵌入开发流程，很可能成为未来企业 AI 系统构建的核心方法之一。

把 AI 安全前移到开发流程

传统软件安全测试往往在开发后期进行。但 AI Agent 的行为复杂且可能不断变化，如果只在发布前检查一次，很容易遗漏问题。

微软提出的思路是：让安全成为工程流程的一部分。

在这种模式下：

• 设计阶段使用 Clarity 识别潜在风险
• 开发阶段用 RAMPART 自动化测试这些风险
• 任何发现的漏洞都会转化为长期回归测试

这样安全测试就不再是一次性的审核，而是持续运行的工程机制。

RAMPART：为 AI Agent 提供持续对抗测试

RAMPART（Risk Assessment and Measurement Platform for Agentic Red Teaming） 是一个专门针对 AI Agent 的测试框架，用来把正常场景和攻击场景都写成可重复运行的测试。

与 pytest 深度集成

RAMPART 采用 pytest‑native 设计，这意味着工程师可以像写普通 Python 单元测试一样编写 AI Agent 的安全测试。

这些测试可以直接加入企业常见的 CI/CD 流水线，与应用测试一起自动执行。

好处是：

• 工程团队无需学习新的测试体系
• 安全测试可以随代码变更自动运行

将攻击场景写成测试用例

RAMPART 的核心能力之一是把潜在攻击模拟为测试场景，例如：

• 提示注入攻击（诱导模型忽略原始指令）
• 试图绕过安全策略的请求
• 危险工具调用（如执行恶意 shell 命令）
• 数据外泄尝试（访问或发送敏感信息）

开发者可以为每种场景编写测试，检查 AI Agent 是否拒绝请求或安全处理输入。

把红队发现变成回归测试

安全团队或红队测试中发现的漏洞，通常只是一次性的报告。RAMPART 的设计目标之一，就是把这些发现 永久化为自动化回归测试。

例如：

• 如果发现某个提示注入能绕过防护
• 就可以把该攻击写成测试
• 以后每次构建都会自动检测是否再次出现

这样漏洞不会在未来的代码更新中悄悄复现。

处理 AI 的“概率性行为”

与传统软件不同，AI Agent 的输出具有一定随机性。

一次测试通过并不意味着系统永远安全。

RAMPART 的做法是 反复执行高风险场景测试，观察行为在多次运行和多个版本中的变化，从而更早发现安全退化或回归问题。

在 CI/CD 中自动拦截风险

当 RAMPART 集成到持续集成系统后，企业可以对以下变化设置自动安全门控：

• Prompt 或系统指令修改
• 模型版本更新
• 新接入工具或 API
• 新增数据源或检索系统
• 安全策略变更

如果某次改动导致测试失败，构建可以在部署前被自动阻止。

Clarity：在写代码前就讨论安全

如果说 RAMPART 是测试工具，那么 Clarity 更像是一个结构化的设计讨论框架。

微软把它描述为一个 “设计决策的结构化思考工具（structured sounding board）”。

它会引导团队在开发前思考一系列关键问题，例如：

• 这个 Agent 应该做什么任务？
• 哪些任务必须 明确拒绝？
• 它需要访问哪些工具或权限？
• 哪些滥用或攻击场景是合理可能的？
• 在上线前需要哪些保护措施和测试？

这些问题能帮助团队在早期就暴露潜在风险，而不是在系统上线后才发现设计漏洞。

用于事故复盘与系统改进

Clarity 不只用于前期规划，也适用于 事故后的复盘分析。

例如：

• RAMPART 测试失败
• 或 AI Agent 在生产环境出现异常行为

团队可以回到 Clarity 框架重新审视设计假设：

• 是否遗漏了某些风险？
• 哪些安全控制没有设计？
• 是否需要新增测试场景？

随后，这些新发现又可以转化为 新的 RAMPART 回归测试，不断强化系统安全。

为什么这对企业 AI 很重要

在企业环境中，AI Agent 往往拥有广泛能力，例如：

• 读取内部文档
• 调用业务 API
• 执行自动化脚本
• 与员工或客户交互

如果遭遇提示注入或工具滥用，可能带来真实的业务或安全风险。

通过 Clarity（设计阶段风险分析） + RAMPART（持续对抗测试） 的组合，微软试图推动一种新的开发模式：

把 AI 安全变成持续工程实践，而不是上线前的一次性审核。

在 AI Agent 越来越自主的背景下，将安全思维直接嵌入开发流程，很可能成为未来企业 AI 系统构建的核心方法之一。