HN讨论 · 身份未知
让 AI Agent 通过用户填写的请求页获取密钥，而非直接把凭据交给管道
AI Agent 需要用户提供密钥时，传统做法是把 secrets 直接给 agent 或让 agent 访问 vault/浏览器，但凭据会流经模型路由、提供方等多个环节。作者构建了 peardrop：由 agent 生成请求页，用户经 Web/CLI 填写，之后值被放入目标位置或触发脚本，从而减少用户对管道泄露的担忧。
查看原始信号hn:49346770
目标用户
需要使用 AI Agent 处理 API key、vault/keychain 等敏感信息的开发者与自动化流程使用者，以及在意凭据在 agent 管道中泄露风险的用户。
潜在需求
一种能让 agent 在需要时向用户发起密钥请求、由用户主动确认并填写的机制，使凭据不需要直接暴露给 agent 或它的整个调用管道。
发生场景
给 agent 配置或让 agent 运行时，需要把密钥交给它，但 secrets 会经过 harness、model router、model provider、training set、聊天应用等中间环节，用户无法确定哪个环节会留存或泄露。
来源证据
项目作者因担心把 secrets 交给 agent 会在 harness、model router、provider 等管道环节泄漏，构建了让 agent 生成请求页、用户通过 Web/CLI 填写的工具。
Hi all, I kinda got sick of having to give secrets to my agents and all the potential leakage in the pipeline (with the harness, the model router, the model provider, the training set, the chat application etc etc) so I decided to make peardrop.fyi - this tool allows your agent to declaratively generate secret request pages/links which you can fill in via web or CLI. The agent can determine a script that runs once the values are received or can put them in a target folder. This is useful if youhttps://news.ycombinator.com/item?id=49346770
为什么值得留意
这个信号把 AI Agent 的安全问题从“agent 是否会偷用凭据”延伸到“传递过程中管道环节是否泄漏”，并给出一种用户可控的交互形态。作者用请求页/CLI 让 secret 传递可视、可人工确认，可能是 Agent 应用在凭据接入上被持续需要的设计方向。
已有方案
- 直接将 secrets 提供给 agent
- 让 agent 访问机器 vault/keychain 或浏览器
未满足部分
- 在不让 agent 直接接触凭据或浏览器访问权的情况下，仍能完成密钥的请求、传递和使用
可能延伸 · 模型推测
- 将 secret 请求流程封装为可嵌入不同 agent 框架的通用审批组件
- 把填写后的 secret 直接写入主流密钥管理器或密码管理器
- 记录每次 secret 请求的发放与过期策略，形成审计日志
目前未知
- 该工具目前是否已有独立用户采用
- 作者对泄漏风险的描述主要基于个人经验还是更多用户反馈
- agent 通过脚本使用 secret 后是否仍能以间接方式接触或导出明文
继续核实
- 在真实 AI Agent 工作流中，用户对 secrets 经手中间管道有多在意？
- 现有 vault 的授权机制（如 Keychain 弹窗）为什么不能覆盖这种场景？
- “agent 请求、用户审批”是否正在成为 Agent 接入凭据时的常见交互模式？
主题词
ai agent secretscredential leakagehuman-in-the-loop approvalsecret delivery