构建安全默认的 AI 编码 Agent：Anaconda 的工程实践
Stack Overflow 博客发布了对 Anaconda AI 产品工程副总裁 Greg Jennings 的访谈，探讨了构建安全默认（secure-by-default）的 AI 编码 Agent 所需的工程实践。访谈涵盖了为什么提示词不应该被视为严格的安全护栏、Anaconda 如何通过战略收购来保障 AI 软件供应链安全，以及安全编码 Agent 的设计原则。
背景：AI 编码 Agent 的安全挑战
随着 AI 编码工具（如 GitHub Copilot、Cursor、Anaconda Assistant 等）的普及，安全性成为一个日益重要的问题。AI 编码 Agent 不仅能生成代码，还能执行代码、访问文件系统、调用 API，这带来了新的安全挑战。
主要安全风险
- 恶意代码生成：AI 可能生成包含安全漏洞的代码（如 SQL 注入、XSS、硬编码密钥）
- 依赖混淆：AI 可能推荐使用存在已知漏洞的依赖包，或被混淆的恶意包
- 提示注入：攻击者可能通过代码注释、文档或输入数据注入恶意指令，操纵 AI 的行为
- 数据泄露：AI 可能在生成代码时泄露敏感信息（如 API 密钥、内部系统细节）
- 执行风险：AI 编码 Agent 可能执行危险操作（如删除文件、修改系统配置、访问敏感数据）
- 供应链攻击：AI 生成的代码可能引入易受攻击的依赖，成为供应链攻击的入口
核心观点：提示词不是严格的安全护栏
访谈中一个核心观点是：提示词不应该被视为严格的安全护栏。
为什么提示词不够安全
- 提示词可以被绕过：通过提示注入、角色扮演、编码等技巧，攻击者可以绕过提示词中的安全限制
- 模型行为不确定：同一个提示词在不同模型、不同版本、甚至不同时间的行为可能不同
- 复杂规则难以用自然语言描述：安全规则通常需要精确的逻辑和边界条件，自然语言难以精确描述
- 提示词冲突：当多个提示词指令冲突时，模型的行为不可预测
- 提示词泄露：提示词本身可能被泄露，攻击者可以针对性地设计绕过方法
正确的安全架构
Jennings 强调，安全应该通过架构和工程手段来保障，而不是依赖提示词：
- 最小权限原则：AI Agent 只拥有完成任务所需的最小权限，而不是全部权限
- 沙箱执行：AI 生成的代码在隔离的沙箱中执行，限制其对系统资源的访问
- 静态分析：AI 生成的代码在执行前经过静态分析，检测已知的安全漏洞模式
- 依赖扫描：自动扫描 AI 推荐的依赖包，检查是否存在已知漏洞
- 操作确认：高风险操作（如删除文件、执行系统命令）需要人工确认
- 审计日志：记录 AI Agent 的所有操作，便于事后审计和追溯
Anaconda 的战略：通过收购保障 AI 软件供应链安全
Anaconda 是数据科学和 Python 生态的重要参与者，以 Anaconda Distribution（Python 数据科学平台）和 conda 包管理器而闻名。近年来，Anaconda 通过一系列战略收购来加强其在 AI 软件供应链安全方面的能力。
收购策略
Anaconda 的收购围绕几个核心方向：
- 包安全扫描：收购能够扫描软件包漏洞和恶意代码的公司
- 依赖管理：收购能够管理和验证依赖关系的技术
- 运行时安全：收购能够在运行时监控和阻止恶意行为的技术
- 合规和治理：收购能够帮助企业满足合规要求的工具
为什么软件供应链安全对 AI 编码很重要
AI 编码 Agent 生成的代码通常依赖大量的第三方库。这些依赖构成了软件供应链的一部分：
- AI 可能推荐使用存在已知漏洞的包
- 攻击者可能发布与流行包名称相似的恶意包（依赖混淆攻击）
- 包的传递依赖可能引入未被审查的代码
- 包的维护者账号可能被入侵，发布恶意更新
Anaconda 通过收购来构建完整的供应链安全能力，确保 AI 编码 Agent 推荐和使用的包是安全的。
conda 生态的安全优势
Anaconda 的 conda 包管理生态在安全方面有一些独特优势：
- 包签名和验证：conda 支持包签名，可以验证包的完整性和来源
- 受控的包仓库：Anaconda 维护经过审核的包仓库，减少恶意包的风险
- 环境隔离：conda 环境提供了良好的隔离，减少依赖冲突和污染
- 依赖解析：conda 的依赖解析器可以检测冲突和不兼容的版本
- 企业级管理：Anaconda Enterprise 提供企业级的包管理和安全控制
安全默认的 AI 编码 Agent 设计原则
基于访谈内容，可以总结出构建安全默认的 AI 编码 Agent 的几个设计原则：
原则 1：深度防御
不要依赖单一的安全措施，而应该构建多层防御体系：
- 输入层：验证用户输入的安全性，检测提示注入
- 生成层：在提示词中嵌入安全指导，但不依赖它
- 输出层：对 AI 生成的代码进行静态分析和安全扫描
- 执行层：在沙箱中执行代码，限制系统资源访问
- 网络层：限制 AI Agent 的网络访问，只允许访问必要的服务
- 监控层：实时监控 AI Agent 的行为，检测异常模式
原则 2：最小权限
AI Agent 应该只拥有完成任务所需的最小权限：
- 文件系统：只允许访问特定目录，而不是整个文件系统
- 网络：只允许访问特定的域名和端口，而不是全部网络
- 命令执行：只允许执行特定的安全命令，禁止危险命令
- API 访问：使用受限的 API 密钥，只授予必要的权限
- 环境变量：不暴露敏感的环境变量（如密钥、令牌）给 AI Agent
原则 3：透明和可控
用户应该能够理解和控制 AI Agent 的行为：
- 操作预览：在执行操作前，向用户展示将要执行的操作和影响
- 可解释性：AI Agent 应该能够解释为什么做出某个决策
- 撤销能力：用户应该能够撤销 AI Agent 的操作
- 配置灵活：用户可以根据自己的需求调整安全级别和权限
- 审计日志：完整记录 AI Agent 的所有操作，便于审计
原则 4：安全不应该牺牲可用性
安全措施不应该让工具变得难以使用：
- 默认安全，可选放宽：默认配置是安全的，高级用户可以根据需要放宽限制
- 智能提示：当 AI 检测到潜在风险时，给出清晰的解释和建议，而不是简单阻止
- 学习用户偏好：根据用户的反馈和行为，动态调整安全策略
- 快速工作流：安全检查应该在后台进行，不影响正常的编码流程
- 一键信任：对于用户信任的项目或操作，可以快速跳过重复的安全检查
原则 5：持续更新和改进
安全是一个持续的过程，不是一次性的功能：
- 漏洞数据库更新：持续更新已知漏洞和恶意包的数据库
- 模型安全训练：持续训练模型，提高其识别和避免安全问题的能力
- 红队测试：定期进行红队测试，发现和修复安全漏洞
- 用户反馈：收集用户遇到的安全问题和误报，持续改进
- 行业合作：与安全社区和行业伙伴合作，共享威胁情报
对开发者的建议
访谈最后给出了对使用 AI 编码工具的开发者的建议：
- 不要盲目信任 AI 生成的代码：始终审查 AI 生成的代码，特别是涉及安全和隐私的部分
- 使用安全扫描工具：在 CI/CD 流程中集成安全扫描工具，检测代码和依赖中的漏洞
- 保持依赖更新：及时更新依赖包，修复已知漏洞
- 最小权限配置：为 AI 编码工具配置最小必要的权限
- 警惕提示注入：注意代码库中可能存在的提示注入攻击向量
- 学习安全最佳实践：持续学习安全编码的最佳实践，不依赖 AI 来保证安全
总结
构建安全默认的 AI 编码 Agent 需要系统性的工程实践，而不仅仅是在提示词中添加安全指令。Anaconda 的实践展示了几个关键方向：
- 提示词不是安全护栏：安全应该通过架构和工程手段保障
- 深度防御：构建多层防御体系，不依赖单一措施
- 最小权限：AI Agent 只拥有完成任务所需的最小权限
- 软件供应链安全：通过收购和技术积累，保障 AI 推荐的依赖包是安全的
- 安全与可用性平衡：默认安全，但不牺牲用户体验
- 持续改进：安全是持续的过程，需要不断更新和改进
随着 AI 编码工具越来越强大，安全性将成为区分优秀产品和普通产品的关键因素。Anaconda 的工程实践为行业提供了有价值的参考，也提醒所有开发者：在享受 AI 带来的效率提升的同时，不能忽视安全风险。
原文链接：https://stackoverflow.blog/2026/09/04/how-to-build-a-secure-by-default-ai-coding-agent/