等到拉取请求阶段才进行的安全审查，已经跟不上AI智能体的速度。当一个想法一两周就能上线，工程部门以外的员工也在自行发布内部工具时，在合并关口检查代码既太晚，也太慢。SpaceX和xAI的一位安全工程师提出了另一种模式：安全团队把公司政策打包成上下文，让智能体在写代码的过程中随时调取。主要手段是Model Context Protocol（MCP，一种让AI智能体连接外部工具和数据的开放标准）服务器，以及编程工具中的钩子。而在这一切之下，传统的预防性控制比以往任何时候都更重要。
拉取请求关口为何失灵
传统的软件开发生命周期按固定顺序推进：团队先写产品需求文档和设计文档，再写代码，提交拉取请求（PR），等待同事批准，运行自动化测试，部署到预发布环境，经过质量保证，最后才上线。过去12到18个月里，专为编程打造的大语言模型打破了这条时间线。开发者如今在聊天和智能体界面中生成、调试和重构代码，而且常常同时运行多个模型会话。从想法到可运行的原型再到生产环境，所需时间已从数月缩短到一两周，有时只需几天。一些企业甚至用真实用户的反馈来代替漫长的预发布验证。
更大的变化发生在工程部门之外。招聘等部门的员工不再提交工单请工程师开发工具，而是直接用提示词让AI模型写出工具，再自行托管。这些工具从未经过工程团队，因此完全绕开了静态分析、安全审查和标准测试。
数字说明了安全团队为何跟不上：
| 因素 | 常见水平 |
|---|---|
| 安全工程师与软件工程师之比 | 约1比100 |
| 一名开发者并行运行的智能体 | 4到5个，各自负责不同的代码库或任务 |
| PR阶段每次安全扫描带来的延迟 | 5到10分钟 |
| 生成代码的非工程人员 | 每家公司数百到数千人 |
静态应用安全测试（SAST）和检查开源依赖的软件成分分析（SCA）会给每个PR增加几分钟。乘以五个并行智能体，这些检查就成了瓶颈。一些编程工具已能让智能体读取评审意见、编写修复并自动重新推送，于是可能出现荒诞的循环：评审机器人指出缺陷，另一个智能体推送补丁，两者在评论区你来我往。按照这种观点，安全验证更合适的位置是更早的阶段，也就是代码生成的过程中。
把安全规则放进智能体的工作流程
禁止AI智能体行不通。安全团队需要主动走到开发者已经在工作的地方，把公司政策、安全编码模式和“铺好的路”（paved road，即预先批准、默认安全的构建方式）变成智能体可以直接读取的形式。
有两种做法尤为突出：
- 智能体编辑器中的钩子。 Cursor等编程工具支持钩子，即在特定时间点自动执行的用户自定义操作。安全团队可以在这里设置护栏，让智能体在工作时检查公司规则。
- 由安全团队维护的MCP服务器。 智能体或开发者向服务器查询与当前任务相符的安全指引，例如搭建无服务器云基础设施的规则。返回的政策会进入模型的上下文窗口，也就是模型处理当前任务时依赖的工作记忆，因此它接下来写的代码会符合公司要求。
▲ 查询安全政策的智能体
“铺好的路”这一理念不变，变的是交付方式。静态文档和复制粘贴的模板，让位于智能体可以通过函数调用（模型以结构化格式调用外部功能的机制）来使用的API端点和工具定义。指引一旦可以调用，智能体就能自行查询并保持合规，无需有人去翻找政策维基。
左移终于变得可行
“左移”是指在开发早期发现安全问题，但它一直受制于人：开发者会疲劳、缺乏上下文、被截止日期追赶。智能体没有这些限制。它们能吸收大量代码检查规则，在后台运行安全检查，并修复检查发现的问题。例如，针对Terraform的编辑器检查工具一旦发现公开可访问的Amazon S3存储桶或范围过宽的信任策略，智能体就能当场修正。只要给智能体提供本地检查工具、批准使用的库清单和组织的政策规则，它就能在PR产生之前清理好自己的工作。
基础控制先于新的AI安全工具
一个常见错误是追逐新的“AI安全”产品，却忽视预防性控制。这个词本身的定义还很模糊，问十位从业者，可能得到十种不同的答案。AWS的服务控制策略（SCP）、GCP的组织政策和资源控制策略等云端护栏，是智能体无法越过的硬性限制。运行时沙箱、网络隔离和操作系统级隔离都有帮助，但无法取代身份与访问管理或云端边界。
权限同样关键。已有报道称，权限过大的智能体删除了整个生产数据库。给智能体直接写入权限，让它不经审查就把代码或基础设施变更推送到生产环境，是一种反模式。任何改变状态的操作，例如更新或删除，都需要审计记录和人的明确批准。
问责是另一半问题。读邮件、发Slack消息的个人“助手”型智能体代表用户行事，所以责任仍在用户。而在云端无人监督自主运行的智能体，根本无法被问责。正如IBM的一条老原则所说，机器无法承担责任，因此不应做出管理决策。所以自主智能体需要在身份层面和网络层面都受到严格限制的访问权限，以及明确定义的功能。
按智能体和操作类型匹配控制
智能体大致分为两类，另外还有一类在浏览器中运行：
| 智能体类型 | 作用 | 主要控制 |
|---|---|---|
| 编程智能体 | 处理代码库、构建、部署流水线和内部基础设施 | 变更需人工批准，隔离执行 |
| 问答智能体 | 以调用者的身份查询内部数据并整合答案 | 现有身份体系、安全MCP服务器、OpenTelemetry日志 |
| 浏览器智能体 | 代替用户完成网页任务 | 只在Island或Chrome Enterprise等受管理的企业浏览器中运行 |
更有用的区分或许是操作类型。只读查询，例如查找公开的S3存储桶，只要授权边界不被突破，无论由聊天型还是编程型智能体执行，风险都相近。创建、更新和删除操作的风险则高得多，需要严密监控和人工参与。OpenTelemetry是一个收集遥测数据的开源标准，可以记录哪个智能体在何时接触了哪个工具、端点或数据资产。
MCP服务器本质上是普通API的封装，因此可以在网络层或API网关层加以管控。如果企业在网络上屏蔽了某项服务的API，任何依赖该API的MCP服务器都会直接停止工作。
▲ 智能体隔离与访问控制
其他推荐做法包括：让智能体在隔离的云端沙箱中运行，而不是在员工的笔记本电脑上；过滤出站网络流量；使用出站代理把凭据注入请求，使密钥永远不进入模型的上下文。由于智能体会发起大量外部调用，操作系统级隔离和出站控制仍是尚未解决的难题。数据方面也需要投入：用目录和标签标记个人身份信息等敏感资产，智能体就能以程序化方式识别哪些内容不能碰。
安全团队如今可以自建工具
智能体也改变了安全团队“自建还是采购”的算法。过去，搭建内部安全中心需要具备全栈技能的工程师；现在，只要有清晰的想法，从业者就能自己动手。这一点对商业厂商缺乏动力开发的、各组织特有的工具尤为重要。
一个例子是策略拒绝说明工具。当开发者因Kubernetes准入控制器（根据策略允许或拒绝集群请求的组件）或AWS SCP而收到HTTP 403错误时，过去的惯常做法是截图，贴到Slack频道，再问安全团队原因。安全团队自建的Slack机器人可以读取拒绝信息，说明触发了哪条策略，指出配置错误所在，并给出需要修改的具体值。如果确实需要例外，它会引导开发者完成申请，只在需要批准时才请人工工程师介入。据估计，仅这一个工作流就能把重复的安全工单和工作中断减少25%到30%。同样的模式还可以扩展到HIPAA和PCI DSS等合规领域。
对于从未构建过智能体的从业者，建议的路径很简单：
- 用一到两周时间，把AI模型当作日常工作的个人副驾驶。
- 把任务分成三类：AI可以完全处理的、在人工监督下AI可以处理的、必须由人完成的。
- 找出重复相同步骤的工作，把它变成自动化工作流、智能体工具或内部应用。
例如，大量涌入的漏洞赏金报告的初步分诊，可以交给以代码库为上下文的智能体处理。
不过这里有个隐患。安全团队往往持有管理员级和root级凭据，安全智能体一旦被劫持或冒用，可能造成严重损害。安全团队应当让自己的自动化遵守与开发者相同的政策和沙箱规则。而当他们解决了某个难题，比如在不把密钥暴露在提示词中的情况下向智能体传递凭据，就应把这一方案变成全公司都能使用的“铺好的路”。
为智能体泛滥做好准备
如今，大多数企业中真正用好AI的团队只有一两个。一旦向外推广，就可能出现“智能体泛滥”，就像云时代的微服务泛滥一样。当年的答案是借助Kubernetes和云原生平台实现标准化。按照这种观点，如今的答案是由平台团队和安全团队共同打造、配备预先批准模板和遥测功能的内部AI平台。这样，即便是拥有1万名以上员工的企业，也能掌握哪些智能体正在运行，隔离不合规的部署，并快速响应安全事件。
安全团队现在可以做什么
智能体安全似乎正在从“最后一道关口拦截”转向“把公司规则提前放到智能体工作的地方”。可以从以下几点入手：
- 把政策作为工具开放。 把安全指引和“铺好的路”做成MCP服务器或可调用的函数，让智能体在行动前查询。
- 把检查前移。 在智能体的本地循环中运行代码检查和策略检查，而不是放在PR阶段。
- 核实基础控制。 确认SCP、组织政策、最小权限访问和数据分类已经到位。
- 为写入操作设关口。 任何改变生产环境的操作都要有人工批准和审计记录。
- 隔离执行环境。 让智能体在沙箱中运行，并管控出站流量和凭据。
- 规则同样适用于自己。 权限越高的安全团队智能体，越要按最严格的标准管理。