收益：
- 能够分离身份验证和授权并使用 RBAC/ABAC 应用最小授权
- 能够通过在用户上下文中运行模型来避免混合代理风险
- 能够使用秘密管理系统存储和轮换 API 密钥
对人工智能系统的攻击很大一部分不是从“欺骗”模型开始的，而是从被盗的 API 密钥或过度授权的帐户开始的。这一层安全来自经典的信息安全，但在人工智能的背景下增加了新的风险：模型代表其他人叫车、服务帐户访问所有数据、密钥泄露到 GitHub。在本单元中，我们将学习如何通过身份验证、授权（RBAC/ABAC）、最小授权和秘密管理来缩小对人工智能系统的访问范围。
身份验证和授权之间的区别
这两个术语经常被混淆：
- 验证：“你是谁？” — 证明用户/服务确实是他们所声称的人（密码、令牌、证书、MFA）。
- 授权：“你能做什么？” — 确定经过身份验证的一方可以访问哪些资源/操作。
人工智能系统的关键微妙之处在于：当模型代表用户执行工作时，它是在该用户的权限下运行还是在广泛的服务帐户下运行？后者是危险的——因为被注入欺骗的模型获得了对服务帐户的完全访问权限。
注意：“困惑代理”问题：低权限用户通过外包高权限模型间接访问他无法访问的数据。该模型应该始终在用户权限的范围内运行，而不是他自己的广泛权限。
RBAC 和 ABAC
- RBAC（基于角色的访问控制）：访问取决于用户的角色。 “支持专家”角色可以读取客户注释，但不能删除它们。简单又常见。
- ABAC（基于属性的访问控制）：访问取决于属性：用户的部门、数据的隐私标签、一天中的时间、请求来自的网络。更精细但更复杂。
大多数组织从 RBAC 开始，并针对敏感数据深入到 ABAC。 AI 的经验法则：模型应根据发出请求的用户的角色/属性过滤其调用的每个代理及其访问的每个数据。
循序渐进：行使最低限度的权力
- 盘点库存。模型调用哪些工具，访问哪些数据？把它们全部列出来。
- 证明每次访问的合理性。 “这位助理真的需要删除权限吗？”否则，请将其删除。
- 默认只读。默认情况下模型应该能够读取；需要写入/删除单独的、窄范围的令牌。
- 移动用户上下文。使用用户权限调用车辆，而不是使用服务帐户。
- 短暂的凭证。使用短期的、自动更新的令牌而不是长期的密钥。
秘密管理
机密是必须保密的凭据，例如 API 密钥、密码、令牌或证书。 AI 项目中最常见的事故是模型提供商的 API 密钥嵌入到代码中并泄漏到版本控制 (Git) 中。
正确应用：
- 切勿在代码中嵌入密钥；使用环境变量或秘密管理系统（一种存储加密密钥并控制访问的服务）。
- 轮换：定期更新密钥（例如每 90 天）；如果怀疑有泄漏，请立即取消。
- 范围缩减：每个交换机仅具有所需的服务和所需的授权。
- 审计：记录谁使用了密钥、何时何地。
四个可复制模板
访问审核控制提示：
对于下面工具列表中的每个工具，评估：- 执行该助理的工作是否需要该工具？ （是/否）-它是只读还是写入/擦除？ - 这个工具是用用户的权限或服务帐户调用的吗？将不必要或过度授权的标记为“删除/编辑”。<tools>{{ tool_list }}</tools>
泄密扫描提示：
在以下代码片段中查找可能是硬编码秘密的任何内容：API 密钥、密码、令牌、连接字符串、私钥。为每个给出行和类型。将值复制到响应中；掩码（前 4 个字符 + ***）。<code>{{ source }}</code>
最小权限决策规则：
当新工具/访问请求到达时，询问：1。如果没有此访问权限，是否可以执行任务？ -> 如果是：拒绝2。只读就够了吗？ -> 如果是：授予写权限3。范围可以缩小到单一来源吗？ -> 如果是：darat默认答案是“否”；进入是通过理性获得的。
轮换日历提醒：
对于每个秘密，记录：所有者、创建日期、到期时间、范围。将任何已超过 90 天或 30 天未使用的密钥报告为“轮换/取消候选”。
弱提示/强提示
糟糕的方法
强硬的做法
模型使用单个服务帐户访问所有数据
模型以发出请求的用户的权限进行访问
API密钥嵌入在代码中，永远不会改变
关键秘密管理人员轮换，90 天
赋予助理广泛的“做任何事情”的权力
默认只读，写窄
访问从未被审查
定期访问审查和撤销
三个迷你箱
案例 1——泄露混合代理数据。一名内部助理正在使用一个可以访问所有员工记录的服务帐户。一位实习生用户通过说“汇总高管薪资表”访问了他通常不会看到的数据；因为模型是在其自身广泛权威的背景下质疑它的，而不是用户的。一旦用户上下文被调整为移动，实习生就能够提取只有他或她才能看到的录音。
案例 2 — 密钥泄露，两周内 190,000 土耳其里拉账单。开发人员将模型 API 密钥嵌入到帮助程序脚本中，并将其推送到公共存储库。机器人在 40 分钟内找到了密钥并使用了两周；账单达到了 190,000 里拉。当密钥被移动到秘密管理器、连接到轮换并添加存储库扫描时，该事件没有再次发生。
情况 3 — 只读默认值阻止中断。 DevOps 助理通过提示注入收到“重置生产数据库”命令。然而，助理只获得了一个只读令牌；写入/擦除处于单独的批准流程中。该命令因授权错误而被拒绝，该事件被记录为警报；没有数据丢失。
提示：对于新的访问请求，将“否”作为默认答案。进入是通过正当理由获得的；向每个人提供广泛的资金然后再削减几乎是不可能的，而且风险会不断累积。
常见错误
- 使用大型服务帐户运行模型并丢失用户上下文（混合代理）。
- 将 API 密钥嵌入代码中并将其泄漏到版本控制中。
- 根本不旋转按键（“工作中，请勿触摸”）。
- 默认授予助手写入/删除权限。
- 授予访问权限一次，就不再重新考虑。
- 将身份验证与授权混淆，并假设“他已登录，他可以访问所有内容”。
综上所述
- 认证是“你是谁”的问题，授权是“你能做什么”的问题；在人工智能中，两者都必须在用户的上下文中运行。
- 该模型应以提出请求的用户的权限运行，而不是以其自己广泛的权限运行（避免混合代理的风险）。
- 从 RBAC 入手，深入敏感数据上的 ABAC；将最小权限设置为默认值。
- 不要将秘密埋藏在代码中；将其存储在秘密管理器中，缩小范围并定期轮换。
- 只读默认和窄写极大地限制了注入的影响。
应用任务
列出您的 AI 助手访问的所有工具和数据。每个回答三个问题：（1）真的有必要吗？ (2)只读就够了吗？ (3) 它是否在用户上下文中运行？然后搜索所有硬编码的秘密（通过上面的扫描提示）并为找到的每个密钥编写轮换计划。删除至少一项不必要的授权。
清单
- [ ] 模型在发出请求的用户的权限上下文中运行。
- [ ] 工具和数据访问范围已缩小到最小权限原则。
- [ ] 写入/擦除与只读、验证和窄化分开。
- [ ] 代码中没有隐藏任何秘密；它保存在秘密管理器中。
- [ ] 钥匙有轮换时间表和取消程序。
- [ ] 访问会定期审核。