10月28日，GitHub宣布其代码扫描功能新增对AI应用与智能体的检测能力，并以公开预览形式在github.com上线。这项功能瞄准的正是AI应用时代最棘手的一类安全问题：智能体在读取外部内容时，可能把藏在其中的恶意指令当成命令执行，从而在不知不觉中越权操作、泄露数据。
新功能能查什么
根据GitHub官方更新说明，新的检测器会在拉取请求（Pull Request）创建时自动运行，并与已有的CodeQL分析并行工作。它会追踪一条关键的数据流路径：不可信内容是否能够到达一个同时拥有工具、数据或业务系统访问权限的模型。如果存在这样的路径，扫描就会在拉取请求的对话或文件变更标签页中发出提醒，并附上可操作的修复建议，让开发者在合并代码之前先处理风险，而不是等到上线后才复盘。
GitHub此次重点列出三类AI特有的风险。第一类是间接提示注入，这是OWASP大语言模型应用十大风险中的首位风险：攻击者把恶意指令藏在文件、网页或议题评论等不可信内容里，智能体在读取这些内容时可能受到操纵，进而执行非预期的操作。第二类是敏感信息泄露：当AI应用或智能体可以在缺乏适当授权控制的情况下访问敏感数据时，这些数据就可能被暴露给本不应接触它们的用户或系统。第三类是过度授权：智能体获得的能力、权限或自主程度超出了其任务实际所需，一旦行为出现偏差，造成的影响也会被放大。
为什么这类问题难靠人工审查发现
传统代码审查擅长发现逻辑错误和已知漏洞模式，但智能体的风险往往藏在架构层面，而非某一行代码本身。一个智能体是否危险，取决于三个要素的组合：它读什么、它能调用什么、它被允许做什么。单独看每一段代码可能都没有问题，只有当不可信输入、模型推理和工具调用连成一条完整路径时，风险才真正出现。随着越来越多团队把智能体写进代码库，这类组合式风险靠人工逐行检查越来越难以覆盖，这也是GitHub把检测前移到拉取请求阶段的原因。
值得注意的是，GitHub对这项功能的定位是“扫描”，而非“保证安全”。一次扫描没有报警，并不等于智能体在所有提示、工具、身份和生产状态下都是安全的；它更像是在合并前多了一道信号，帮助审查者把注意力放在最值得怀疑的数据流上。威胁建模、最小权限、人工复核和上线后的运行时监控，仍然是不可替代的环节。
使用门槛与当前限制
目前这项功能仍处于公开预览阶段，适用范围有明确边界。首先，它仅在github.com上提供，暂未登陆GitHub Enterprise Server。其次，使用它需要GitHub Advanced Security许可；对于已启用代码扫描并开启AI应用扫描的仓库，检测器会在符合条件的拉取请求上自动启动。也就是说，个人免费仓库用户不能默认假定自己已经用上这项能力，企业团队则需要先确认许可与仓库配置是否到位。
GitHub同时表示，覆盖的AI风险范围还会随着时间扩展。这意味着公开预览阶段的检测能力是一个起点，而非完整清单。团队在试用时，应当把它的输出当作新增的审查输入，而不是替代现有安全流程的结论；对于扫描结果，也应结合自身业务场景判断优先级，避免把所有提醒一视同仁，或者反过来因为提醒数量不多就放松警惕。
对开发团队意味着什么
对正在开发AI应用的团队来说，这次更新的实际意义在于把安全检查左移到了代码合并之前。过去，智能体相关的风险常常要到联调、内测甚至上线后才暴露，修复成本高，还可能已经造成数据或权限方面的影响。现在，风险路径可以在评审阶段就被标出来，附带修复建议一起交给审查者，相当于在代码评审清单里增加了一项专门针对智能体的检查项。
对审查者而言，新的提醒也有助于改变评审方式：不再只问“这段代码写得对不对”，还要问“这个智能体读了谁提供的内容、能动用哪些工具、权限是否超出了任务需要”。这三个问题，恰好对应GitHub此次列出的三类风险，也可以作为团队内部评审AI相关拉取请求时的通用检查框架。
展望：智能体安全正在成为标配环节
从行业趋势看，智能体已经从实验性功能走向生产系统的组成部分，围绕它的安全工具也在从通用代码扫描向专用检测演进。GitHub此次把间接提示注入、敏感信息泄露和过度授权纳入代码扫描，表明平台方开始把智能体风险当作常规软件供应链风险来处理，而不是只靠开发者自觉防范。
接下来值得观察的，是这项检测的覆盖范围会以多快的速度扩展，以及它何时会覆盖更多部署形态。对于已经在github.com上使用GitHub Advanced Security的团队，现在就可以在仓库中开启相关扫描，在真实拉取请求里验证它的提醒是否准确、修复建议是否可用；对于其他团队，则可以先用它提出的三类风险自查现有智能体：输入来源是否可信、数据访问是否有授权控制、工具权限是否收敛到任务所需。无论是否立即用上这项功能，这三道检查，都已经是开发AI应用时绕不开的基本功。