为生成式 AI 应用构建安全防线：generative-ai-for-beginners 第 13 课「保护你的 AI 应用」深度解读

本篇指南基于 generative-ai-for-beginners 课程的第 13 课 13-securing-ai-applications/README.md（含孟加拉语等 40 余种语言的译本）展开，系统讲解生成式 AI 语境下"安全"的含义、AI 系统面临的典型威胁（尤其是数据投毒）、面向 AI 系统与 LLM 的安全测试方法、数据保护实践，以及 AI 红队（Red Teaming）的运作方式。读完本文，你不仅能掌握 AI 安全的威胁模型与防御框架，还能从本仓库的共享工具代码（shared/python/ 下的输入校验、密钥管理与安全请求封装）中看到这些安全理念在真实工程代码中的落地方式。

课程定位与学习目标

第 13 课在 21 课体系中承担"安全"这一关键主题，核心覆盖三块内容：

• AI 系统语境下的安全（Security in the context of AI systems）；
• AI 系统常见的风险与威胁；
• 保护 AI 系统的方法与工程考量。

完成本课后，应能理解：AI 系统面临的威胁与风险；保护 AI 系统的通用方法与最佳实践；以及安全测试如何防止意外结果、避免侵蚀用户信任。

生成式 AI 语境下的"安全"意味着什么

随着 AI 与机器学习技术日益深入生活，保护的对象不再只是客户数据，AI 系统本身也必须被保护。AI/ML 正越来越多地支撑高价值决策流程（金融、医疗、司法等），错误决策可能带来严重后果。原文档归纳了三个必须考虑的关键点：

• AI/ML 的影响：AI/ML 对日常生活影响深远，因此守护其安全成为必需品；
• 安全挑战：基于 AI 的产品必须防范来自"网络恶徒（trolls）"乃至有组织群体的复杂攻击；
• 战略性问题：技术产业必须主动应对战略层面的挑战，才能保障长期的客户安全与数据安全。

更隐蔽的一点在于：机器学习模型通常无法区分恶意输入与善意的异常数据。训练数据的重要来源是未经筛选、无人审核、允许第三方贡献的公开数据集——攻击者根本不需要"攻陷"数据集，因为他们是数据集的合法贡献者。只要数据结构与格式正确，低置信度的恶意数据会随着时间推移逐渐"沉淀"为高置信度的可信数据。这正是原文档强调"必须确保模型所用数据仓库的完整性与保护"的根本原因。

理解 AI 的威胁与风险：数据投毒居首

在 AI 及相关系统中，数据投毒（Data Poisoning）是当今最突出的安全威胁：有人故意篡改用于训练 AI 的信息，使其学到错误关联、做出错误决策。其成因包括：缺乏标准化的检测与缓解手段，以及对不可信、未筛选公开数据集的依赖。要维持数据完整性、防止训练过程被破坏，必须追踪数据的来源与血缘（lineage），否则"垃圾进，垃圾出"（Garbage In, Garbage Out）的旧话就会应验，模型性能随之受损。

原文档给出了数据投毒影响模型的四种典型手法，每种都配有具体示例：

1. 标签翻转（Label Flipping）：在二分类任务中，攻击者故意翻转训练数据中一小部分样本的标签，使模型学到错误关联。 示例：垃圾邮件过滤器因标签被篡改，把合法邮件误判为垃圾邮件。
2. 特征投毒（Feature Poisoning）：攻击者对训练数据中的特征做细微修改，以引入偏见或误导模型。 示例：在商品描述中塞入无关关键词，操纵推荐系统的输出。
3. 数据注入（Data Injection）：向训练集注入恶意数据以影响模型行为。 示例：伪造用户评论，扭曲情感分析的结果。
4. 后门攻击（Backdoor Attacks）：攻击者在训练数据中植入隐藏模式（后门），模型学会识别该模式并在被触发时表现出恶意行为。 示例：用带后门的图片训练人脸识别系统，使其对特定人物做出错误识别。

行业级威胁知识库：MITRE ATLAS 与 OWASP LLM Top 10

围绕这些威胁，业界已有系统化的"地图"：

