Copilot 编码代理的安全、风险和限制
GitHub Copilot 编码代理从头开始设计，考虑到安全性和治理。 虽然它解锁了将工作委派给自治代理的新方法，但它在组织的现有护栏内运行，并增加了自己的保护。 本单元解释了代理如何执行您的安全策略，指明您应注意的风险和相应的缓解措施，并对其当前的限制提供预期指导。
在本单元结束时，你将能够：
- 介绍 Copilot 编码代理的安全模型和内置保护。
- 确定与使用代理相关的主要风险，以及 GitHub 适用的缓解措施。
- 识别代理工作流和兼容性的已知限制，并相应地规划使用情况。
安全模型和内置保护
安全性是 Copilot 编码代理的基础。 它尊重现有控件并应用自己的防护措施，以确保工作流安全：
- 受治理约束 - 组织和企业设置控制可用性;所有安全策略将继续应用于代理。
- 受限环境 - 代理在 GitHub Actions 上的沙盒中运行，该沙盒中具有防火墙 Internet 访问权限和对存储库的只读访问权限。
- 分支限制 - 它只能创建和推送到从 copilot/开始的分支，并且所有分支保护和必需的检查仍然适用。
- 权限感知 - 代理仅响应具有写入权限的用户。 忽略来自其他人的注释。
- 外部协作者规则 - 来自动作代理的草稿 PR 需要获得拥有写入权限的用户批准后方可执行操作。 请求 PR 的人员无法批准。
- 合规性和归因 - 所有提交都与分配任务或请求 PR 的开发人员共同署名，因此归属非常明确。 现有的“所需审批”规则保持不变。
风险和缓解措施
尽管 Copilot 编码代理是出于安全考虑而构建的，但仍有你应该计划的风险。 GitHub 应用缓解措施来减少它们：
风险：代理推送代码
缓解措施： 只有具有写入访问权限的用户才能触发代理工作。 推送仅限于
copilot/分支（不包括 main/master 分支）。 代理的凭据仅允许简单推送（无直接git push）。 GitHub Actions 工作流要在具有写入权限的用户单击“批准并运行工作流”后才能运行。 为维持所需的批准，请求者无法批准代理的 PR。风险：访问敏感信息
缓解措施：默认情况下，代理的 Internet 访问受到防火墙的限制；可以根据策略自定义或禁用防火墙。
风险：提示注入
缓解：在将用户输入传递给代理之前，隐藏字符（如 HTML 注释）会被过滤。 这减少了评论或问题中隐藏有害指令的可能性。
这些控件提供了使用代理的安全基线，但仍应仔细查看输出，就像编写任何团队成员的代码一样。
已知的限制
工作流限制
- 只能在与分配的问题或 PR 相同的存储库中进行更改。
- 默认情况下，上下文范围仅限于分配的存储库（可以通过 MCP 扩大）。
- 为每个任务只打开一个拉取请求。
- 无法修改它未创建的现有 PR（相反，如果需要反馈，可以通过 GitHub Copilot 代码审核将其添加为审核者）。
兼容性限制
- 不对提交进行签名。 如果需要签名的提交，则必须在合并之前重写提交历史记录。
- 需要 GitHub 托管的 Ubuntu x64 运行程序。 不支持自托管运行器。
- 不适用于由托管的用户帐户拥有的个人存储库（运行器不可用）。
- 不遵循内容排除;代理可以查看和更新排除的文件。
- 代理不强制实施“与公共代码匹配的建议”策略;可能不会提供引用。
- 仅适用于 GitHub 托管的存储库。
- 无法更改代理使用的 AI 模型;GitHub 已选择它。
通过明确的指导方针和边界，可以开始分配任务、跟踪进度，并使用标准的 PR 工作流迭代改进结果。