为什么AI智能体正在破坏零信任安全

在过去的十年里，安全团队一直依赖零信任架构来保护他们的系统。其理念很简单：永远不要信任任何访问请求，始终进行验证。但这整个模型都是建立在一个单一假设之上——即由人类来做决定。2026年7月4日一篇探讨这一差距的文章概述了一个关键挑战：这个假设正在瓦解，并且其影响是严重的。

到了今天，2026年7月5日，这种转变比以往任何时候都更加重要。AI智能体不再仅仅是生成文本。它们正在企业环境中直接执行操作——查询数据库、触发工作流、调用API并修改记录。当一台机器可以在您的云基础设施内部代表用户自主操作时，该机器的身份就变得与任何人类用户的身份一样关键。这从根本上改变了我们需要如何思考安全问题。

发生了什么变化：自主AI的崛起

几年前，AI系统大多是被动的。它们生成摘要、写电子邮件、回答问题。如今，像Amazon Bedrock Agents这样的平台已经彻底改变了架构。这些系统现在可以解释用户的请求，决定需要哪些工具，并在无需等待批准的情况下自主执行后端操作。

这在实践中是什么样子的呢：一位用户输入“总结过去30天的客户投诉”。AI智能体便自行开始行动——它查询CRM数据库、调用分析API、提取支持工单数据并生成报告。所有这些都会自动发生，无需人工在循环中检查每一步。

这对于生产力来说是强大的。但如果没有得到妥善的安全保护，它也是极其危险的。

新的攻击面

一旦您想到可能出现什么问题，风险就显而易见了。一次成功的提示词注入——一种旨在劫持智能体行为的精心制作的输入——可以完全重定向智能体接下来要做的事情。如果该智能体拥有过于宽泛的权限，攻击者就可以迫使它去：

• 访问敏感的客户数据
• 执行未经授权的API调用
• 修改数据库中的记录
• 触发特权后端工作流

在多智能体环境中，问题变得更糟。想象一个处理公众请求的面向客户的AI智能体。如果该智能体遭到破坏，它可能会将恶意指令传递给一个拥有高度特权的后端智能体——一个有权修改基础设施或访问受限系统的智能体。传统的安全工具通常会完全忽略这一点，因为流量来自受信任的内部服务。它看起来是合法的。

为什么零信任不再足够了

零信任是为人类行为和相对可预测的访问模式而设计的。人类登录、在营业时间工作、遵循流程。AI智能体的运作方式则完全不同：

• 它们以机器速度自主行动
• 它们在没有实时人类验证的情况下做出决策
• 它们频繁地与其他智能体通信
• 它们的行为更难预测

传统的安全系统现在难以回答这些棘手的问题：

• 这个操作对于这个特定的智能体来说合理吗？
• 这个请求是否符合其预期角色？
• 这种AI对AI的交互合法吗？
• 这种行为是否偏离了我们通常的预期？

仅仅是身份验证——证明你就是你所声称的那个人——已经不够了。你可以验证一个智能体是真实的，但仍然不知道它是否应该做它即将要做的事情。

如何真正确保AI智能体的安全

像对待常规IAM用户（身份和访问管理——控制谁可以访问什么的系统）那样对待AI智能体是不够的。必须将安全性直接设计到架构中。以下是关键实践：

步骤1：仅使用短期凭证

每次智能体执行都应通过AWS STS（安全令牌服务）或同等服务接收临时凭证。长期凭证——比如永远有效的API密钥——会制造持久的攻击路径。如果攻击者窃取了短期令牌，它会在几分钟或几小时内过期。如果他们窃取了永久密钥，他们就会一直拥有访问权限，直到有人注意到并撤销它。

步骤2：应用真正的最小权限

每个智能体都应该有一个专用的IAM角色，具有受到严格限制的权限。不要让智能体拥有对“数据库中所有内容”的广泛访问权限。相反，只赋予它执行工作实际所需的那些确切的Lambda函数、API和数据库的权限。如果你能说出它的名字，你就应该限制它。

