尽管采纳攻击者的思维方式是红队行动的核心组成部分,但在明确的法律和道德界限内操作同样重要。作为红队成员,你的目标是找出薄弱点以用于防御目的,而不是造成实际损害或违反法律。本节介绍了规范大型语言模型红队行动的法律规定和负责任的披露实践,确保你的行动既有效又合乎规范。在此方面操作得当很重要,特别是在技术和相关法规持续变化的情况下。授权:合法测试的依据在任何红队行动开始前,获得明确的书面授权是最重要一步。此授权通常以工作说明书(SOW)或明确的行动规则(RoE)的形式体现。这些文件应详细说明:范围: 测试包含哪些系统、模型和数据?明确不在范围内的有哪些?允许的行动: 允许使用哪些类型的测试技术?是否有任何限制(例如,避免对生产系统进行拒绝服务攻击)?时间: 测试何时进行,持续多长时间?联系人: 红队和客户方指定的联系人是谁?如果没有明确授权,红队行动很容易被误解为未经授权的访问或恶意攻击,带来较大的法律风险。对于内部开发和托管的大型语言模型,此授权可能来自内部管理层。对于第三方大型语言模型或平台,你必须严格遵守其服务条款、漏洞赏金计划规则,或签订具体的合同。了解法律规定有些法律规定与大型语言模型红队行动特别相关。尽管这并非详尽的法律建议(具体情况请务必咨询法律专业人士),但理解这些方面是红队成员尽职调查的一部分。计算机访问与欺诈法规像美国的《计算机欺诈和滥用法案》(CFAA)以及其他司法管辖区的类似立法,都禁止未经授权访问计算机系统或超越授权范围进行访问。红队行动的性质包含探测系统的薄弱点。关联性: 未经许可测试大型语言模型、其API或底层基础设施可能违反这些法规。指导: 你的工作说明书(SOW)或系统所有者的明确许可,是你主要保障。确保你的测试活动严格保持在约定的范围之内。数据隐私规定大型语言模型可能会处理或无意中存储个人身份信息(PII)或其他敏感数据。欧洲的《通用数据保护条例》(GDPR)或加州的《消费者隐私法案》(CCPA)等法规对处理此类数据施加严格规定。关联性: 你的测试可能包含尝试提取敏感信息或测试数据泄露的薄弱点。指导:避免瞄准或尝试窃取真实用户的个人身份信息。尽可能使用合成数据进行测试。如果测试可能泄露个人身份信息,必须承认此风险,并制定处理此类情况的流程(例如,立即通知、安全地处理证据)。如果测试涉及跨境数据处理的模型,请了解其数据驻留和处理协议。知识产权和版权大型语言模型是在庞大的数据集上训练的,其中可能包含受版权保护的材料。关联性:测试“反刍”(大型语言模型完全复现训练数据)可能涉及受版权保护的文本。你编写的提示词和生成的输出本身可能具有版权影响。指导:注意避免将大量受版权保护的材料作为提示词输入,除非获得专门授权(例如,在提供的文档上测试摘要模型)。记录任何用于测试的特定受版权保护材料的来源。人工智能生成内容的法律地位仍在变化;关注找出的薄弱点,而非测试输出的所有权。服务条款(ToS)大多数大型语言模型平台和API都受服务条款或可接受使用政策的约束。这些文件通常规定了哪些是允许的使用方式,包括对安全测试、自动化查询或尝试逆向工程模型的限制。关联性: 违反服务条款可能导致账户暂停、法律诉讼,或使漏洞赏金计划中的任何“安全港”条款失效。指导: 务必查阅你打算测试的任何第三方大型语言模型或平台的服务条款。如果服务条款禁止安全测试,你必须获得明确的单独许可,或在官方漏洞赏金计划的范围内操作,该计划对批准的活动而言,凌驾于一般服务条款之上。大型语言模型红队行动的伦理准则严格遵守法律,同时伦理考量也指导着红队行动的开展方式,特别是对于能生成类似人类文本并以复杂方式交互的大型语言模型。危害最小化一个核心伦理原则是最小化红队行动可能造成的任何潜在危害。有害内容: 尽管测试大型语言模型生成有害、有偏见或不当内容的倾向是一个合理目标,但红队应避免生成过量此类内容或传播。目标是找出薄弱点,而非加剧危害。心理安全: 注意使用的提示词以及对人类审核者或与测试输出交互的任何人的潜在影响。影响: 避免可能产生负面影响的测试,例如生成和传播实际的错误信息,或尝试通过大型语言模型操纵系统或个人。客观性与偏见在测试大型语言模型中的偏见(例如,种族、性别、政治偏见)时,红队成员必须力求客观。自我认知: 在设计测试用例和解读结果时,认识并减轻自身的偏见。公平代表性: 确保偏见测试全面,且不会不公平地针对或错误地表现大型语言模型的行为。对利益相关者保持透明与系统所有者或利益相关者保持开放沟通,说明正在使用的方法,即使它们模拟对手策略。方法上的意外可能损害信任。工作说明书(SOW)应提供大致了解,若有需要,持续沟通可以澄清具体方法。负责任的披露实践一旦找出薄弱点,报告它的过程与找出它同样重要。负责任的披露是指向受影响系统的供应商或所有者报告安全薄弱点,给予他们合理的时间来修复问题,然后再公开细节。负责任的披露为何重要保护用户: 它给予组织时间修复缺陷,以防恶意行为者广泛利用它们。建立信任: 它促进研究人员/红队成员与开发者之间的合作关系。降低风险: 它最小化零日漏洞在没有警告的情况下出现的可能性。负责任的披露流程尽管具体情况有所不同,但典型的负责任披露流程遵循以下步骤:digraph G { rankdir=TB; node [shape=box, style="rounded,filled", fillcolor="#e9ecef", color="#495057", fontname="Arial", fontsize=10]; edge [fontname="Arial", color="#495057", fontsize=9]; Start [label="红队找出 薄弱点", shape=ellipse, fillcolor="#ffc9c9"]; Contact [label="1. 初次联系与验证 (找到安全通道,如security@ 或漏洞赏金平台)", fillcolor="#a5d8ff"]; Report [label="2. 详细薄弱点报告 (清晰描述、影响评估、 复现步骤/PoC)", fillcolor="#a5d8ff"]; Acknowledge [label="3. 供应商确认 (确认收到,初步分类)", fillcolor="#ffd8a8"]; Timeline [label="4. 修复时间线约定 (合作讨论修复时间线)", fillcolor="#ffd8a8"]; Fix [label="5. 供应商开发并部署修复", fillcolor="#b2f2bb"]; Verify [label="6. 红队/供应商验证修复 (确认薄弱点已解决)", fillcolor="#b2f2bb"]; Disclose [label="7. 协调公共披露(可选) (修复后或约定时间后,如适用)", fillcolor="#96f2d7"]; End [label="流程完成", shape=ellipse, fillcolor="#e9ecef"]; Start -> Contact; Contact -> Report; Report -> Acknowledge; Acknowledge -> Timeline; Timeline -> Fix; Fix -> Verify; Verify -> Disclose; Disclose -> End; }负责任地披露薄弱点的一般流程。重要组成部分包含:明确的报告渠道: 使用指定的安全联系方式(例如,security@example.com)、薄弱点披露平台或漏洞赏金计划提交入口。足够多的细节: 提供足够多的信息,以便供应商理解、复现和评估薄弱点的影响。这包括概念验证(PoC)代码或适当的详细步骤。保密性: 对薄弱点细节保密,直到约定的披露日期,或直到供应商有合理时间进行修补。合作: 与供应商合作澄清细节,并在必要时验证修复。漏洞赏金计划许多组织运行漏洞赏金计划,将负责任的披露流程规范化。这些计划通常:明确定义测试范围。为善意行动并遵守规则的测试人员提供法律“安全港”。为有效薄弱点报告提供金钱奖励。 通过官方漏洞赏金计划与大型语言模型供应商合作,通常是确保你的测试获得授权并有明确披露路径的很好方式。法律和伦理合规的实用步骤始终优先考虑书面协议: 如前所述,一份全面的工作说明书(SOW)或行动规则(RoE)是不可协商的。这份文件是你防止法律误解的主要防御措施。保持细致的记录: 记录下你所有的测试活动、沟通和情况。这份审计追踪记录对报告非常宝贵,在你的行动受到质疑时可能很重要。理解“行动规则”: 在工作说明书(SOW)之外,确保每个团队成员都理解哪些在范围内、允许哪些技术,以及在出现意想不到的敏感情况(例如,意外发现个人身份信息)时该怎么做。必要时咨询法律专家: 对于复杂的行动、测试高度敏感的系统,或者你不确定计划行动的法律影响时,向专门从事网络安全和技术法律的法律专业人士寻求建议。大型语言模型红队行动需要平衡考量。你在模拟对手,但这样做是经过许可的,且是为了开发或部署大型语言模型的组织利益。遵守法律规定和伦理最佳实践,特别是负责任的披露,确保红队行动积极促进这些强大人工智能系统的安全和保障。这种结构化的方法不仅保护你和你的组织,还促进人工智能开发更健康的生态系统。