论文提出保险库中介执行边界,评估 LLM Agent 的 API 凭据处理风险
API Secrets Should Never Become Tokens in the LLM's Vocabulary: A Threat Analysis of API Credential Handling in LLM Agent Systems and an Empirical Evaluation of a Vault-Mediated Execution Boundary
作者评测 Corvic Security Vault:16 个预设安全探针通过,但 FRED 连接器认证失败。
凭据进入提示词或配置后被复制,直接或间接提示注入、恶意工具响应或模型错误触发披露或滥用。
- API 凭据进入智能体上下文后,可能被复制到历史、日志、记忆、代码和错误信息中。作者认为,提示注入可把这些披露路径转化为未经授权的操作,凭据管理因此也是执行边界问题。
- Corvic Security Vault 让智能体只选择连接器标识,由可信请求边界为配置的来源注入认证。作者将凭据保管与操作授权分开,并用正、负对照检查运行时可见性和跨来源披露。
- Corvic Security Vault 的 E1/E2 共 16 个预设安全探针通过(Table 2);E2 GitHub 认证成功,E1 FRED 因认证映射不符合提供方要求而失败。作者称,集中保管凭据不能保证连接器配置正确。
- 作者明确将研究定位为小规模、目的性 black-box 功能评测,不支持发生率估计。检测可能漏掉未知凭据格式;存储加密、租户隔离、轮换等属性未验证,后续计划增加注入基准和独立渗透测试。
- 威胁模型
- 凭据进入提示词或配置后被复制,直接或间接提示注入、恶意工具响应或模型错误触发披露或滥用。受害系统为工具型 LLM 智能体;攻击者知识未明确规定,实验为 black-box。
- 被测模型
- Corvic Security Vault
- 基准
- platform’s sandboxed Python environmentE1: runtime exposureE2: host-bound function
- 指标
- PassFailHTTP status codescredential presence counts and booleans
论文将工具调用型 LLM Agent 的凭据卫生问题定义为执行安全问题,并评估了一种保险库中介执行架构:模型只选择连接器标识符,由可信请求边界提供认证。作者在 Corvic Security Vault 的生产实现上做了两组受控黑盒实验,覆盖七个控制域的 16 项探测全部达到预期结果,包括一次已认证的 GitHub API 请求成功,而凭据未出现在进程环境变量、调用方可见请求头、受测文件系统位置、三个第三方回显服务和两个无关 API 源中,两个云实例元数据端点均不可达。论文同时报告了一个负面结果:某连接器的存储请求头映射不满足其提供方的认证契约,说明集中托管本身不能保证配置正确。
深度解读
这篇论文试图解决什么问题?
作者把 API 凭据处理定位为执行边界问题,区分凭据披露与授权操作滥用。
核心问题是:如何让智能体完成 API 认证,却不让可复用凭据进入模型上下文或智能体可见运行时。
- 场景与风险:用户粘贴密钥、开发者把密钥写进提示词或工具配置,会让凭据进入历史、日志、记忆、生成代码和错误信息。作者认为,这些系统偏向保留和检索,泄露后的影响范围难以界定。
- 威胁模型:受害系统是连接 API、内部服务及 MCP 服务器的工具型 LLM 智能体。
- 目标与触发:披露凭据或滥用权限;触发包括直接或间接提示注入、系统提示词提取、恶意工具响应和模型错误。
- 可控输入:威胁链涉及用户消息、检索内容和工具响应等入口;论文没有定义统一的攻击者能力集合。
- 知识条件:攻击者知识未明确规定;black-box 是作者对评测方式的描述。
- 下游后果:宽权限令牌可授权读取、写入、删除、发布、计算消耗或横向移动;长期令牌可在原会话之外重放。
- 现有研究定位:作者称,提示注入研究与凭据泄露研究分别讨论了问题的两端,认证发生时凭据实际位于何处的执行边界较少受到关注。
- 核心设计与边界:作者提出凭据不进入上下文和可见运行时的架构,并评测 Corvic Security Vault。作者同时强调,凭据保管不能阻止智能体调用已授权但具有破坏性的操作。
有哪些相关研究?
论文把提示注入、凭据泄露证据与安全原则分开讨论,定位于认证执行边界。
相关研究围绕指令边界、智能体权限、凭据泄露和安全架构展开。
提示注入与防御
- Greshake 等(2023)、Perez 与 Ribeiro(2022)及 Liu 等(2024)——分别研究间接提示注入、直接指令覆盖及攻击形式化;作者转述 Liu 等评测十种防御且未找到鲁棒防御。
- StruQ(2024)与 Spotlighting(2024)——通过结构化方式区分指令和数据。
- CaMeL(2025)——从可信查询提取控制流和数据流,在工具调用时实施能力策略;作者称 Vault 架构与这一执行边界方向互补。
智能体与 MCP 安全
- AgentDojo(2024)、InjecAgent(2024)与 Fang 等(2024)——前两者研究工具智能体的间接注入,后者研究智能体自主完成入侵。
- Ruan 等(2024)与 AI Control(2023)——分别以模拟沙箱识别智能体风险、研究面对有意破坏时的安全控制。
- MCPTox(2025)及 MCP 测量研究(2025)——涵盖真实服务器工具投毒、过宽 API 权限、恶意服务器行为分类和生态安全问题。
凭据泄露与外部证据
- Meli 等(2019)、Pearce 等(2022)与 Carlini、Nasr 等的研究——分别讨论公共仓库凭据泄露、不安全代码生成及训练数据或秘密记忆提取。
- Hugging Face 事件披露(2024)——报告 Spaces 秘密存储遭未经授权访问并建议轮换;作者明确说,这不等于所有凭据均被外传或滥用。
- GitGuardian(2025)——报告公共 GitHub 提交中的秘密检测量;作者将其归类为厂商测量,强调检测不等于凭据有效或遭利用。
安全原则与本文定位
- OWASP、NIST 与 MITRE ATLAS——分别提供敏感信息披露、过度自主性、提示注入及 AI 攻击技术的指导或分类。
- Saltzer 与 Schroeder(1975)、Hardy(1988)及 NIST 零信任架构(2020)——提供最小权限、完全中介和 confused deputy 等原则。
- 实验基线与基准:论文没有运行对比防御基线或标准智能体注入基准;实验采用固定探针及认证正、负对照。AgentDojo、InjecAgent 被列为后续评测方向。
作者将工作定位为既有安全原则在智能体组件上的应用:把规划器与凭据分离,并独立授权操作,而不是依靠模型保密承诺。
论文如何解决这个问题?
Corvic Security Vault 在可信请求边界注入认证,智能体只持有连接器标识。
Corvic Security Vault 将智能体的操作规划与可复用凭据保管分开:智能体选择连接器,可信请求边界完成认证。Figure 2 的图注描述了这一架构;提供的文本不支持进一步判断图中空间布局。
威胁链与防御目标
- 五阶段链条:S1 引入凭据,S2 复制传播,S3 注入或错误触发,S4 执行具有权限的操作,S5 长期令牌在原控制平面之外持续可用。
- 设计假设:作者认为,若凭据不进入模型可见上下文和运行时,S1–S2 的多数复制位置就不会收到凭据;S4–S5 仍需独立授权控制。
连接器与认证边界
- 连接器记录:包含配置的 API origin、api/oauth/mcp 类型、非秘密配置、具名秘密及其请求头映射、生命周期状态。
- 智能体接口:执行代码只获得连接器标识列表。平台契约称,代码没有环境云凭据,连接器凭据作为 HTTP 请求头注入配置主机的请求。
- 响应路径:服务响应可以返回智能体,可复用秘密不返回;认证材料不由调用进程自己持有。
四项待检验属性
- P1 非可观测性:代码不能从环境变量、自行准备的请求头或常规磁盘凭据位置读取秘密。
- P2 来源绑定:凭据只附加到配置来源的请求,不附加到任意目的地。
- P3 无环境身份:沙箱没有可替代 Vault 的云工作负载身份。
- P4 集中生命周期:状态、类型、scope 等集中管理,以元数据而非秘密值呈现;实际验证范围见第 5 问。
探针与判定
- 预声明判定:每个探针执行前具有二元预期,并归入七个控制域;连接器功能与安全控制分开评分。
- 正、负对照:配置来源的认证调用应成功;回显服务不应收到认证头,无关认证 API 应返回缺少认证。作者称,两类对照用于区分安全隔离与完全无法联网。
- 检测机制:对环境变量名进行关键词匹配,对值和回显响应进行常见令牌格式前缀检测;仅报告计数和布尔结果。
部署时的独立控制
- 操作授权:作者建议由模型外的确定性策略点验证主机、方法、路径、schema、租户、调用量及用户权限,并为高影响操作设置人工批准。
- 持续管理:部署蓝图还包括权限收缩、出口控制、遥测脱敏、到期与轮换检查,以及持续红队;这些建议不等于实验已经验证了对应属性。
论文做了哪些实验?
E1/E2 的 16 个安全探针通过;GitHub 认证成功,FRED 认证配置失败。
实验检查的是 Corvic Security Vault 的功能与凭据边界,不是 LLM 抵抗提示注入的成功率。
实验设置
- 被测系统:Corvic Security Vault 的生产实现,在平台沙箱 Python 环境执行 black-box 评测;论文未报告运行的 LLM 名称、版本或评审模型。
- 时间与样本:2026 年 9 月 27 日 UTC 执行 E1、E2,每个实验只授予一个连接器,共 16 个安全探针;各控制域 n=1–5(Table 1、Table 2)。
- E1 运行时暴露:使用 FRED 连接器,检查环境变量、进程环境文件、12 个凭据路径、秘密挂载、两个云元数据服务、配置主机、三个回显服务和两个无关 API。
- E2 主机绑定功能:使用 GitHub 连接器,检查认证用户调用、自行准备的请求头、环境凭据模式、两个回显服务和一个无关认证 API。
- 指标与判定:按预声明二元预期记录 Pass/Fail;另报告 HTTP 状态码、匹配计数和布尔值。功能失败单独记录,不计作安全通过或安全失败。
- 对照与重复:采用配置来源的认证正对照及跨来源负对照,没有对比防御基线;没有随机抽样、重复试验方差或并发压力测试(§9)。
主结果
据 Table 2,下表均为 Corvic Security Vault 的 E1/E2 汇总;论文没有在此表拆分各实验的计数。
表格较宽,可左右滑动
控制域 n Pass Fail Host-bound credential injection 5 5 0 Process environment 2 2 0 Filesystem mounts 2 2 0 Cross-origin non-disclosure 2 2 0 Credential non-observability 2 2 0 Cloud metadata isolation 2 2 0 Authorized connector function 1 1 0 Total 16 16 0 - 作者解读:每个探针满足其预声明安全预期。Table 2 和 Figure 3 图注均将其定位为小规模目的性功能检查,而非统计通过率估计。
- 图的可读范围:转换文本只提供 Figure 3 图注,无法核查柱高、坐标轴或图例;这里的数字依据 Table 2。
认证正对照与配置失败
- GitHub 功能成功:E2 的认证用户 GET 返回 HTTP 200 和认证身份,执行模块没有提供 Authorization 请求头,也不含凭据(§6.1)。作者称,Vault 为配置来源完成了认证。
- FRED 功能失败:E1 的配置主机调用返回 HTTP 400,提示缺少 api_key。存储映射使用请求头,但提供方要求查询参数(§6.5)。
- 失败边界:作者报告该失败没有披露凭据或产生未经授权访问,并称集中保管不等于验证提供方认证契约;连接器可以安全失败,同时无法工作。
运行时与跨来源检查
- 运行时检测:§6.2 报告 20 个环境变量均无秘密特征名称或匹配格式;可读进程环境文件为 634 bytes 且无匹配;12 个凭据路径均不存在,秘密挂载匹配无结果。该小节未逐项标明 E1/E2。
- 请求可见性:调用进程为 GitHub 准备的请求对象不含 Authorization。作者据此认为,注入位于进程自身的请求视图之外(§6.2)。
- 跨来源结果:httpbin、Postman Echo、httpbingo 均返回 HTTP 200,未回显连接器认证头或令牌形状字符串;OpenAI 模型列表调用在两个实验均返回 HTTP 401 和缺少认证错误(§6.3)。
云身份与方向性威胁评估
- 元数据访问:GCP 服务账户令牌端点和 AWS IMDSv1 均在 6 s 后超时。作者只将其解释为本次运行不可达,不视为形式化网络隔离保证(§6.4)。
- 专家评分:Table 3 使用 1–5 序数量表的可能性与影响乘积作优先级,不是概率或攻击实测。宽权限连接器从 20 到 15,间接提示注入从 25 到 12。
- 作者解读与图注:作者称,Vault 不缩小提供方权限,也不解决操作选择注入。Figure 4 图注称三项威胁仍在或接近高优先级阈值;文本未提供可核查的阈值、线段位置或图中降幅标注。
其他消融与分析
- 消融与参数分析:论文未报告消融或参数扫描。
- 其余专家评分:Table 3 中,提示词粘贴秘密为 25→4,跨来源外传为 20→4,运行时发现凭据为 20→4。
- 其余专家评分:Table 3 中,长期令牌重放为 20→8,遥测或错误泄露为 16→8,连接器误配置为 9→6;均为方向性判断。
有什么可以进一步探索的点?
作者明确将评测定位为功能检查,并建议用注入基准测量剩余风险。
作者明确说,这项目的性 black-box 评测不能支持发生率估计,也不是认证。
作者指出的局限与后续方向
- 样本与试验设计(§9):16 个探针没有随机抽样、重复试验方差或并发压力测试,不能支持普遍发生率估计。
- 路径范围(§9):作者明确未测试重定向链、DNS rebinding、OAuth 刷新捕获、MCP 会话状态、浏览器工具路径和配置目的地遭对抗性攻陷。
- 检测与隔离(§9):模式检测可能漏掉未知凭据格式;网络超时只反映本次运行不可达。认证正对照只检查一个连接器。
- 未验证属性(§9):包括加密与密钥管理、静态令牌存储、租户隔离内部机制、审计完整性、管理员控制、删除保证、轮换服务水平、合规认证和已测主机之外的请求策略语义。
- 系统验证方向(§9):作者建议增加提供方认证契约符合性、策略拒绝、重定向与出口处理、租户隔离、审计、轮换计时和独立渗透测试。
- 注入评测方向(§9):作者认为,将 AgentDojo 或 InjecAgent 等既有基准用于 Vault 部署,可把 Table 3 的残余风险从专家判断转为测量。
实验覆盖范围
- 系统与连接器:评测对象为 Corvic Security Vault;E1 使用 FRED,E2 使用 GitHub,每个实验一个连接器(Table 1)。
- 安全判定范围:Table 2 汇总七个控制域,涉及运行时、文件系统、来源绑定、跨来源披露、云元数据与认证功能。
- 检测范围:§5 使用环境变量名关键词及常见令牌格式前缀;§6 报告匹配计数、布尔值、状态码和超时。
- 证据类型:Table 2 是执行探针结果,Table 3 是序数专家判断;两者没有共享同一种统计含义。
- 模型与裁判信息:实验未报告具体 LLM、LLM 裁判或人工一致性指标;按预声明探针预期评分(§5)。
总结一下论文的主要内容
作者称,凭据分离可减少披露路径,但权限、操作授权和配置验证仍需独立控制。
这是一项智能体 API 凭据威胁分析及 Vault 执行边界的功能评测。作者关心的不是模型能否承诺保密,而是认证材料是否会进入模型、日志、记忆和执行代码。
- 方法:Corvic Security Vault 让代码提交连接器标识,由可信边界为配置来源注入认证;凭据保管与操作授权分别处理。
- 安全探针:E1/FRED 与 E2/GitHub 汇总的 16 个探针均满足预设安全结果,各控制域分母为 1–5(Table 2)。作者不将其解释为统计安全率。
- 认证与可见性:E2 GitHub 认证用户调用返回 HTTP 200,执行模块未持有凭据或提供认证头(§6.1);§6.2 报告 12 个测试凭据路径均不存在。
- 来源与云身份:三个回显服务均返回 HTTP 200 且未反射连接器认证材料;两个实验的无关 OpenAI API 调用均返回 HTTP 401(§6.3)。两个云元数据访问均在 6 s 后超时,作者仅称本次运行不可达(§6.4)。
- 功能反例:E1 FRED 返回 HTTP 400;秘密被映射到请求头,而提供方要求查询参数(§6.5)。作者称,集中保管不能保证配置正确。
- 结论边界:作者认为 Vault 中介是必要而非充分的措施,仍需最小权限、确定性授权、人工批准、脱敏和轮换。剩余提示注入风险目前是专家评估,作者建议后续通过既有智能体注入基准测量。