• MITRE ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems，AI 系统对抗性威胁态势）：MITRE 公司建立的"战术与技巧"知识库，记录真实攻击中针对 AI 系统的对抗手法。原文档引用了 ATLAS 的官方说明：AI 的引入使现有系统的攻击面超出传统网络攻击范畴，AI 赋能系统中的漏洞数量正在增长；ATLAS 参照 MITRE ATT&CK® 框架构建，其战术、技巧与程序（TTPs）与 ATT&CK 互为补充，帮助安全人员像规划高级威胁演练一样理解和防御新兴 AI 攻击。
• OWASP LLM Top 10：开放 Web 应用安全项目（OWASP）发布的"使用 LLM 的应用中最关键的十大漏洞"清单，除数据投毒外，重点风险还包括：
  • 提示注入（Prompt Injection）：攻击者通过精心构造的输入操纵 LLM，使其偏离预设行为；
  • 供应链漏洞（Supply Chain Vulnerabilities）：构成 LLM 应用的组件与软件（Python 模块、外部数据集等）本身可能被污染，导致意外结果、引入偏见，甚至危及底层基础设施；
  • 过度依赖（Overreliance）：LLM 会犯错、会"幻觉"，输出不准确或不安全的结果；已有多个记录在案的案例中，人们直接采信了输出，造成现实世界的负面后果。

此外，原文档还推荐了微软云布道师 Rod Trent 撰写的免费电子书 Must Learn AI Security，该书深入剖析了这些新兴 AI 威胁并给出应对指导（可按书名列名检索获取）。

AI 系统与 LLM 的安全测试

AI 正重塑各行各业，但同时也带来数据隐私、偏见、可解释性缺失与被滥用等风险。因此必须确保 AI 系统是安全且负责任的——遵循伦理与法律标准，并能被用户和利益相关方信任。安全测试即评估 AI 系统或 LLM 安全性、识别并实际利用其漏洞的过程，可由开发者、用户或第三方审计者执行。原文档列出了四种最常见的安全测试方法：

方法	过程	价值
数据消毒（Data sanitization）	从训练数据或输入中移除/匿名化敏感与私人信息	降低机密或个人数据暴露面，防止数据泄露与恶意操纵
对抗性测试（Adversarial testing）	生成并施加对抗样本到输入/输出，评估鲁棒性与韧性	识别攻击者可利用的弱点并加以缓解
模型验证（Model verification）	核验模型参数或架构的正确性与完整性	通过保护与认证模型来检测并防止模型窃取
输出验证（Output validation）	核验输出的质量与可靠性	确保输出一致、准确，检测并纠正恶意操纵

来自 OpenAI 红队网络的"安全评估"样例

OpenAI 在其红队网络（red teaming network）计划中建立了一系列 safety evaluations（安全评估），目标是测试 AI 系统的输出、贡献于 AI 安全。原文档指出评估可以是从简单问答到复杂模拟的多种形态，并给出两组具体例子：

说服（Persuasion）类：

• MakeMeSay：一个 AI 系统能否诱使另一个 AI 系统说出某个秘密词？
• MakeMePay：一个 AI 系统能否说服另一个 AI 系统捐出金钱？
• Ballot Proposal：一个 AI 系统能否影响另一个 AI 系统对某政治提案的支持？

隐写（Steganography，隐藏消息）类：

• Steganography：AI 系统能否在不被另一 AI 系统察觉的情况下传递秘密消息？
• Text Compression：AI 系统能否压缩与解压消息，从而为隐藏秘密消息创造条件？
• Schelling Point：在没有直接通信的情况下，AI 系统能否与另一 AI 系统达成协调？

这类评估的价值在于：它们把"AI 与 AI 之间"的新攻击面（跨系统诱导、隐写通信）变成了可测量、可复现的测试项目，而不是停留在概念讨论。

AI 安全的五大目标与双重性

原文档强调，保护 AI 系统免受恶意攻击、滥用或意外后果是当务之急，具体包括：

• 保护用于训练和运行 AI 模型的数据与算法；
• 防止对 AI 系统的未授权访问、操纵或破坏；
• 检测并缓解 AI 系统中的偏见、歧视与伦理问题；
• 确保 AI 决策与行动的可问责性、透明度与可解释性；
• 让 AI 系统的目标与价值观符合人类社会。

AI 安全对于保障 AI 系统与数据的完整性、可用性与机密性至关重要，且具有一体两面的特征：

• 机遇：将 AI 纳入网络安全战略本身——AI 能提升威胁识别与响应速度，自动化钓鱼、恶意软件、勒索软件的检测与缓解；
• 挑战：AI 同样会被对手用来发起高级攻击——生成虚假或误导内容、冒充用户、利用 AI 系统的漏洞。因此 AI 开发者承担着独特责任：设计出对滥用具有鲁棒性和韧性的系统。

数据保护：LLM 的数据风险与三道防线

LLM 对其所用数据的隐私与安全构成风险：模型可能记住并泄露训练数据中的敏感信息（人名、地址、密码、信用卡号），也可能被恶意行为者利用其漏洞与偏见进行操纵或攻击。原文档给出应对这些风险的具体步骤：

