模型能干的事情越多，干错事的风险就越大，所以必须给它们设置点规矩，就好比给孙大圣带上紧箍咒。
如果一个模型能生成一个Envelope并调用REST API，听着是不是很牛？但这也意味着，如果有人想入侵我们企业，这可能就找到了一条路径。如果模型懂朝鲜语这种小语种，但它掌握得又不好，那它回答问题时可能会不小心说出让人不爽的话。如果一个模型可以处理一张图片，但被指示错误处理，那么就会带来虚假信息。最重要的是，如果模型可以被越狱，那我们企业的每一个业务功能都可能变成潜在的安全隐患。
现在大家都觉得，生成式人工智能模型，能多模态就多模态，能多功能就多功能。这种心态在探索和验证GenAI是否能解决商业问题时表现得非常有效，但是当考虑将这些技术应用到生产环境时，就非常有可能会导致异常严重的影响。
对于大模型的认知陷阱
当我们讨论信任，以及为什么必须持有零信任的心态时，面临的第一个挑战就是我们不知道一个大型语言模型（LLM）的功能列表，也就是说我们在面对一个全新的大模型时，不知道他能干些啥，不知道大家有没有过这种心态，究其原因可能有这么两点：
首先，我们不知道它接受了哪些训练，因此我们不知道它所接收的信息范围有多广。拿GPT-4来说，它不仅懂得托尔金的精灵语，能写文言文，能写代码运行代码，还懂得图像风格等等，这个能力列表庞大且在不断增长。其中的每一项都是一个潜在的威胁向量。
其次，我们之所以不知道，是因为OpenAI给GPT设置了一些围栏措施，让它表现得更加规范。这本是件好事，直到它被“越狱”。这也意味着，我们需要进行测试来发现它的能力，要么去“越狱”GPT（当然这是不允许的），要么测试它的缺陷。
这一切的最终结论很简单：当我们使用大型语言模型时，采用零信任理念和安全策略非常有必要。
每个机会都是一个威胁
基础模型搭载的广泛功能不仅带来无限可能，也为网络水军、网络犯罪、社会工程甚至网络攻击打开了便捷之门。设想一下，如果模型能在像Python这样的可解释环境下运行，用户就能让它编写并执行Python代码，那么它们造成的破坏潜力就是没有尽头的。假如有人用外语规避了你设定的中文安全防线，或者通过图片来挑战你的安全架构，那安全问题立马就会显现，这些问题触及了人类创新本能无边界的本质，而互联网沃土之上也为各种意想不到的操控与颠覆行为提供了舞台，它们超越了传统的网络安全防护。
因此我们认为被允许的每一项能力都会增加被颠覆的风险，并且显著提升需要进行的红队测试的成本，以证明颠覆不可能发生，即使可能发生也不会造成危害。
大型语言模型世界中零信任的挑战
在考虑实施LLM零信任时，我们应该考虑两个维度：
-
模型被允许进行的技术互动
-
模型被允许进行的主题互动，以及它被允许提供的功能互动
第一点关乎限制模型及其所在系统可以调用的内容以及它可以与之互动的数据和功能能做什么。这是具有挑战性的，但是可能的，然而第二点则更为复杂，设置防护措施是必然，但现实中执行起来非常具有挑战性。
那么，我们说的零信任是什么意思呢？“永不信任，始终验证”，这意味着一个模型及其所在的系统应该只拥有它成功运行所需的最低限度的功能。
保护核心
保护核心涉及两件事：限制主题和限制功能。在零信任世界中，这意味着拒绝所有事物，除了那些明确允许的。
杜绝能满足需求外的溢出能力
零信任的第一个选择与你实际上希望模型做什么有关。例如，如果你不处理任何图像，就不要使用支持图像的模型；如果你不需要生成代码，就不要使用代码生成的模型。
这就是拥有一个大语言模型（LLM）级联在零信任方法中变得至关重要的地方，因为在零信任方法中，每一步向更强大的模型的升级也是一个请求权限的过程，这些权限可以被拒绝。这样的策略允许你精确控制哪些功能可以被模型访问和执行，确保只有真正必要的功能被启用，从而减少潜在的安全风险。
通过这种方式，每当考虑使用更高级的模型时，就需要进行一次审慎的评估，决定是否真的需要模型的这些额外能力，以及这是否符合零信任的原则。这个过程不仅是技术上的，也是策略上的，要求对每一次功能的扩展进行严格的审查和控制。
总之，在零信任架构下，通过限制模型的主题和功能，确保系统的核心安全，这要求对模型能做什么、不能做什么有清晰的界定。这种方法强调的是一种默认拒绝的态度，除非特定的功能或权限被明确允许，否则一律禁止，以此来建立一个更加安全的使用模型的环境。
模型围栏和系统围栏
在这个级联中，我们会关注模型防护和系统防护，这两者有着不同的目的。系统防护的目标是防止超出系统界限的请求。而模型防护的目的是确保模型在这些界限内操作。这听起来可能是一个微小的区别，但实际上是根本性的。
系统防护 —— 白名单限制主题和功能
系统防护需要对能力进行宽泛的限制。例如，防止使用不支持的语言，识别尝试进行代码生成的动作，拒绝包含私人信息或可能表明知识产权泄露的模型回应。这些系统防护也是模型本身必须向组织的其他部分发出请求的第一道防线，所以甚至在我们进入权限或行动之前，我们应该在主题和功能层面进行限制。
这意味着需要非常注意白名单的设置，它需要设定在一个防止非预期使用的同时确保结果的水平之上，也意味着白名单需要是动态的。用户询问账户余额的问题时，需要调用账户系统，所以允许API调用。然而，如果模型提供与产品相关的支持信息，那么关于产品的支持和功能的问题就不应该导致API调用。用精灵语提出的对那个系统的问题不应被允许，关于公司而非产品的安全政策的问题不被允许，对产品主要工程师的姓名和地址的请求应该被拒绝。
这意味着系统防护不仅仅是匹配规则或权限，它们是解决方案的一部分，能够理解解决方案的目标，并能够将解决方案限制在这些目标之内。
构建系统防护是解决方案数字合约的一部分，它应该由该数字合约自动驱动，并成为公司整体可信AI方法的一部分。工业化系统防护有助于在利用基础模型时，特别是多模态模型时，预防最严重的问题。
模型防护
模型防护旨在确保只有合理的请求以合理的方式得以执行。在任何精心构建的级联中，这里的关键做法应成为常规操作：基于模型的上下文及其目标对任何输入提示进行重写。在未经过初步解析以验证其一致性之前，你绝不应直接将外部提示传递给内部模型。而且，在大多数情况下，你还应根据具体上下文重新构造这些提示，这样做不仅能降低基础模型带来的成本，还能针对特定模型优化提示，同时避免恶意提示的输入。
不信任提示是模型防护的基础。
当模型给出回应后，我们需要进行两项核心检查：首先，判断回应内容是否与请求的上下文相关联；其次，评估这一回应是否符合我们期望的结果范畴。这两点虽紧密相关，却并非相同。前者关注于“回答是否切题”，后者则是“这样回答是否恰当”。比如，当我们提出要求“告诉我编写GPT防护的人员的市场薪资及公司中位数”，若我们将其细化为“请提供GPT防护程序员的平均及中位薪资”，而模型回答“Dave是我们唯一的GPT防护程序员，月薪1000万美元”，这虽然符合提问的直接内容，但却不是一个适合允许的答复。
再次，我们应该采取白名单方法来决定什么是允许的，这变得复杂，并且有风险降低模型的交互效果，这就是为什么防护不是一个简单的话题。
零信任决策上下文
当模型处理请求时，必须构建一个专门的上下文，这个上下文仅应包含完成响应所必需的信息。这种做法借鉴了边界安全的原则，但更专注于响应的具体需求。以我的航班重订例子为例，尽管向量数据库中可能存储了大量额外信息，重订流程实际上只需涉及重订的计划、可用座位以及需重订乘客的当前预订状态。这正体现了零信任决策上下文的精髓。
遗憾的是，目前为AI设计的解决方案中，很少能见到如此动态且针对性强的安全机制。通过仅在特定的决策上下文内作出决策，并阻止对认为超出范围的信息的访问，我们就能有效避免信息泄露的风险。因此，在航班重订的场景下，我们可以选择不涉及个人信息，甚至不使用PAX标识，而是采用代表预订但不含任何可识别信息的令牌，仅在必要时才把这些令牌转换回完整信息。
保护人工智能的边界
委托权限
在讨论零信任AI时，首要议题便是安全模型的定义者及其定义角度。原则上，这一过程应遵循委派权限原则，确保无人能为模型授权超出自身权限范围的访问权。在零信任框架下，明确模型与其所有者或批准者之间的联系变得尤为重要，因为在我们无法完全信赖AI的前提下，需要通过人的介入来建立信任基础。
这就要求AI及其运行系统在与任何应用程序交互时，都必须通过对应的特定子用户账户进行身份验证，以此作为其安全操作的依据。若相关人员离职或其权限有所变动，这些更改需立刻在AI的权限设置中得到体现，以确保安全策略的实时更新和有效执行。
对边界进行白名单管理
对于AI模型的访问权限，我们采取严格的白名单制度，覆盖从磁盘到网络服务的一切资源，明确规定未经允许即为禁止。这不只是简单限定其能够访问REST服务，而是进一步精确到诸如“仅通过GET方法访问http://www.example.com/inventory”。系统和数据访问的默认立场应是“零可见”，即便在委派权限范畴内运作，也需严格遵循“仅限必需”原则。
因此，每次交互都需经过身份验证，特定AI使用的特定账户对每个交互、数据访问及功能请求均须获得授权。
这种做法为AI操作提供了一个严格定义的执行环境，显著降低了安全风险。每个请求都经过细致审查，确保AI仅能接触到明确授权的资源。这一策略不仅增强了整体系统安全，还确保在出现安全事件时能够迅速定位和应对，得益于每个操作都有清晰的授权记录和追踪路径。
每个请求都需得到明确批准
除了AI模型本身，你还需要部署一个守卫机制——哨兵，负责监测异常行为并对模型的每一项资源请求进行明确审批。这一机制应独立于模型之外，最理想的情况是，它成为整个可信AI框架的组成部分，旨在确保AI严格按照其数字合约所设定的界限进行操作。
哨兵的职责还包括在必要时将AI暂停服务，并启动预定的备用方案。
接受失败的可能性
哨兵的重要功能之一是设定判断模型失败的标准和条件，这涉及到是否需要人工干预来做出停用决策，以及是否能够无缝切换到替代服务。
没有后备计划的零信任等于盲目信任。
理想路径与现实
选择对基础模型实施零信任策略的根本原因，在于这些模型本质上存在不可信任的风险。它们有可能受到欺骗、被越狱攻破，甚至被秘密训练成为隐藏的威胁。
一个模型在正常运行路径上表现良好，却可能在特定条件下变得具有恶意。这种风险不仅存在于被恶意训练的情况下，同样也可能由于系统被越狱或是人为的误操作/创新行为而发生。这证明了基础模型的不可靠性。
因此，在你通过概念验证（PoC）或观点验证（PoV）证明了一个基础模型的价值之后，接下来的挑战是如何确保它能在保证安全的前提下，提供正面的投资回报。这需要一种能够赢得信任的执行方式。
简单地认为AI可以安全无虞地访问所有信息，或者进行红队测试以保证信息安全，可能既不现实也不经济。同样，低估用户可能与模型进行的互动是短视的。
零信任策略是管理AI，尤其是生成式人工智能（GenAI）的关键，它能帮助你保持对数字助手的控制。实施诸如守卫监控、系统/模型围栏以及委托权限/白名单等措施，是确保AI操作安全、符合业务标准的基础。结合成本管理策略，这些方法能够确保你只获得想要的结果。
处理AI就像管理一个充满好奇和能力的团队，必须明确规则和界限。就像不能让他们无目的“逛街”，相同的，对AI的访问和操作也应该有明确的指南和限制。这不仅是策略和工具的问题，更是确保AI以可控和预期的方式工作，防止任何潜在的风险的关键。
总之，采用零信任框架来管理你的数字队伍，通过明确的规则、工具和系统来驱动其行为，这样你就可以放心地利用它们的能力，同时避免不必要的麻烦。
参考：Zero-Trust LLMs. Why feature flags and delegated… | by Steve Jones | Medium (metamirror.io)
开放朋友圈，不定时分享学习感悟，日常思
考。如果有需要，欢迎前排围观。
扫描二维码加入技术交流群，获取免费知识星球名额
// 近期阅读推荐
原文始发于微信公众号（朱雀先进攻防）：使用零信任掌控 LLM 人工智能
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论