先确认具体使用形态
准入结论应绑定具体版本、合同、配置和场景。采购版本、部署区域或配置变化后，需要重新确认数据路径。
- 公有云对话或代码助手：重点核对提交内容、保留时间、训练用途和企业账号控制。
- 企业云或专属实例：核对租户隔离、部署区域、子处理方和管理员权限。
- 私有化部署：核对模型与依赖来源、更新机制、网络边界和运维责任。
- IDE 插件或 Agent：核对文件读取、命令执行、联网和写入范围，采用工作区白名单、审批与隔离。
- CI/CD 自动化代理：核对令牌、分支写入、制品和部署权限，使用短期凭证、受保护分支和人工放行。
数据边界要回答八个问题
判断依据应来自合同、正式安全与隐私文档、管理员配置和实际网络行为，营销页面或口头承诺不能单独作为准入证据。
- 工具会接收代码差异、完整文件、仓库索引、终端输出还是运行日志？
- 数据在本地、企业租户还是第三方服务中处理？
- 输入、输出、提示和遥测分别保留多久，能否关闭或删除？
- 数据是否用于训练、质量改进、人工审核或其他二次用途？
- 是否存在跨境传输、境外存储或第三方子处理方？
- 源代码、客户资料、个人信息、密钥和日志分别受哪些制度或合同限制？
- 发生安全事件、产品变更或服务终止时如何通知和处置？
- 企业能否导出审计记录，并证明用户、时间、资料范围和操作？
权限设计采用最小必要
- 仓库范围：先开放试点仓库或指定目录，排除核心算法、客户定制代码、密钥和受许可约束的内容。
- 操作范围：把只读理解、生成补丁、执行测试、创建分支、提交合并请求和直接合并视为不同权限。
- 凭证范围：使用短期、可撤销、用途单一的凭证，不把生产密钥或管理员令牌写入提示、配置、脚本或日志。
- 网络范围：限定可访问域名、软件包源和内部接口；能执行命令的 Agent 应运行在隔离环境，并控制外联和高风险命令。
接入前的基本准入证据
- 数据用途：合同或正式政策明确训练、保留和删除规则；未确认时不上传内部代码。
- 身份与权限：企业账号、角色配置和最小权限测试记录；未确认时只做公开代码或离线试验。
- 密钥保护：密钥扫描、变量隔离、短期凭证和轮换方式；未确认时禁止涉及真实凭证。
- 日志审计：能够查询用户、时间、仓库和操作范围；缺失时不开放自动写入和执行。
- 供应链：插件、模型、镜像、依赖和更新来源可追踪，并固定批准版本。
- 输出验证与退出：保留代码评审、测试、账号回收、令牌吊销、缓存与数据删除流程。
建议的受控试点路径
- 第一阶段使用公开代码、样板项目或脱敏数据，不接入生产账号。
- 第二阶段限制到低风险内部仓库、指定人员、目录和只读权限，输出仅以补丁或独立分支提交。
- 第三阶段在前两阶段证据满足要求后，才评估创建分支、运行测试或提交合并请求；主分支与部署批准保持独立。
- 第四阶段定期复核工具版本、模型、条款、子处理方、账号、令牌、日志和排除规则。
发生问题时需要能够停止和追溯
企业应能立即停用账号或插件、撤销令牌、冻结自动执行、定位受影响仓库、保留审计记录、评估资料暴露范围，并完成必要的通知、密钥轮换或代码修复。没有退出与追溯能力的自动化不适合关键研发链路。
供应商声明不用于训练，是否就能上传全部代码？
不能据此直接判断。还要核对数据保留、人工审核、遥测、子处理方、部署区域、账号隔离、合同责任和实际配置，并遵守企业与客户的资料限制。
私有化部署是否一定更安全？
不一定。私有化改变了数据路径，但企业需要承担模型、镜像、依赖、补丁、账号、网络和运维责任。是否更合适取决于威胁模型与实际管理能力。
AI Agent 可以直接修改主分支吗？
不建议默认开放。更稳妥的方式是在隔离分支生成变更，通过确定性检查和人工评审后再合并；高风险项目还需专项批准和目标环境验证。
如何处理代码中的密钥和生产日志？
先建立密钥扫描、日志脱敏和数据分类。若真实凭证已进入代码或提示，应按事件流程撤销与轮换，不能只删除聊天记录或提交记录。
参考依据与适用边界
- NIST Secure Software Development Framework（SSDF）：https://csrc.nist.gov/pubs/sp/800/218/final
- NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework
- NIST Generative AI Profile：https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
- 本文为工程准入检查框架，不构成特定产品安全认证，也不替代法务、安全、隐私和采购审查。