1. 限制与 LLM 共享的数据数量与类型：只共享对预期目的必要且相关的数据，避免共享敏感、机密或个人数据；用户应对数据匿名化或加密（移除或掩码识别信息、使用安全通信通道）。
2. 核验 LLM 生成的数据：始终检查输出输出的准确性与质量，确保其中不含意外或不适当的信息。
3. 报告与告警任何数据泄露或事件：警惕 LLM 的可疑或异常行为（生成无关、不准确、冒犯性或有害的文本），这可能是数据泄露或安全事件的信号。

在多云环境中，数据安全、治理与合规对任何想发挥数据与 AI 力量的组织都是关键。保护数据需要采纳的通用最佳实践包括：

• 使用提供数据保护与隐私特性的云服务或平台；
• 使用数据质量与校验工具，检查数据中的错误、不一致或异常；
• 使用数据治理与伦理框架，确保数据以负责任、透明的方式使用。

模拟真实威胁：AI 红队（Red Teaming）

模拟真实世界威胁——采用类似工具、战术与程序来识别系统风险并检验防御者响应——如今已成为构建韧性 AI 系统的标准实践。原文档引用了微软 AI 红队的定义演进：

AI 红队的实践已演化出更广义的内涵：它不仅探测安全漏洞，也探测其他系统失效，例如生成潜在有害的内容。AI 系统带来了新的风险，红队对于理解这些新型风险（如提示注入、生成无根据的内容）至关重要。

形成微软 AI 红队计划的三条关键洞察是：

1. AI 红队的广义范围：如今同时覆盖安全与负责任 AI（RAI）两个维度。传统红队聚焦安全侧、把模型当作向量（例如窃取底层模型），但 AI 系统引入了提示注入、投毒等新型漏洞，需要特别关注；安全之外还要探测公平性问题（如刻板印象）与有害内容（如美化暴力）。尽早识别这些问题有助于排定防御投入的优先级。
2. 恶意失效与良性失效并重：红队既考虑恶意视角，也考虑良性视角。例如对新版 Bing 做红队时，不只测试恶意对手如何颠覆系统，也测试普通用户可能遇到哪些有问题或有害的内容。与传统安全红队主要针对恶意行为者不同，AI 红队覆盖更广的角色画像与潜在失效模式。
3. AI 系统的动态性：AI 应用在持续演化，LLM 应用开发者不断适应变化的需求。持续的红队测试保证持续的警觉，并让防御与演化中的风险保持同步。

需要明确的是，AI 红队不是万能的，应作为额外控制手段的补充动作，例如基于角色的访问控制（RBAC）与全面的数据管理方案。它的定位是补充一种安全战略：优先采用安全且负责任的 AI 解决方案，兼顾隐私与安全，同时尽量最小化可能侵蚀用户信任的偏见、有害内容与错误信息。

仓库实证：安全理念在共享工具代码中的落地

本课程的 AGENTS.md 明确课程采用集中式 .env 配置管理（以 .env.copy 为模板）。课程在仓库根目录提供了 shared/python/ 共享工具包，其三个模块恰好把本课"数据消毒、输出验证、机密数据保护"的理念变成了可直接复用、带完整测试的工程实现。

1. 提示注入防御：sanitize_prompt_input

针对 OWASP 风险清单中的提示注入，shared/python/input_validation.py 提供了 sanitize_prompt_input()（第 96–151 行），用于清洗将拼入 LLM 提示的用户输入。其核心防御逻辑（第 123–139 行）分三层：

# 移除空字节与控制字符（保留换行与制表符）
sanitized = re.sub(r"[\x00-\x08\x0b\x0c\x0e-\x1f\x7f]", "", sanitized)

# 移除潜在的模板/注入危险模式
dangerous_patterns = [
    r"\{\{.*?\}\}",  # 模板注入（如 {{system}}）
    r"\${.*?}",      # 变量替换（如 ${danger}）
    r"<script.*?>.*?</script>",  # 脚本标签
    r"javascript:",  # JavaScript 伪协议 URL
]

for pattern in dangerous_patterns:
    sanitized = re.sub(pattern, "", sanitized, flags=re.IGNORECASE | re.DOTALL)

if strict:
    # 严格模式：只允许字母数字、空白与基础标点
    sanitized = re.sub(r"[^\w\s,.\'\"-?!@#$%&*()+=:;]", "", sanitized, flags=re.UNICODE)

从源码结构看，这个函数正是原文档"数据消毒 + 输出验证"两步的组合：先剥离控制字符与注入载体，再做长度上限（默认 1000 字符）与"清洗后为空"的校验，最终归一化空白后返回。

配套的 tests/test_input_validation.py（第 57–87 行的 TestSanitizePromptInput）用测试用例固化了每条防御规则的可验证依据：

def test_removes_template_injection(self):
    result = sanitize_prompt_input("Hello {{system}} world")
    assert "{{" not in result
    assert "}}" not in result

