据TechRadar报道，Teleport首席执行官近日撰文指出，自主AI代理已开始运行在核心基础设施中，执行代码、应用策略和管理DevOps功能，但许多项目却因安全模型问题而停滞。这些安全模型是为过去“两个角色”的世界构建的，如今无法适应AI代理这一新角色。文章援引实例称，一个代理曾在九秒内删除了一家公司的整个生产数据库及其备份，安全团队正在用过时工具应对此类风险。
文章认为，AI代理与机器不同，它们像人类一样容易出错且具有非确定性，但运行速度却达到机器级别，且全天候工作。现有身份系统只区分人类和机器，而AI代理是第三类角色。将代理塞进旧系统，会使每个代理成为潜在入侵点，并能以秒级速度在基础设施中执行数千项操作。工程师们被要求用老旧的IAM工具阻止灾难性场景，但裂缝已经显现。
身份碎片化问题长期困扰着使用Kubernetes集群、云平台、CI/CD流水线和数据库的工程师。对人类员工来说，这种碎片化尚可管理，因为人类登录登出可追踪，速度慢到可见性缺口很少立即引发事故。但代理AI出现后，速度被拉到极限，团队被海量活动日志淹没，却缺乏在代理执行未经授权的更改前有效遏制其行为的能力。
文章警告，为第三种身份类型创建新工具是最糟糕的行业反应，那将让工程师从头重建身份策略，并引入更大的匿名性，反而使攻击者更难被捕获。解决之道不是增加技术栈或实施更多工具，而是改变身份模型，彻底消除匿名性。为此，必须赋予每个行动者——人类、机器、工作负载和AI代理——一等身份，并以硬件信任根进行加密保护。还应彻底抛弃静态凭证，消除导致数据泄露的凭证蔓延以及密钥被盗或交予错误行动者的威胁。
强认证本身并不足够，AI代理也需遵守零信任原则。文章建议用统一基础设施层取代孤立系统，使代理与运行它们的机器和授权它们的人类拥有完全相同的身份类型。代理应使用短期特权，这些特权限定于人类用户授权的具体动作，特权附着于动作而非行动者。例如，生成代码的代理必须从具有匹配权限的人类所有者那里继承授权，权限仅限该任务所需的特定数据表。非确定性行动者还需要受信任的执行环境，以便在遵守安全边界的前提下运行。