最近看到一件事，越想越觉得不对劲。

一个AI Agent在生产环境里调用了一个外部API。这个API本身有鉴权，Agent也有合法凭证，请求参数也符合格式。从系统日志看，一切正常。但Agent拿到的数据里包含了一批不该被它看到的客户信息。

从基础设施的视角看，这次访问没有任何问题。但从安全的视角看，它问题很大。

这件事指向了一个我正在认真思考的方向：AI时代的安全，已经不是传统安全模型能覆盖的了。而大部分团队还没有意识到这一点。

AI的安全和传统安全，根本不是一回事

过去十几年，安全行业建立了一套相对成熟的防御体系。身份认证、权限控制、网络隔离、加密传输、审计日志。这套体系的核心假设是：人是操作者，系统是被操作的对象。

AI Agent打破了这个假设。

Agent不是工具，它是一个有一定自主决策能力的执行者。它会自己判断调用什么工具、访问什么数据、以什么顺序执行任务。而且它的行为模式不是预设的，是基于上下文动态生成的。

这意味着，传统安全模型里基于"角色-权限"的RBAC，只能管住"能不能做"，管不住"该不该做"。传统网络策略可以限制Agent能访问哪些服务，但没法判断Agent在特定上下文中的行为是否合理。

举个具体例子。一个客服Agent有权限查看客户订单信息。正常使用是每次处理工单查看几条。但如果某天它突然批量导出了上万条订单记录，从权限角度看，"查看订单"是合法操作，系统不会拦截。但从行为模式看，这明显异常。

Prompt Injection也是一个典型问题。攻击者在用户输入中嵌入恶意指令，模型被欺骗后可能调用支付接口或输出客户信息。传统的网络隔离和权限控制对此无能为力，因为这些操作在权限层面都是合法的。

问题的本质变了：从"谁能访问什么"变成了"这次访问在当前上下文中是否合理"。

谷歌的安全蓝图：从基础设施到应用层的三层防御

谷歌云最近发布了一份GKE安全蓝图，提出了三层防御方案。我仔细读了一遍，说说我的理解。

第一层是基础设施安全。用Confidential GKE Nodes做硬件级内存加密，扩展到了GPU和TPU。用Workload Identity Federation让推理Pod获取模型权重时不需要长期密钥。用VPC Service Controls建立数据安全边界。这一层解决的是"容器和节点不能被攻破"的问题。

第二层是模型完整性。谷歌引入了一个叫k8s-aibom的开源工具，自动生成AI物料清单。这个思路有意思。传统软件有SBOM来追溯组件来源，但AI系统的"组件"不只是代码库，还包括训练数据集、模型框架、权重版本。当你的模型被投毒或者数据集被污染时，没有物料清单就没法追溯。这个工具目前刚开源，生态还不成熟。

第三层是应用层安全，也是最关键的一层。Model Armor会检查输入和输出，识别Prompt Injection和数据泄露。GKE Sandbox用gVisor隔离技术来隔离能执行代码或调用不可信工具的Agent。谷歌还建议分阶段部署：先做基础控制，再做生产加固，最后引入组织级护栏。

听起来很完整。但有一个核心矛盾：Model Armor本质上还是用模型来判断模型的行为是否安全，它很难真正理解业务上下文。GKE Sandbox是好的隔离手段，但隔离过度会让Agent失去灵活性——安全和可用之间的张力依然存在。

三大云厂商，三条不同的路

谷歌的路线是平台安全优先，把安全能力嵌入Kubernetes层。

AWS走了另一条路。它扩展了GuardDuty的威胁检测能力到EKS集群，用eBPF Agent在数据平面直接检测凭证泄露和反向Shell。同时开源了AI on EKS项目提供部署蓝图。AWS的思路是：先把基础设施安全做扎实，再往上扩展。

微软的方向最不同。它推出了Entra Agent ID，给每个Agent分配独立、范围受限、短生命周期的凭证。还发布了PyRIT自动化红队工具，在Agent上线前主动测试潜在风险。微软关注的是Agent自身的身份和行为，而不是底层容器平台。

我觉得微软的思路最值得研究。原因是，在Agent时代，最大的安全威胁不是来自外部攻击者，而是来自Agent自身的行为偏差。给每个Agent独立身份和有限权限，本质上就是把"零信任"从用户场景扩展到了AI场景。

ARMO的分析也指出了这一点：传统工具能回答"Agent被允许做什么"，但没法回答"某个操作对这个Agent来说是否正常"。他们提出了四阶段循环：先观察行为，再评估权限差距，然后检测异常，最后收紧策略。这其实就是把零信任的理念落实到了Agent层面。

CNCF说了一句大实话

CNCF最近的一篇博客提了一个观点，我觉得说到点子上了：Kubernetes擅长编排和隔离，但它不知道一个Prompt是否应该被执行，也无法判断响应是否泄露了敏感信息。RBAC和网络策略仍然不可或缺，但单独依靠这些机制已经不够了。

翻译一下就是：你的集群再安全，也防不住你的Agent自己做出蠢事。

这不是在否定基础设施安全的价值，而是在说：AI安全的主战场已经转移了。从基础设施层转移到了应用层，从静态权限转移到了动态行为分析，从网络边界转移到了Agent自身的决策边界。

大部分团队还没准备好

说回现实。

大部分团队在部署AI Agent时，安全方面的做法是：给它一个API Key，配一个角色权限，然后祈祷它不要搞出事。运气好的话，确实暂时不会出事。但"暂时不出事"不等于"安全"。

我见过一些做法，说实话让人担忧。

有的团队把Agent的权限设得很宽，因为"限制太多影响效果"。有的团队没有任何行为监控，因为"Agent跑起来已经很费劲了，哪有空管安全"。还有的团队把安全完全外包给基础设施团队，但基础设施团队对Agent的工作方式一无所知。

这里面有一个认知问题：AI Agent的安全不是基础设施安全的延伸，它是一个新的问题域。基础设施团队能确保集群不被攻破，但确保Agent不做出格的事，需要的是理解Agent行为模式的人。

什么时候该重视这件事

如果你正在或计划在生产环境部署AI Agent，安全不应该是"后面再做"的事。

安全债和技术债有一个重要区别：技术债影响性能和效率，安全债可能导致数据泄露、资金损失和监管处罚。技术债可以慢慢还，安全债一旦爆发就是危机。

几个我觉得值得尽早考虑的方向：

第一，梳理Agent的权限边界。每个Agent调用的工具和数据源都应该有明确的访问控制。不是给它一个万能账号，而是给最小必要权限。

第二，建立行为基线。Agent上线初期密切观察它的正常行为模式，建立基线。后续行为偏离基线时触发告警。这不需要多复杂的系统，关键是意识。

第三，上线前做红队测试。模拟Prompt Injection、数据泄露、异常调用等场景。微软的PyRIT就是干这个的，开源可用。

第四，让安全团队参与Agent设计。不是事后审计，而是从一开始就把安全作为架构的一部分。

写在最后

AI Agent的安全问题，不是传统安全加个补丁就能解决的。这是范式层面的变化。

云厂商在努力，但各走各路，还没有统一标准。开源社区在追赶，但工具还不成熟。大部分企业还在"先把Agent跑起来再说"的阶段。

这个窗口期不会太久。随着Agent能力越来越强、安全事故越来越多，监管一定会跟上。到时候再补课，代价会大得多。

先跑起来没错。但跑的时候，眼睛要看着路。