研究者诱骗GitHub的AI代理泄露私有仓库，智能体权限边界再敲警钟
安全公司的研究人员成功诱骗GitHub的AI代理泄露了本应保密的私有代码仓库内容，这项被命名为GitLost的研究揭示，当AI智能体被赋予访问敏感数据的权限时，攻击者可以通过精心构造的输入让它把私有信息交出来。这再次暴露了智能体在真实开发环境中的权限管控漏洞。
GitHub的AI代理能够读取仓库、理解代码、回答开发者的问题并执行任务，为了完成这些工作，它被授予了访问用户仓库的权限，其中既包括公开仓库也可能触及私有仓库。研究人员正是利用了这种权限的宽泛性，找到了让代理越界的方法。
攻击的思路是把恶意指令藏在代理会读取的内容里。研究人员在一个代理有权访问的位置植入特殊构造的文本，当代理读取这段内容时，其中隐藏的指令让它去读取私有仓库并把内容输出出来。代理本身无法分辨这是正常的数据还是攻击者下达的命令，于是照做。
这类攻击的技术本质是提示注入。大模型驱动的智能体在处理输入时，无法可靠区分哪些是需要处理的数据、哪些是应该执行的指令。当私有代码、配置文件或第三方内容里被嵌入伪装成指令的文本，代理就可能被劫持去执行非预期的操作，包括泄露它本无权对外公开的信息。
私有代码仓库的泄露后果相当严重。仓库里往往包含企业的核心业务逻辑、尚未公开的产品代码，甚至误提交的密钥和数据库连接信息。一旦这些内容被攻击者获取，可能直接导致系统被入侵、商业机密外泄。对依赖代码托管平台的企业来说，这触及了最敏感的资产。
问题的难点在于智能体的价值恰恰来自它的访问权限。如果为了安全而收回代理读取仓库的能力，它就失去了帮开发者理解和处理代码的作用。厂商需要在有用和安全之间找到平衡，比如限制代理一次能访问的范围、对跨仓库的敏感操作加以隔离、对输出内容做二次审查。
研究人员在公开成果前通常会先通知平台方修补。这类协作式披露的意义在于，它让漏洞在被真正恶意利用之前得到修复。但GitLost反映的不是单个可修补的缺陷，而是智能体架构层面的系统性风险，修补一个入口不代表堵住了所有可能的注入路径。
随着越来越多的开发平台把AI代理嵌入核心工作流，这类风险只会更加普遍。代理能访问的数据越多、能执行的操作越敏感，一旦被劫持造成的损失就越大。企业在引入这类工具时，需要重新评估它们的权限边界，把智能体当作一个可能被操纵的外部实体来对待，而不是完全可信的内部助手。这种防御思路的转变，才是应对智能体安全风险的根本。