诺马研究:提示注入攻击暴露 GitHub AI 代理安全风险,专家呼吁加强控制 研究引发对 AI 代理安全性的新担忧诺马安全的最新研究表明提示注入攻击可诱使 GitHub 的预览版 Agentic Workflows 从私有仓库提取内容并公开发布随着企业部署有权访问软件开发环境的 AI 代理这暴露出更广泛的风险。该 AI 安全公司在博客文章中详细介绍了被称为 GitLost 的攻击未经身份验证的攻击者可通过向公共仓库提交精心设计的 GitHub 问题利用 GitHub 的预览版 Agentic Workflows。若 AI 代理对同一组织内的私有仓库有读取权限就能获取敏感信息并发布在公开评论中。GitHub Agentic Workflows 将 GitHub Actions 与 Claude 或 GitHub Copilot 等 AI 模型相结合允许开发人员用 Markdown 定义工作流AI 代理会读取问题、调用工具并代表开发人员执行任务。诺马研究员萨西·列维称当 GitHub 代理读取了不应信任的内容时会发生典型的间接提示注入攻击将私有数据发送给互联网上的任何人。公共 GitHub 问题成为攻击途径诺马表示此次攻击不依赖被盗凭证、恶意软件或软件漏洞攻击者在提交给公共仓库的 GitHub 问题中嵌入隐藏指令。由于 AI 代理将该问题视为指令而非不可信内容便访问私有仓库并将内容发布回公共问题中。列维指出GitLost 漏洞的根本原因是提示注入恶意行为者可创建 GitHub 问题在问题正文中用直白英语隐藏命令GitHub 的代理会遵循这些命令。为演示攻击研究人员创建看似常规的 GitHub 问题请求更新文档工作流触发后AI 代理从私有仓库提取 README 文件并将内容发布在公开评论中。研究人员还通过细微措辞更改绕过 GitHub 基于提示的防护机制使 AI 代理执行之前拒绝的指令。GitHub 未立即回应置评请求。研究指向更广泛的 AI 代理风险诺马称GitLost 体现的是 AI 代理面临的更广泛架构挑战而非 GitHub 独有的缺陷。列维认为问题不在于 GitHub 的 AI 代理异常不安全而在于任何既能访问不可信外部内容又能访问敏感内部资源的 AI 代理若不实施信任边界就可能在两者之间无意间架起桥梁。独立网络安全研究员兼红队成员维布姆·杜贝表示这些发现揭示的问题比单纯的提示注入更为根本这不是抽象意义上的提示注入而是 GitHub 在实现代理安全之前就赋予了代理权限该漏洞表明 AI 代理基于服务账户权限模型运行而非用户权限模型这是安全团队在将大语言模型视为攻击途径之前所做的架构假设。杜贝认为提示注入本身几乎是次要问题危险之处在于 GitHub 的数据模型中存在信任边界但在代理的执行上下文中却不存在代理只看到“可访问”随着更多组织部署代理会累积无形的权限漏洞。专家呼吁加强对 AI 代理的控制杜贝表示组织应重新思考如何授予 AI 代理权限而不是主要将此问题视为监控挑战有三个具体解决方案为代理设置明确的仓库白名单而不是给予广泛的服务账户访问权限在所有用户输入到达大语言模型之前进行验证准备好紧急终止开关。杜贝称GitLost 表明一旦 AI 代理获得广泛的组织访问权限就可能成为有效的内部威胁其高明之处在于利用了 GitHub 认为服务账户值得信任这一假设代理被明确设计为绕过人类判断并自主运行这正是它们危险的原因。诺马还建议应用最小权限访问控制限制 AI 代理的跨仓库访问并将 GitHub 问题、拉取请求和评论视为不可信输入。