步骤3：消除静态API密钥

硬编码凭证永远不应该存在于AI工作流中。埋在代码中的秘密可能会在版本控制、日志或内存转储中泄漏。相反，请使用工作负载身份联盟（Workload Identity Federation）和OIDC（OpenID Connect）协议来让智能体动态地承担临时角色。智能体不需要持有密钥——它向一个受信任的机构证明自己的身份，由该机构颁发临时权限。

步骤4：积极隔离智能体工作流

在单独的VPC（虚拟私有云）或AWS账户中运行智能体，以在发生妥协时限制爆炸半径。微隔离——创建小型的、隔离的网络区域——在自主环境中至关重要。如果一个智能体被破坏，攻击者不应该自动获得对其他一切的访问权限。

步骤5：持续监控智能体行为

使用CloudTrail（记录API调用）、GuardDuty（检测威胁）和行为分析等工具来检测异常。留意不寻常的模式：智能体突然访问它以前从未触及过的数据库、权限提升尝试，或可疑的跨智能体通信。机器学习可以帮助比人类更快地发现偏离正常行为的情况。

更大的转变

这里发生的是安全运作方式的根本性转变。机器身份正在呈指数级增长。云安全的未来不再仅仅是保护员工——而是管理以机器速度运行的自主系统。取得成功的组织将把AI智能体视为一等身份，具有动态授权、严格隔离、持续验证和实时行为监控。

如果公司未能将零信任原则扩展到自主智能体，他们就不是在现代化安全。他们是在自动化自己的漏洞。

结论

零信任架构是开创性的，因为它们挑战了网络边界内任何东西都是安全的这一假设。今天，它们再次受到挑战——不是来自外部攻击者，而是来自我们自己正在构建的自主系统。AI智能体是强大的工具，但如果没有适当的保障措施，力量就只是一种不同类型的漏洞。

优点

• 解决了一个真正的差距： 传统的零信任框架没有考虑到自主智能体，因此本指南填补了真正的安全需求。
• 切实可行的建议： 这些建议超越了理论，进入了具体的、可实施的实践（短期凭证、最小权限、隔离）。
• 提高意识： 许多部署AI智能体的组织尚未考虑这些风险；现在的这场对话很重要。
• 适用于各种平台： 无论您使用AWS Bedrock、Google Cloud还是其他云提供商，这些原则都适用。

缺点

• 实施开销大： 添加OIDC、工作负载身份联盟、多账户隔离和持续监控需要大量的工程工作和成本。
• 局限于云环境： 该指南假定使用AWS或类似的云基础设施；本地部署面临着不同的挑战。
• 监控复杂性： 实时行为分析需要复杂的工具和专业知识，而许多团队尚未具备这些。
• 未解决训练数据中毒问题： 重点是在运行时安全；模型和训练数据的安全是一个单独的（同样重要的）问题。

注意

本文具有教育意义，并基于2026年7月4日发表的一篇文章中讨论的安全实践。如果您计划实施这些建议，请在生产环境中依赖它们之前，对照当前的AWS文档、OWASP指南和NIST框架验证所有声明。安全架构应由您组织的安全团队进行审查，并根据您特定的风险状况和合规性要求进行调整。提到的技术、API和服务名称可能会发生变化。

常见问题

• 什么是零信任安全，它是如何工作的？
• AI智能体在网络内部能被完全信任吗？
• 什么是提示词注入，它是如何破坏AI智能体的？
• 与静态API密钥相比，短期凭证如何提高安全性？
• 什么是工作负载身份联盟，为什么AI智能体需要它？
• 团队如何监控AI智能体行为以发现安全异常？
• 被破坏的AI智能体的爆炸半径是多少？
• 传统的防火墙和网络安全工具能防御AI智能体攻击吗？

标签

#security #cloudcomputing #ai #iam #zerotrust #aws #agents