雷法埃尔·安吉尔，Akeyless联合创始人兼CTO – 采访系列

雷法埃尔·安吉尔，Akeyless联合创始人兼CTO，是一位网络安全和软件工程领域的领导者，具有丰富的云安全、加密、机器认证和企业基础设施经验。自2018年联合创立Akeyless以来，他帮助公司围绕现代密钥管理和云原生环境的身份安全建设。加入Akeyless之前，他曾在Intuit (INTU ) 担任安全高级软件工程师，负责构建公有云加密密钥管理和机器认证系统，获得了AWS、Go、Python、Java、PHP、Bash、Linux、Git和Jenkins的实践经验。早期，他在3D Systems (DDD ) 和Cimatron担任软件工程角色，使用C/C++、C#、WPF、MFC和面向对象设计模式开发CAD/CAM和Windows应用程序。

Akeyless是一家专注于通过云原生平台保护机器、AI代理和人类的身份安全公司。其平台集成了密钥管理、加密密钥管理、证书生命周期管理、特权访问和机器身份安全，提供了一个统一的方式来管理凭据、密钥、证书和访问权限，适用于混合、多云、DevOps和AI环境。该公司的定位反映了网络安全领域更广泛的转变：随着工作负载、服务和AI代理越来越多地在没有直接人类参与的情况下执行系统访问，企业需要对非人类身份、短期凭据、自动轮换和运行时治理施加更强的控制。

您在2018年在Intuit构建加密密钥管理和机器认证系统后联合创立了Akeyless。是什么样的云安全和身份管理缺口让您相信是时候开始Akeyless了？随着AI代理的出现，这一原始愿景如何演变？

在Intuit，我是负责构建加密密钥管理和机器认证系统的团队成员，当时Intuit是最早将业务迁移到云的企业之一。很明显，每个采用云的组织最终都会面临我们内部解决的问题：如何在分布式、动态的基础设施中管理密钥和凭据。构建这一功能需要大量的工程资源，而且没有必要让每家公司都重新发明轮子。合理的答案是SaaS模式。

但是，存在信任问题。这是企业最敏感的资产，没有哪家严肃的组织会将其数据的访问权交给第三方。因此，要求几乎是矛盾的：需要提供SaaS模式以实现规模和简单性，但同时需要从架构上确保供应商永远无法访问客户的数据。这种紧张关系正是分散式分段加密（DFC）的诞生原因。DFC允许我们运行一个完全托管的SaaS控制平面，而客户持有我们永远不会拥有的一部分，因此我们在数学上无法访问他们的密钥。这成为Akeyless建立的SaaS加零知识模型的基础。

最初的愿景是关于在云中保护人类和机器访问。AI代理是同一问题的自然且最极端的延伸。它们是非人类身份，以人类目录无法设计的规模和速度运行。同样的零知识、基于身份的基础现在直接扩展到它们。

您被誉为Akeyless专利的零信任加密技术的架构师。构建一个消除信任假设的安全模型的最大技术挑战是什么？

最困难的部分是让“不信任任何人”变得实际，而不是学术上的。大多数分割密钥或密钥共享方案仍然会在某个时刻组装完整的密钥，通常是在单个进程、HSM或执行加密操作时的瞬间。正是这个短暂的窗口是攻击者、内部人员和法律强制场景的目标。

使用DFC，密钥永远不会被组装，不是在创建时，不是在休眠时，也不在使用时。分段独立地在不同的信任域中生成，密钥操作作为分布式计算运行，每个分段持有者在本地计算其份额，只有部分结果交换。工程挑战是实现这一点，同时满足大型企业在生产环境中要求的延迟、吞吐量和可靠性。

另一个挑战，也是最重要的挑战之一，是实现分段的持续刷新。我们需要能够用新数学值替换每个分段，在每个位置，同时底层主密钥保持不变，密钥操作过程不会被中断。这为解决方案添加了大量的安全性。由于刷新，攻击者不再能够耐心地收集分段。上周捕获的分段与今天存在的分段在数学上无关，因此它是噪音而不是起点。要了解任何关于密钥的信息，攻击者必须同时在单个刷新窗口内、在所有分段位置、在所有信任域中以及在所有刷新频率增加的情况下破坏每个分段位置，这个要求随着位置、信任域和刷新频率的增加而指数级增加。结合所有或无的阈值，需要100%的分段才能揭示任何内容，任何严格的子集都会泄露零信息，刷新将安全模型从静态保证转变为基于时间的保证。

许多组织正在争相部署AI代理，但身份安全往往是事后才考虑的。公司在给AI代理访问企业系统和敏感数据时最常犯的错误是什么？

最大的错误是像对待服务帐户一样对待代理，并为其提供静态的长期API密钥。该凭据成为一个永久的、可收获的资产，位于一个非确定性、可注入提示的执行者内部。

我看到的其他常见错误是：授予代理静态权限，而不是仅限于即时访问；依赖粗糙的基于角色的权限，这些权限描述了代理可以访问的内容，但从不描述代理打算做什么；为代理提供直接的网络路径，以便访问数据库和API，这样一旦代理被破坏，就会导致横向移动；以及没有审计链来将代理的操作与触发它的提示和人类联系起来。每一个都是试图将人类时代的控制措施强加于一个不像人类的东西。

