Agent 把文件交给远程环境时，链接泄露到底谁负责？用 YAFL 拆开传输加密、访问失效与端点风险
AI 编程 Agent 经常在不止一台机器上工作：本机生成测试报告，远程 VPS 跑构建，另一台环境负责部署或验收。文件一旦要跨机器，最常见的临时方案是把对象存储链接、聊天附件或长期 API Token 交给 Agent。它们能解决“传过去”，却没有回答更重要的问题：文件内容、文件名、下载权限、过期策略和 Agent 的运行凭据，分别暴露给了谁？
YAFL（Yet Another File Layer）是一个面向 Agent 的文件传递服务：可通过 CLI 或 MCP 调用，将文件在发送端加密后上传，并以带 URL fragment 的短期链接交付。它不是通用的安全沙箱，也没有独立第三方安全审计；更适合把它看成一层边界明确的临时交付通道。本文不把“端到端加密”当成万能标签，而是拆开它真正能保护的部分与仍需自行治理的部分。
先区分四类对象：文件、链接、API Key 与端点
在跨机器工作流中，最容易混淆的是“能访问服务的身份”和“能解密文件的能力”。YAFL 的设计把这两者分开：上传或管理传递记录需要 API Key；下载则由分享链接中的解密材料决定。官方文档说明，解密密钥位于 URL 的 #fragment，浏览器不会把 fragment 发送给 Web 服务器。因此，服务端不能仅靠 API Key 推导出文件解密密钥。
这带来一个实际收益：若远程机器上的 YAFL API Key 泄露，攻击者仍不能仅凭该 Key 解密此前已经交换的文件。不过，这不等于没有影响。攻击者可能以该身份创建新的传递、列出该身份的记录，或删除它有权管理的传递；应当把每个 Agent、每台机器的 Key 独立配置，并在异常后撤销对应 Key。
反过来，普通分享链接本身应被视为秘密。链接中携带了解密信息，任何拿到完整链接的人，在有效期内都可能下载并解密文件。它出现在 shell history、Agent 对话记录、日志截图、工单评论或聊天窗口时，风险并不会因为文件“已经加密”而自动消失。加密保护的是服务端和传输路径不直接读到明文，不会替你收回已经扩散的能力链接。
YAFL 的传递路径到底做了什么
YAFL 的公开安全说明给出了足够具体的实现边界：客户端使用 WebCrypto；每个文件使用新的 256 位密钥和新的 12 字节 IV，采用 AES-256-GCM；文件名与内容类型也被单独加密。应用服务器不接收文件字节，文件通过预签名 URL 直接写入对象存储，因此存储侧看到的是密文而非明文。
密码保护不是把密码上传给服务端验证。官方说明称，受密码保护的链接会使用 PBKDF2-SHA256（600,000 次迭代）和新的 salt 派生额外密钥材料；密码不发送给 API。它适合降低“完整链接被转发一次”带来的直接泄露风险：拿到链接的人仍缺少第二个输入。
但边界也必须写清：
- 发送端或接收端机器被攻破时，文件会在端点以明文形式出现，YAFL 无法保护已失陷的端点。
- 服务仍可看到账户邮箱、文件大小和传递时间等运行元数据；它不是匿名通信系统。
- 标准链接持有者即可解密；不要把它贴到公开 issue、长期文档或会同步到第三方的日志中。
- 官方明确表示尚未进行第三方安全审计。对于密钥、生产数据导出或合规受限材料，仍应先经过组织自己的密钥管理、DLP 与审批流程。
用 CLI 交付一次构建产物：把“谁能拿到”写进命令
YAFL 的 CLI 包名为 @yafldev/cli，可在 Node.js 20 或更高版本环境中安装。先完成交互式登录；官方安装脚本和文档均显示，登录会走设备授权流程，由人类在浏览器中确认，而不是将长期令牌直接粘贴进 Agent 提示词。
npm install --global @yafldev/cli yafl login yafl put ./dist/release.tar.gz --one-time --password "$YAFL_TRANSFER_PASSWORD"
这条命令适合“把一个一次性构建包交给指定远程环境”的场景。--one-time 让首次成功下载后传递失效；密码则避免单独泄露链接即可解密。密码不应与链接放进同一条 Agent 消息、同一个工单或同一份日志，否则两个控制面又被人为合并了。
接收端拿到完整链接和密码后，再将文件写入明确的目标目录：
yafl get 'https://yafl.dev/t/传递ID#链接中的解密材料' ./incoming
YAFL 还提供 yafl status、yafl list --json 与 yafl delete --yes 等命令。对于自动化，应在工作流结束后清理不再需要的传递；对一次性材料，也不要把“对象存储生命周期稍后删除”误当作访问控制。YAFL 的文档区分了两层：24 小时到期时，应用会拒绝再签发下载；对象存储的生命周期清理则是后续的资源与留存兜底，时间并非精确到秒。
接进 MCP 前，先决定哪些操作不该自动化
如果希望 Claude Code、Cursor 或其他 MCP 客户端调用 YAFL，官方给出的配置形式如下：
{
"mcpServers": {
"yafl": {
"command": "npx",
"args": ["-y", "@yafldev/mcp"],
"env": {
"YAFL_API_KEY": "在本机安全注入的专用密钥"
}
}
}
}
其 MCP 服务公开的 upload_file({ path, password, oneTime })、download_file({ url, destDir, password })、get_status({ url }) 等工具足以覆盖基本交付。关键不在于让 Agent 拥有更多工具，而在于限定其参数：上传只允许构建输出目录或经审批的导出目录；下载只写入隔离的接收目录；delete_file 是不可恢复的破坏性操作，应保留人工确认或策略门。
尤其要谨慎对待 email_link。官方文档明确提示：该功能会把包含 fragment 的分享链接发送到收件箱，因此邮件服务商及能访问该收件箱的人都可能获得解密能力。若确有邮件交付需求，应启用密码层，并用不同渠道传递密码；对高敏感文件，更稳妥的选择是避免把能力链接走邮件渠道。
一份可执行的交付检查表
把 YAFL 放进 Agent 工作流前，可以用下面的顺序审查：
还要为失败路径预留处理方式。Agent 在上传后不应把返回链接原样打印到所有日志；在需要传递给下一步任务时，优先使用受权限控制的秘密变量或短暂的人工交接。接收端在 yafl get 之前可先用 yafl status 确认链接仍有效，再将下载目录设为专用工作区，完成校验、提取与扫描后再把经过处理的产物移动到正式位置。这样，即使某次任务拿到了错误链接或过期链接，影响也停留在临时目录，而不是直接污染部署目录。
把 YAFL 作为 MCP 工具时，还应将“允许上传哪些路径”和“允许向哪些环境交付”写进调用策略，而不是仅依赖模型理解自然语言。比如，允许 ./dist/ 与经批准的测试报告目录，拒绝用户主目录、凭据目录和未经确认的数据库导出；对生产环境交付则要求一次性链接、额外密码与人工审批。工具层提供的是可用参数，组织仍要决定哪些参数组合可以自动执行。
- 按 Agent 与机器拆分 API Key：不要让所有自动化共用一个长期身份；异常时才能局部撤销。
- 按材料性质选择链接模式：临时构建包可采用一次性链接；链接可能进入协作系统时，再加独立密码。
- 把链接视为凭据：避免完整链接进入 CI 日志、聊天记录、截图、issue 与终端历史。
- 限制 Agent 的可读路径与落盘路径：加密不能阻止 Agent 选择错误文件上传，也不能阻止它把接收文件写入错误位置。
- 把到期与删除分开验证：到期解决访问截止，删除解决后续留存；两者都要纳入流程。
- 为端点风险保留原有控制：主机加固、最小权限、密钥轮换、审计和数据分类不会被文件传递层取代。
YAFL 的价值不在于把跨机器传输伪装成“零风险”，而在于把常被混为一谈的能力拆开：服务身份不等于解密权，链接失效不等于端点安全，存储密文也不等于没有元数据。对于需要让 Agent 把有限、短生命周期的文件交给另一环境的团队，这种拆分能让交付流程更容易审查，也更容易在出错时缩小影响范围。
相关链接