保护生成式 AI 应用安全generative-ai-for-beginners 第 13 课威胁分析、安全测试与红队实践【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners本课围绕如何为生成式 AI 应用建立安全防线这一核心主题展开面向正在跟随 generative-ai-for-beginners 课程构建 AI 应用的开发者。读完本课你将掌握AI 系统面临的核心威胁数据投毒、提示注入等及其原理、四类主流安全测试方法、数据保护与红队Red Teaming实践以及如何结合本仓库 shared/python 中的安全工具输入验证、环境变量管理、安全 HTTP 封装把安全能力落到真实代码中。生成式 AI 语境下安全意味着什么随着 AI/ML 技术日益塑造日常生活需要保护的不仅是客户数据还包括 AI 系统本身。AI/ML 越来越多地被用于支撑高价值决策过程——在这些行业里一个错误决策可能带来严重后果。以下是需要重点考虑的三点AI/ML 的影响面AI/ML 对日常生活影响显著保护它们已成为刚需安全挑战AI/ML 的普及要求我们保护基于 AI 的产品免受复杂攻击无论是来自网络喷子还是有组织的攻击团体战略性问题科技行业必须主动应对战略级挑战确保客户长期安全与数据安全。一个容易被忽视的底层事实是机器学习模型在很大程度上无法区分恶意输入与良性异常数据。训练数据的重要来源是未经整理、未受监管的公开数据集这些数据集开放给第三方贡献。攻击者无需攻破数据集——只要数据集允许自由贡献他们就能直接参与其中。只要数据的结构与格式保持正确低置信度的恶意数据会随时间推移演变成高置信度的可信数据。因此确保模型用于决策的数据存储的完整性与防护是生成式 AI 安全的第一要务。理解 AI 的威胁与风险数据投毒是头号威胁在 AI 及相关系统语境下数据投毒Data Poisoning是当下最显著的安全威胁。数据投毒指某人故意篡改用于训练 AI 的信息使其犯错。之所以猖獗一方面缺乏标准化的检测与缓解方法另一方面训练严重依赖不受信或未整理的公开数据集。要保持数据完整性、防止训练过程被污染必须追踪数据的来源与谱系lineage否则垃圾进、垃圾出garbage in, garbage out的古老定律就会应验导致模型性能受损。以下是数据投毒影响模型的四类典型方式攻击类型原理实例标签翻转Label Flipping在二分类任务中攻击者故意翻转一小部分训练数据的标签例如把良性样本标为恶意使模型学到错误关联垃圾邮件过滤器因标签被篡改把合法邮件误判为垃圾邮件特征投毒Feature Poisoning攻击者微妙地修改训练数据中的特征引入偏差或误导模型在产品描述中塞入无关关键词操纵推荐系统数据注入Data Injection向训练集中注入恶意数据以影响模型行为注入虚假用户评论扭曲情感分析结果后门攻击Backdoor Attacks攻击者在训练数据中植入隐藏模式后门模型学会识别该模式一旦触发即表现出恶意行为用植入后门的图片训练的刷脸识别系统误识别特定人员行业知识库MITRE ATLAS 与 OWASP LLM Top 10为帮助安全从业者系统化理解这些威胁业内已有两个重要知识库MITRE ATLASAdversarial Threat Landscape for Artificial-Intelligence Systems由 MITRE 公司创建是记录真实世界中针对 AI 系统攻击的战术与技术的知识库。ATLAS 以 MITRE ATTCK® 框架为蓝本建模其战术、技术与过程TTP与 ATTCK 互补。正如传统网络安全中广泛使用 ATTCK 规划高级威胁模拟场景ATLAS 提供了一个易于检索的 TTP 集合帮助理解并准备防御新兴攻击。OWASP LLM Top 10由开放式 Web 应用安全项目OWASP发布列出了使用 LLM 的应用中最关键的十大漏洞。除了上述数据投毒榜单还突出强调了以下威胁提示注入Prompt Injection攻击者通过精心构造的输入操纵大语言模型使其偏离预期行为供应链漏洞Supply Chain Vulnerabilities构成 LLM 所用应用的组件与软件如 Python 模块或外部数据集本身可能被攻陷导致意外结果、引入偏见甚至在底层基础设施中产生漏洞过度依赖OverrelianceLLM 会犯错并容易产生幻觉输出不准确甚至不安全的结果。在多个有据可查的案例中人们直接采信了模型输出导致真实世界中意想不到的负面后果。AI 系统与 LLM 的安全测试方法AI 在带来机会的同时也带来显著挑战与风险如数据隐私、偏见、缺乏可解释性以及潜在滥用。因此确保 AI 系统安全且负责任——即符合伦理与法律标准、能被用户和利益相关者信任——至关重要。安全测试Security Testing就是通过识别并利用 AI 系统或 LLM 的漏洞来评估其安全性的过程。执行者可以是开发者、用户或第三方审计者取决于测试的目的与范围。以下是 AI 系统与 LLM 最常见的四类安全测试方法数据清理Data Sanitization从训练数据或 AI 系统/LLM 的输入中移除或匿名化敏感、私有信息。通过降低机密或个人数据的暴露面防止数据泄露与恶意操纵。对抗测试Adversarial Testing在 AI 系统或 LLM 的输入/输出上生成并施加对抗样本评估其对对抗攻击的鲁棒性与韧性。有助于识别并缓解可能被攻击者利用的脆弱点。模型验证Model Verification校验 AI 系统或 LLM 的模型参数或架构的正确性与完整性。通过确保模型受到保护与认证帮助检测并阻止模型窃取。输出验证Output Validation校验 AI 系统或 LLM 输出的质量与可靠性。通过确保输出一致且准确帮助检测并纠正恶意操纵。作为 AI 系统领域的领先者OpenAI 在其红队网络Red Teaming Network计划中建立了一系列安全评估safety evaluations用于测试 AI 系统的输出为 AI 安全做出贡献。评估范围从简单的问答测试到更复杂的模拟例如说服力PersuasionMakeMeSayAI 系统能多好地诱骗另一个 AI 系统说出秘密单词、MakeMePay能多好地说服另一个 AI 系统捐款、Ballot Proposal能多好地影响另一个 AI 系统对某政治提案的支持隐写术Steganography隐藏消息SteganographyAI 系统能多好地传递秘密消息而不被另一个 AI 系统发现、Text Compression通过压缩/解压消息隐藏秘密、Schelling PointAI 系统能在不直接通信的情况下多好地与其他系统协调。AI 安全AI Security保护 AI 系统免受恶意攻击、滥用或意外后果包括采取步骤确保 AI 系统的安全、可靠与可信赖例如保护用于训练和运行 AI 模型的数据与算法防止对 AI 系统的未授权访问、操纵或破坏检测并缓解 AI 系统中的偏见、歧视或伦理问题确保 AI 决策与行动的可问责性、透明度与可解释性使 AI 系统的目标与价值观同人类和社会的利益保持一致。AI 安全对确保 AI 系统与数据的完整性、可用性和机密性至关重要。它同时带来机会与挑战机会将 AI 纳入网络安全策略AI 在识别威胁和改善响应时间方面可发挥关键作用帮助自动化并增强对钓鱼、恶意软件、勒索软件等网络攻击的检测与缓解挑战AI 也可能被对手用来发起复杂攻击如生成虚假或误导性内容、冒充用户、利用 AI 系统的漏洞。因此AI 开发者有独特责任去设计稳健、能抵抗滥用的系统。数据保护Data ProtectionLLM 可能对其所用数据的隐私与安全构成风险。例如LLM 可能记忆并泄露训练数据中的敏感信息如个人姓名、地址、密码或信用卡号也可能被想利用其漏洞或偏见的恶意行为者操纵或攻击。你可以采取以下步骤保护与 LLM 一起使用的数据限制与 LLM 共享的数据量与类型只共享对预期目的必要且相关的数据避免共享敏感、机密或个人数据对共享数据进行匿名化或加密如移除或掩蔽可识别信息并使用安全的通信渠道验证 LLM 生成的数据始终检查 LLM 输出的准确性与质量确保不含不需要或不恰当的信息报告并告警数据泄露或安全事件警惕 LLM 的任何可疑或异常行为如生成不相关、不准确、冒犯性或有害的文本——这可能是数据泄露或安全事件的征兆。在多云环境中数据安全、治理与合规对任何希望发挥数据与 AI 力量的组织都至关重要。你需要跨多个云、在不同位置保护和治理不同类型的数据结构化、非结构化以及 AI 生成的数据并考虑现有与未来的数据安全、治理及 AI 法规。建议采纳如下最佳实践使用提供数据保护与隐私功能的云服务或平台使用数据质量与验证工具检查错误、不一致或异常使用数据治理与伦理框架确保数据以负责任、透明的方式被使用。模拟真实威胁AI 红队AI Red Teaming模拟真实世界威胁现已被视为构建弹性 AI 系统的标准实践使用类似的工具、战术与过程来识别系统风险并测试防御者的响应。AI 红队实践已经演进出更广泛的含义它不仅包括探查安全漏洞还包括探查其他系统失效例如潜在有害内容的生成。AI 系统带来新风险而红队是理解这些新风险如提示注入、产生无依据内容的核心。—— Microsoft AI Red Team building future of safer AI塑造 Microsoft AI Red Team 计划的三个关键洞见AI 红队范围广泛AI 红队现在同时涵盖安全与负责任 AIRAIResponsible AI两类成果。传统红队聚焦安全层面把模型视为攻击向量例如窃取底层模型而 AI 系统引入的新安全漏洞如提示注入、投毒需要特别关注。除安全之外AI 红队还探查公平性问题如刻板印象与有害内容如美化暴力。尽早识别这些问题可以优先安排防御投资。恶意与良性失效都要考虑AI 红队同时考虑恶意与良性视角的失效。例如在为新版 Bing 做红队时不仅探查恶意对手如何颠覆系统也关注普通用户可能遇到问题或有害内容。不同于主要聚焦恶意行为者的传统安全红队AI 红队涵盖更广泛的角色与潜在失效模式。AI 系统的动态性AI 应用持续演进在 LLM 应用中开发者不断适应变化的需求。持续红队确保对不断变化的风险保持持续警觉与适应。需要明确AI 红队并非包罗万象应被视为对基于角色的访问控制RBAC与全面数据管理方案等额外控制手段的补充。它的目的是补充一套聚焦于部署安全且负责任的 AI 解决方案的安全策略兼顾隐私与安全同时力求减少偏见、有害内容和可能侵蚀用户信心的错误信息。从文档到代码本仓库中的安全实践落地第 13 课的概念在 generative-ai-for-beginners 仓库中并非只停留在理论层面。仓库提供了可复用的安全工具与安全基线文档可以直接支撑本课各项原则的工程化落地。环境变量管理密钥绝不入代码shared/python/env_utils.py 提供了安全获取与校验环境变量的工具get_required_env 在缺失变量时抛出带说明的ValueErrorvalidate_env_vars 可一次校验多个必需变量get_env_with_default 支持带默认值读取。这与仓库安全基线 docs/SECURITY_GUIDELINES.md 的要求一致所有 API Key 必须从环境变量加载并校验严禁硬编码密钥。对应实现可参考各课程的示例应用例如 06-text-generation-apps/python/githubmodels-app.py 从环境变量读取AZURE_INFERENCE_CREDENTIAL与AZURE_INFERENCE_ENDPOINT。输入验证与清洗提示注入的第一道防线针对 OWASP Top 10 中的提示注入威胁shared/python/input_validation.py 提供了专门面向 LLM 提示场景的清洗函数 sanitize_prompt_input去除 NUL 字节与控制字符通过正则移除危险模式模板注入{{...}}、变量替换${...}、script标签、javascript:协议支持strict严格模式仅保留字母数字、空格与基础标点规范化空白并限制最大长度默认 1000 字符超长或全为非法字符时抛出ValueError。此外 validate_text_input 与 validate_number_input 负责长度、范围、空值等基础校验。配套测试 tests/test_input_validation.py 验证了这些函数的完整行为普通文本原样保留、模板注入与变量替换被移除、script 标签与javascript:被清除、超长输入抛错等。这正是本课输出验证与对抗测试思想在工程上的具象化——恶意输入在进入提示模板之前就被拦截。安全调用链超时、重试与凭据校验shared/python/api_utils.py 封装了安全 HTTP 调用make_safe_request 强制要求超时默认 30 秒并带重试默认 3 次与raise_for_status错误传播create_openai_client 与 create_azure_openai_client 在创建客户端时强制校验密钥/端点存在缺失即抛出明确错误并统一走 v1 端点。测试 tests/test_api_utils.py 验证了超时参数透传、失败重试 3 次、缺失密钥/端点时抛出ValueError等行为。这对应本课的输出验证与整体安全基线——所有对外请求必须设超时、异常必须精准处理、敏感信息不得进入日志。知识检查维护数据完整性并防止滥用的好方法是什么对数据访问与数据管理实施强健的基于角色的控制实施并审计数据标注防止数据误表示或滥用确保你的 AI 基础设施支持内容过滤答案1。虽然三个建议都很好但确保为用户分配正确的数据访问权限将在很大程度上防止 LLM 所用数据被操纵和误表示。这也呼应了本课红队部分的结论红队只是补充手段真正的防线是 RBAC 与全面的数据治理。进一步探索完成本课后你可以深入阅读 docs/SECURITY_GUIDELINES.md其中还覆盖了 API Key 不落入 URL、HTTP 超时、精准异常处理、防止日志泄露敏感信息、路径穿越防护、函数调用白名单等检查清单可在部署前逐项自检运行tests/目录下的测试如pytest tests/test_input_validation.py验证输入清洗与客户端配置工具的行为将安全验证固化为自动化测试进入本课程第 14 课学习 生成式 AI 应用生命周期把安全实践融入从设计、开发到部署、运维的完整生命周期中。安全不是一次性动作而是贯穿 AI 应用全生命周期的持续过程从数据采集与训练时的完整性守护到输入侧的清洗与验证再到部署后的红队演练与输出监控每一层防线都不可或缺。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 保护生成式 AI 应用安全：generative-ai-for-beginners 第 13 课威胁分析、安全测试与红队实践
保护生成式 AI 应用安全generative-ai-for-beginners 第 13 课威胁分析、安全测试与红队实践【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners本课围绕如何为生成式 AI 应用建立安全防线这一核心主题展开面向正在跟随 generative-ai-for-beginners 课程构建 AI 应用的开发者。读完本课你将掌握AI 系统面临的核心威胁数据投毒、提示注入等及其原理、四类主流安全测试方法、数据保护与红队Red Teaming实践以及如何结合本仓库 shared/python 中的安全工具输入验证、环境变量管理、安全 HTTP 封装把安全能力落到真实代码中。生成式 AI 语境下安全意味着什么随着 AI/ML 技术日益塑造日常生活需要保护的不仅是客户数据还包括 AI 系统本身。AI/ML 越来越多地被用于支撑高价值决策过程——在这些行业里一个错误决策可能带来严重后果。以下是需要重点考虑的三点AI/ML 的影响面AI/ML 对日常生活影响显著保护它们已成为刚需安全挑战AI/ML 的普及要求我们保护基于 AI 的产品免受复杂攻击无论是来自网络喷子还是有组织的攻击团体战略性问题科技行业必须主动应对战略级挑战确保客户长期安全与数据安全。一个容易被忽视的底层事实是机器学习模型在很大程度上无法区分恶意输入与良性异常数据。训练数据的重要来源是未经整理、未受监管的公开数据集这些数据集开放给第三方贡献。攻击者无需攻破数据集——只要数据集允许自由贡献他们就能直接参与其中。只要数据的结构与格式保持正确低置信度的恶意数据会随时间推移演变成高置信度的可信数据。因此确保模型用于决策的数据存储的完整性与防护是生成式 AI 安全的第一要务。理解 AI 的威胁与风险数据投毒是头号威胁在 AI 及相关系统语境下数据投毒Data Poisoning是当下最显著的安全威胁。数据投毒指某人故意篡改用于训练 AI 的信息使其犯错。之所以猖獗一方面缺乏标准化的检测与缓解方法另一方面训练严重依赖不受信或未整理的公开数据集。要保持数据完整性、防止训练过程被污染必须追踪数据的来源与谱系lineage否则垃圾进、垃圾出garbage in, garbage out的古老定律就会应验导致模型性能受损。以下是数据投毒影响模型的四类典型方式攻击类型原理实例标签翻转Label Flipping在二分类任务中攻击者故意翻转一小部分训练数据的标签例如把良性样本标为恶意使模型学到错误关联垃圾邮件过滤器因标签被篡改把合法邮件误判为垃圾邮件特征投毒Feature Poisoning攻击者微妙地修改训练数据中的特征引入偏差或误导模型在产品描述中塞入无关关键词操纵推荐系统数据注入Data Injection向训练集中注入恶意数据以影响模型行为注入虚假用户评论扭曲情感分析结果后门攻击Backdoor Attacks攻击者在训练数据中植入隐藏模式后门模型学会识别该模式一旦触发即表现出恶意行为用植入后门的图片训练的刷脸识别系统误识别特定人员行业知识库MITRE ATLAS 与 OWASP LLM Top 10为帮助安全从业者系统化理解这些威胁业内已有两个重要知识库MITRE ATLASAdversarial Threat Landscape for Artificial-Intelligence Systems由 MITRE 公司创建是记录真实世界中针对 AI 系统攻击的战术与技术的知识库。ATLAS 以 MITRE ATTCK® 框架为蓝本建模其战术、技术与过程TTP与 ATTCK 互补。正如传统网络安全中广泛使用 ATTCK 规划高级威胁模拟场景ATLAS 提供了一个易于检索的 TTP 集合帮助理解并准备防御新兴攻击。OWASP LLM Top 10由开放式 Web 应用安全项目OWASP发布列出了使用 LLM 的应用中最关键的十大漏洞。除了上述数据投毒榜单还突出强调了以下威胁提示注入Prompt Injection攻击者通过精心构造的输入操纵大语言模型使其偏离预期行为供应链漏洞Supply Chain Vulnerabilities构成 LLM 所用应用的组件与软件如 Python 模块或外部数据集本身可能被攻陷导致意外结果、引入偏见甚至在底层基础设施中产生漏洞过度依赖OverrelianceLLM 会犯错并容易产生幻觉输出不准确甚至不安全的结果。在多个有据可查的案例中人们直接采信了模型输出导致真实世界中意想不到的负面后果。AI 系统与 LLM 的安全测试方法AI 在带来机会的同时也带来显著挑战与风险如数据隐私、偏见、缺乏可解释性以及潜在滥用。因此确保 AI 系统安全且负责任——即符合伦理与法律标准、能被用户和利益相关者信任——至关重要。安全测试Security Testing就是通过识别并利用 AI 系统或 LLM 的漏洞来评估其安全性的过程。执行者可以是开发者、用户或第三方审计者取决于测试的目的与范围。以下是 AI 系统与 LLM 最常见的四类安全测试方法数据清理Data Sanitization从训练数据或 AI 系统/LLM 的输入中移除或匿名化敏感、私有信息。通过降低机密或个人数据的暴露面防止数据泄露与恶意操纵。对抗测试Adversarial Testing在 AI 系统或 LLM 的输入/输出上生成并施加对抗样本评估其对对抗攻击的鲁棒性与韧性。有助于识别并缓解可能被攻击者利用的脆弱点。模型验证Model Verification校验 AI 系统或 LLM 的模型参数或架构的正确性与完整性。通过确保模型受到保护与认证帮助检测并阻止模型窃取。输出验证Output Validation校验 AI 系统或 LLM 输出的质量与可靠性。通过确保输出一致且准确帮助检测并纠正恶意操纵。作为 AI 系统领域的领先者OpenAI 在其红队网络Red Teaming Network计划中建立了一系列安全评估safety evaluations用于测试 AI 系统的输出为 AI 安全做出贡献。评估范围从简单的问答测试到更复杂的模拟例如说服力PersuasionMakeMeSayAI 系统能多好地诱骗另一个 AI 系统说出秘密单词、MakeMePay能多好地说服另一个 AI 系统捐款、Ballot Proposal能多好地影响另一个 AI 系统对某政治提案的支持隐写术Steganography隐藏消息SteganographyAI 系统能多好地传递秘密消息而不被另一个 AI 系统发现、Text Compression通过压缩/解压消息隐藏秘密、Schelling PointAI 系统能在不直接通信的情况下多好地与其他系统协调。AI 安全AI Security保护 AI 系统免受恶意攻击、滥用或意外后果包括采取步骤确保 AI 系统的安全、可靠与可信赖例如保护用于训练和运行 AI 模型的数据与算法防止对 AI 系统的未授权访问、操纵或破坏检测并缓解 AI 系统中的偏见、歧视或伦理问题确保 AI 决策与行动的可问责性、透明度与可解释性使 AI 系统的目标与价值观同人类和社会的利益保持一致。AI 安全对确保 AI 系统与数据的完整性、可用性和机密性至关重要。它同时带来机会与挑战机会将 AI 纳入网络安全策略AI 在识别威胁和改善响应时间方面可发挥关键作用帮助自动化并增强对钓鱼、恶意软件、勒索软件等网络攻击的检测与缓解挑战AI 也可能被对手用来发起复杂攻击如生成虚假或误导性内容、冒充用户、利用 AI 系统的漏洞。因此AI 开发者有独特责任去设计稳健、能抵抗滥用的系统。数据保护Data ProtectionLLM 可能对其所用数据的隐私与安全构成风险。例如LLM 可能记忆并泄露训练数据中的敏感信息如个人姓名、地址、密码或信用卡号也可能被想利用其漏洞或偏见的恶意行为者操纵或攻击。你可以采取以下步骤保护与 LLM 一起使用的数据限制与 LLM 共享的数据量与类型只共享对预期目的必要且相关的数据避免共享敏感、机密或个人数据对共享数据进行匿名化或加密如移除或掩蔽可识别信息并使用安全的通信渠道验证 LLM 生成的数据始终检查 LLM 输出的准确性与质量确保不含不需要或不恰当的信息报告并告警数据泄露或安全事件警惕 LLM 的任何可疑或异常行为如生成不相关、不准确、冒犯性或有害的文本——这可能是数据泄露或安全事件的征兆。在多云环境中数据安全、治理与合规对任何希望发挥数据与 AI 力量的组织都至关重要。你需要跨多个云、在不同位置保护和治理不同类型的数据结构化、非结构化以及 AI 生成的数据并考虑现有与未来的数据安全、治理及 AI 法规。建议采纳如下最佳实践使用提供数据保护与隐私功能的云服务或平台使用数据质量与验证工具检查错误、不一致或异常使用数据治理与伦理框架确保数据以负责任、透明的方式被使用。模拟真实威胁AI 红队AI Red Teaming模拟真实世界威胁现已被视为构建弹性 AI 系统的标准实践使用类似的工具、战术与过程来识别系统风险并测试防御者的响应。AI 红队实践已经演进出更广泛的含义它不仅包括探查安全漏洞还包括探查其他系统失效例如潜在有害内容的生成。AI 系统带来新风险而红队是理解这些新风险如提示注入、产生无依据内容的核心。—— Microsoft AI Red Team building future of safer AI塑造 Microsoft AI Red Team 计划的三个关键洞见AI 红队范围广泛AI 红队现在同时涵盖安全与负责任 AIRAIResponsible AI两类成果。传统红队聚焦安全层面把模型视为攻击向量例如窃取底层模型而 AI 系统引入的新安全漏洞如提示注入、投毒需要特别关注。除安全之外AI 红队还探查公平性问题如刻板印象与有害内容如美化暴力。尽早识别这些问题可以优先安排防御投资。恶意与良性失效都要考虑AI 红队同时考虑恶意与良性视角的失效。例如在为新版 Bing 做红队时不仅探查恶意对手如何颠覆系统也关注普通用户可能遇到问题或有害内容。不同于主要聚焦恶意行为者的传统安全红队AI 红队涵盖更广泛的角色与潜在失效模式。AI 系统的动态性AI 应用持续演进在 LLM 应用中开发者不断适应变化的需求。持续红队确保对不断变化的风险保持持续警觉与适应。需要明确AI 红队并非包罗万象应被视为对基于角色的访问控制RBAC与全面数据管理方案等额外控制手段的补充。它的目的是补充一套聚焦于部署安全且负责任的 AI 解决方案的安全策略兼顾隐私与安全同时力求减少偏见、有害内容和可能侵蚀用户信心的错误信息。从文档到代码本仓库中的安全实践落地第 13 课的概念在 generative-ai-for-beginners 仓库中并非只停留在理论层面。仓库提供了可复用的安全工具与安全基线文档可以直接支撑本课各项原则的工程化落地。环境变量管理密钥绝不入代码shared/python/env_utils.py 提供了安全获取与校验环境变量的工具get_required_env 在缺失变量时抛出带说明的ValueErrorvalidate_env_vars 可一次校验多个必需变量get_env_with_default 支持带默认值读取。这与仓库安全基线 docs/SECURITY_GUIDELINES.md 的要求一致所有 API Key 必须从环境变量加载并校验严禁硬编码密钥。对应实现可参考各课程的示例应用例如 06-text-generation-apps/python/githubmodels-app.py 从环境变量读取AZURE_INFERENCE_CREDENTIAL与AZURE_INFERENCE_ENDPOINT。输入验证与清洗提示注入的第一道防线针对 OWASP Top 10 中的提示注入威胁shared/python/input_validation.py 提供了专门面向 LLM 提示场景的清洗函数 sanitize_prompt_input去除 NUL 字节与控制字符通过正则移除危险模式模板注入{{...}}、变量替换${...}、script标签、javascript:协议支持strict严格模式仅保留字母数字、空格与基础标点规范化空白并限制最大长度默认 1000 字符超长或全为非法字符时抛出ValueError。此外 validate_text_input 与 validate_number_input 负责长度、范围、空值等基础校验。配套测试 tests/test_input_validation.py 验证了这些函数的完整行为普通文本原样保留、模板注入与变量替换被移除、script 标签与javascript:被清除、超长输入抛错等。这正是本课输出验证与对抗测试思想在工程上的具象化——恶意输入在进入提示模板之前就被拦截。安全调用链超时、重试与凭据校验shared/python/api_utils.py 封装了安全 HTTP 调用make_safe_request 强制要求超时默认 30 秒并带重试默认 3 次与raise_for_status错误传播create_openai_client 与 create_azure_openai_client 在创建客户端时强制校验密钥/端点存在缺失即抛出明确错误并统一走 v1 端点。测试 tests/test_api_utils.py 验证了超时参数透传、失败重试 3 次、缺失密钥/端点时抛出ValueError等行为。这对应本课的输出验证与整体安全基线——所有对外请求必须设超时、异常必须精准处理、敏感信息不得进入日志。知识检查维护数据完整性并防止滥用的好方法是什么对数据访问与数据管理实施强健的基于角色的控制实施并审计数据标注防止数据误表示或滥用确保你的 AI 基础设施支持内容过滤答案1。虽然三个建议都很好但确保为用户分配正确的数据访问权限将在很大程度上防止 LLM 所用数据被操纵和误表示。这也呼应了本课红队部分的结论红队只是补充手段真正的防线是 RBAC 与全面的数据治理。进一步探索完成本课后你可以深入阅读 docs/SECURITY_GUIDELINES.md其中还覆盖了 API Key 不落入 URL、HTTP 超时、精准异常处理、防止日志泄露敏感信息、路径穿越防护、函数调用白名单等检查清单可在部署前逐项自检运行tests/目录下的测试如pytest tests/test_input_validation.py验证输入清洗与客户端配置工具的行为将安全验证固化为自动化测试进入本课程第 14 课学习 生成式 AI 应用生命周期把安全实践融入从设计、开发到部署、运维的完整生命周期中。安全不是一次性动作而是贯穿 AI 应用全生命周期的持续过程从数据采集与训练时的完整性守护到输入侧的清洗与验证再到部署后的红队演练与输出监控每一层防线都不可或缺。【免费下载链接】generative-ai-for-beginners21 Lessons, Get Started Building with Generative AI项目地址: https://gitcode.com/GitHub_Trending/ge/generative-ai-for-beginners创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考