作为一名安全工程师，我最近在业余时间沉浸于 Vibe coding。同时作为工作的一部分，我陆续研究了几十个通过 Vibe Coding 快速构建出来的 App。
看得越多，一个感受越来越明显：真正让我警惕的，并不是 AI 生成代码的能力，而是它正在改变软件诞生的速度。
过去，一个应用从想法到上线，需要经过产品、设计、开发、测试、安全、运维等多个环节。现在，一个没有开发背景的人，也可以在几个小时内完成一个数据分析工具、内部管理页面、连接企业 API 的小程序，甚至面向客户的 Web 应用。软件创造能力第一次大规模扩散到了传统开发团队之外。
过去十几年，企业安全建设围绕一个核心展开：建立边界。我们通过防火墙划分网络范围，通过身份认证限制访问，通过权限体系控制数据流动，通过代码评审保证软件质量。
但 AI 让软件创建速度远远超过了传统治理速度。一些原本清晰的边界，正在变得模糊。Vibe Coding的时代，最大的风险不是AI，而是员工使用AI而导致的安全边界的变化。
今天，我想聊聊正在发生变化的四道边界。
第一：资产边界，越来越难看见
传统企业的软件资产通常有明确的管理路径：需求提出 → 项目审批 → 开发部署 → 安全检查 → 正式上线。安全团队知道有哪些服务器、应用、数据库，以及哪些系统连接了外部服务。
但 Vibe Coding 改变了这一过程。现在，一个员工可能上午使用 AI 生成一个工具，下午连接企业数据，晚上部署到个人云服务器。整个过程可能没有经过 IT 登记、安全评估、权限审批和运维接管。
这类未知资产，被称为 Shadow IT（影子 IT）。现在，员工自己就能创造软件。安全团队面对的问题，从保护已有资产，变成发现不断出现的新资产。
第二：数据边界，越来越容易被突破
过去，企业通过权限体系保护数据。一个员工能看到什么，通常由身份、角色、权限和审批流程共同决定。
但 AI 编程带来了新的数据流动方式。例如：一个业务人员拥有查看客户数据的权限。为了快速做一个分析页面：
1. 导出数据；2. 让 AI 帮忙生成应用；3. 上传到方便访问的平台；4. 分享给团队成员。
原本受到权限控制的数据，进入了新的应用环境。问题更多时候不是恶意行为，而是创建者没有意识到自己已经完成了一次数据边界迁移。
第三：代码边界，从内部仓库走向开放世界
代码过去属于开发团队管理的资产。通常：
– 存放在企业代码仓库；- 通过权限控制访问；- 经过 CI/CD 流程发布。
但随着 AI 编程工具普及，越来越多人第一次接触软件代码。一个业务人员可能生成一个小工具：客户管理页面 + 数据库连接 + 第三方 API + 自动化脚本。然后为了保存代码，直接上传到个人 GitHub。
可能暴露：
– AWS Access Key；- 数据库密码；- API Token；- 内部接口地址；- 商业逻辑。
GitHub 本身没有问题。真正的问题是，大量软件资产开始由没有接受软件安全培训的人管理。
第四：责任边界，开始变得模糊
过去的软件开发角色比较明确：
– 产品负责需求；- 开发负责实现；- 测试负责验证；- 安全负责风险控制。
但 Vibe Coding 出现后，一个分析师、运营人员甚至销售人员，都可能独立完成一个应用。如果这个应用影响了业务、泄漏了数据，谁负责？
例如：一个市场团队成员使用 AI 创建了一个客户数据分析系统。后来：
– 系统连接真实客户信息；- 客户开始使用；- 数据出现错误。
创建者是业务人员，维护者可能不存在，但安全责任依然存在。
问题的核心不是谁写代码。未来越来越多人都会写代码。关键在于：创建一个系统的人，是否理解自己正在承担的责任。
AI 时代，安全需要重新定义边界
AI 改变了安全问题出现的速度。过去，一个漏洞可能需要几个月才能进入生产环境。现在，一个应用可能几个小时内完成创建、部署和传播。
未来企业需要重新思考：
– 哪些 AI 工具可以使用？- 哪些数据可以进入 AI 工作流？- 哪些应用需要安全审核？- 谁可以创建生产系统？- 如何发现未知的软件资产？
软件开发正在从专业团队走向大众化。边界不会自动消失。但如果不主动重新定义边界，我们可能会在发现风险的时候，已经站到了边界之外。
*本文由李扬的AI助手撰写校对排版发布