Akeyless认为AI代理需要一个与人类或传统机器工作负载不同的身份模型。是什么使AI代理与现有的IAM和PAM框架相比难以保护？

核心错误是将AI代理视为一种新的用户，或者甚至是一种新的服务帐户，并假设它们可以像人类身份一样被登记和管理。这种说法是错误的，原因有几个。

代理身份不可枚举。您想要管理的特定实例通常还不存在，一旦它存在，它就已经消失了。代理可以在Lambda上启动，运行800毫秒，然后在任何扫描器注意到之前消失，或者在VM、容器和无服务器环境中跨多个实例生成子代理。将这些代理注册到目录中就像对鬼魂进行登记一样：在条目提交之前，描述的实体已经消失了。

正确的锚点实际上是代理运行时已经颁发的工作负载身份，例如AWS执行角色、Kubernetes服务帐户令牌、SPIFFE SVID。该身份已经存在，由代理运行的平台认证，并且在代理消失时也会消失。由于身份是短暂的，唯一稳定的实体是可以在之间编写策略的认证方法和目标系统，而不是命名身份和范围。

这就是现有的IAM和PAM框架最严重破坏的地方：静态RBAC和ABAC无法包含非确定性执行者。具有完美范围的令牌和完美执行的TTL的代理仍然可以被注入提示，产生一个破坏性的查询，或者在同一个会话中从读取任务切换到写入任务，而不会在授权层面显示任何策略违规。RBAC和ABAC在认证时进行评估，而不是之后，因为之后发生的事情是由LLM根据策略作者无法看到的上下文窗口决定的。

因此，代理之所以难以保护，是因为它们是短暂的、非确定的、多子层的和可注入提示的。缺失的层不是一个更好的目录，而是在每个操作上进行意图感知的执行层，由一个检查代理实际执行的操作与它声称要执行的操作的网关进行中介，在任何凭据被铸造之前，并在会话结束时销毁凭据。这种网关还会对敏感数据进行会话内检查和响应屏蔽，以便在数据进入代理的上下文窗口之前对其进行编辑。

近期研究表明，AI代理可能已经在未经授权的情况下访问信息。组织在允许代理在生产环境中自主运行之前，应该具备哪些治理和运行时控制措施？

在任何代理自主运行于生产环境之前，我希望具备以下几点。首先，代理上没有静态凭据，每个会话都注入短暂的、即时的访问权限。其次，没有直接的网络路径，每个代理操作都通过强制的检查点进行代理，而不是直接访问数据库和API。第三，意图感知的策略执行会在任何凭据被铸造之前评估请求的目的与其原始提示。第四，在会话内进行检查和响应屏蔽，以便在代理的上下文窗口中编辑敏感数据，如PII和PHI。最后，一个单一的、不可变的审计记录将人类提示、分类意图、策略判决、会话和最终操作联系起来。

发现和可见性也很重要，但它们是输入策略的内容，而不是保护的先决条件。你应该能够在代理首次认证时对其进行管理，即使你以前从未见过该特定实例。

行业经常关注模型安全，但对身份、授权和访问控制关注较少。为什么您认为这些领域将成为AI时代最重要的安全挑战之一？

模型安全性占据了头条新闻，但一个完美对齐的模型仍然需要在现实世界中采取行动，而它采取行动的那一刻就需要访问系统和数据。访问是实际损害发生的地方。授权也是代理安全中最难的部分，因为执行者是非确定性的和短暂的。您无法仅在模型层面解决这个问题，也无法仅使用静态角色来解决。它需要在每个操作上进行持续的、意图感知的执行。这是一个不那么引人注目的基础设施工作，这也是为什么它被低估的，也是为什么它将成为这个时代最重要的安全问题之一的原因。

展望未来，您是否认为企业最终会需要一个专门为AI代理设计的身份层，类似于身份提供者如何成为人类用户的必备品？这种未来架构会是什么样子？

是的，但它不会像简单地为代理重新打造人类身份提供者模型那样。试图为代理构建一个目录就像为鬼魂构建一个目录一样，身份在你完成登记之前就已经消失了。

我预计的代理身份层将锚定到运行时颁发的工作负载身份，例如云IAM、Kubernetes服务帐户令牌、OIDC联合和SPIFFE/SPIRE等标准，这些标准已经被生产环境证明是可行的、跨子层的。授权将被表达为认证方法和目标系统之间的关系，而不是命名身份和范围之间的关系。重心将转移到运行时执行平面，即代理每个操作的网关，会对实际操作与声称的操作进行分类、注入短暂凭据、屏蔽敏感响应，并产生完整的法医链。身份仍然很重要，但它将在执行之后自然形成，而不是在执行之前。这种运行时权限层将坐在已经管理人类和机器访问的同一平台上，我相信每个在生产环境中运行代理的企业最终都会需要它。

感谢这次精彩的采访，读者可以访问Akeyless了解更多信息。