def test_removes_script_tags(self):
    result = sanitize_prompt_input("hi <script>alert(1)</script> there")
    assert "<script" not in result.lower()

同文件还包含 validate_text_input()（长度边界校验）、validate_number_input()（数值范围校验，防止越界参数）与 validate_url()（第 178–204 行，默认 require_https=True，拒绝非 HTTPS 地址）——后者体现了"使用安全通信通道"这一数据保护建议。

2. 机密数据保护：环境变量统一入口

原文档"数据保护"一节强调不要泄露密码等敏感数据。shared/python/env_utils.py 将 API Key 等机密统一收敛到环境变量，提供三个函数：

• get_required_env()（第 11–35 行）：读取必需的环境变量，缺失或为空时抛出带清晰提示的 ValueError，提示去 .env 文件中设置；
• validate_env_vars()（第 38–71 行）：批量校验多个变量，一次性报告所有缺失项（例如 AZURE_OPENAI_ENDPOINT 与 AZURE_OPENAI_API_KEY）；
• get_env_with_default()（第 74–88 行）：读取可选变量并提供默认值。

tests/test_env_utils.py 中的 test_get_required_env_missing_raises、test_get_required_env_empty_raises 等用例验证了"缺失即快速失败"的行为——这与原文档"报告与告警异常"的思路一致：把"机密配置缺失"变成开发期就能暴露的显式错误，而不是静默带病运行。

3. 安全的外部调用：带超时与重试的 HTTP 封装

AI 应用大量依赖外部 API，网络侧的鲁棒性属于"AI 系统韧性"的一部分。shared/python/api_utils.py 提供 make_safe_request()（第 15–53 行）：

def make_safe_request(
    url: str, method: str = "GET", timeout: int = 30, retries: int = 3, **kwargs: Any
) -> requests.Response:
    last_exception: Exception | None = None
    for attempt in range(retries):
        try:
            response = requests.request(method=method, url=url, timeout=timeout, **kwargs)
            response.raise_for_status()
            return response
        except RequestException as e:
            last_exception = e
            if attempt < retries - 1:
                continue  # 预留指数退避位置
            raise

从源码结构看，每个请求都强制超时（默认 30 秒）与最多 3 次重试，避免了无超时的阻塞调用；create_openai_client() 与 create_azure_openai_client()（第 91–144 行）则在构造客户端时强制检查密钥与端点是否存在，缺失即报错，与 env_utils 形成"配置—客户端"两层防线。tests/test_api_utils.py 的 test_retries_then_raises 验证了"重试耗尽后抛出异常"的行为。

这些共享工具与其测试（tests/ 目录，配合 tests/conftest.py 保证仓库根可导入）共同构成了一个可运行的"安全基线样例"：输入消毒、机密管理、安全调用三件事都有代码实现与自动化验证，学习者可以按 AGENTS.md 中的 pytest 步骤在本地直接运行验证。

此外，仓库根目录的 SECURITY.md 遵循微软协调漏洞披露（CVD）流程：发现安全漏洞应通过微软安全响应中心（MSRC）渠道私密报告，而非公开 issue——这本身就是"安全报告流程"在开源项目层面的一个实例。

知识检验与延伸挑战

知识检验：保持数据完整性、防止滥用，一个好的做法是什么？

1. 对数据访问与数据管理实施强力的基于角色的控制；
2. 实施并审计数据标注，防止数据被错误表述或滥用；
3. 确保 AI 基础设施支持内容过滤。

参考答案（对应原文档 A:1）：三条都是很好的建议，但确保为用户分配合适的数据访问权限，会在相当程度上阻止 LLM 所使用数据被操纵或错误表述，是投入产出比最高的一项。

延伸挑战：原文档建议进一步学习"在 AI 时代如何治理与保护敏感信息"（可按课程给出的微软 Purview 培训路径名称检索），把本课的威胁模型与数据治理体系对接起来。

小结

第 13 课的主线可以浓缩为一条因果链：公开数据集开放贡献 → 恶意数据可"洗白"为高置信数据（数据投毒、后门、特征污染）→ 模型输出不可信且可能泄露敏感信息 → 因此需要数据消毒、对抗测试、模型与输出验证、红队演练，并以 RBAC 等访问控制兜底。本仓库的 shared/python/input_validation.py、shared/python/env_utils.py、shared/python/api_utils.py 及 tests/ 测试则是这条主线在代码层面的最小可运行示范。掌握这些内容后，可以继续 14-the-generative-ai-application-lifecycle/README.md 了解生成式 AI 应用生命周期（含 LLM Ops 视角下的安全运营），把本课的安全实践嵌入完整的应用生命周期管理之中。