Agent分享链接与SSH转发的权限隐患

Agent 的权限边界，有时藏在一个分享链接、一个 SSH socket 里。给出的原文节选援引安全报道，称 Grok Build 的分享项目可被枚举，暴露应用及关联数据；另一则用户报告称，本地 SSH Agent 被转发到了远程执行环境。两件事都提醒程序员：功能是否方便，和它实际开放了多少权限，需要分开检查。

目前能确认什么

据节选转述，安全公司 Claroc 发现，Grok Build 的分享地址虽然随机，平台设计仍允许枚举有效项目。暴露内容包括商业计划、医疗检查结果、员工信息等。问题并非攻击者破解了随机字符串，而是平台提供了发现这些链接的途径。

仅凭链接即可访问资源时，链接就相当于持有者令牌（Bearer Token）：拿到它的人便获得访问资格。随机地址可以增加猜测难度，但无法阻止链接从索引、日志或聊天记录中泄露。

SSH Agent 转发则开放了另一种能力：远程进程通过转发的 socket，请求本地 Agent 为身份认证签名。

私钥没有离开电脑，不代表使用身份的能力没有离开。

节选还提到，Codex 仓库已合入显式选择启用的 --forward-ssh-agent 参数。这能说明转发能力存在，但单凭那则用户报告，无法确认其具体配置，也不能认定所有桌面环境都会默认转发。

我的判断

程序员检查 Agent 时，可以先盯住两个具体入口：分享页面是否要求登录并校验访问者权限；远程任务是否能接触本地 SSH Agent，以及该身份能访问哪些仓库。

前者不能只看地址够不够长。后者也不能只问私钥有没有上传。如果任务只需要读取一个仓库，却拿到了可向多个私有仓库推送的身份，授权范围就超过了任务需要。

目前仍缺少 Grok Build 的完整访问控制设计、修复状态，以及 SSH 转发报告中的启用过程和权限约束。现有材料足以提出审计问题，但不足以判断所有用户的实际暴露范围。