Jentic联合创始人兼首席执行官Sean Blanchfield访谈系列

肖恩·布兰奇菲尔德Jentic联合创始人兼首席执行官是一位连续创业家，拥有数十年的大型软件和基础设施公司建设经验。他常驻都柏林，目前领导Jentic，同时也是爱尔兰人工智能咨询委员会成员，为政府提供人工智能政策方面的建议。在其职业生涯早期，他联合创立了DemonWare，这是一个面向大型视频游戏发行商的大规模在线服务平台，后被动视暴雪收购；他还联合创立了PageFair，这是一家专注于广告拦截分析的风险投资支持的初创公司，后被Blockthrough收购。此外，他还创立或领导过多家初创公司，并通过Techpreneurs等项目持续支持爱尔兰的创业生态系统。

詹蒂克 Jentic 正在开发一个通用集成层，旨在帮助 AI 代理安全地与企业系统和 API 进行交互。该平台使组织能够将 AI 模型与内部工具、外部服务和运营工作流程连接起来，同时保持治理、身份验证和监督。通过将分散的 API 转换为 AI 代理可以可靠使用的结构化接口，Jentic 旨在帮助企业在复杂的软件环境中大规模部署 AI 驱动的自动化。

您曾创立并领导过多家科技公司，从 DemonWare（已被动视暴雪收购）到 PageFair，再到现在的 Jentic，您同时也是爱尔兰人工智能咨询委员会的成员。是什么促使您再次投身基础设施建设，创立了 Jentic？您认为新兴的人工智能代理生态系统存在哪些其他人忽略的空白？

当你第三次注意到某种模式时，就必须认真对待了。在 DemonWare 大会上，大家都在谈论在线多人游戏——但真正的难题在于其底层的网络基础设施。人工智能代理也面临着同样的问题。模型本身非常出色。瓶颈在于集成层——一直以来都是如此。人工智能代理运行在 API 上，而这些 API 是为人类设计的：文档编写面向人类，安全措施面向人类，结构也面向人类。如果让一个自主代理直接对接这些基础设施，很快就会崩溃。企业级人工智能试点项目失败并非因为模型误解了任务，而是因为代理无法可靠地连接到所需的系统。生成式人工智能提供了一种新的解决方案——将集成视为一个知识问题，而非编码问题。正是这种洞察吸引了我。

2024 年你创立 Jentic 时，代理安全从一开始就是主要论点吗？还是随着你观察到各组织如何在生产环境中实际部署自主代理，才逐渐明确了重点？

我首先想到的就是凭证问题。我设想代理数量激增，每个代理都需要数十个系统的凭证，所有这些密钥都会流入LLM上下文窗口，然后被窃取——简直一团糟。解决方案和二十年前一样：集中化身份验证和授权。但沿着这条思路走下去，立刻引出了下一个问题：如果使用传统的集成工具进行集中化，就又回到了静态连接器的时代，而代理并非静态的。最终让我确信的是，能力发现应该与访问控制紧密结合——只有代理真正获得授权才能使用某个能力，而且提供发现功能的系统也可以成为唯一的执行点和可观察点。

近期大量面向互联网的代理实例被曝光，凸显了编排和凭证通常共享同一信任边界的问题。从您的角度来看，这种模型的核心架构缺陷是什么？

缺陷很简单：代理（一个运行来自LLM的指令的系统）同时也是持有凭证并发起API调用的系统。一旦代理被攻破，它就能执行所有操作。这和我们早期Web时代犯的错误如出一辙——为了方便，应用服务器被赋予了超级用户数据库访问权限。Jentic作为代理和它调用的API之间的中间层。代理本身并不持有凭证。它通过我们托管的执行层发出请求，该执行层会在服务器端注入凭证、强制执行策略并记录每次调用。而且，一旦出现问题，只需一个“终止开关”——一个操作即可同时停止该代理在所有连接系统中的访问权限。

您曾提到将编排与执行分离以控制影响范围。您能否用实际例子解释一下，当实例遭到入侵时，这种分离会如何改变风险状况？

在扁平化模型中，LLM（逻辑层管理）负责推理并直接使用其持有的凭证调用 API。一旦推理层被攻破，执行层就会被控制。而采用分离式架构后，LLM 会发出一个意图——“使用这些参数调用 Stripe 计费 API”——由受管执行层根据策略验证该请求，在服务器端注入凭证，然后执行调用。LLM 本身不会触及凭证。实际应用中：横向移动变得更加困难，攻击范围受限于执行层对特定代理身份的权限，并且还增加了一个“终止开关”。只需切换一次，代理在所有连接系统中的访问权限就会被终止。代理仍然可能被操控——但操控不再意味着凭证的完全泄露。

在实际的企业部署中，集中式凭证管理和即时撤销究竟是什么样的？它与大多数团队目前处理代理 API 密钥和令牌的方式有何不同？

如今，大多数团队都由开发人员配置 API 密钥，将其存储在 .env 文件中，并在代理启动时加载——通常是直接加载到 LLM 的上下文窗口中。没有人能完全掌握哪些代理持有哪些凭据。当有人离职时，他们配置的密钥不会轮换。当代理出现异常行为时，没有审计跟踪可以重现问题所在。而使用 Jentic，开发人员无需处理原始凭据。他们只需声明代理所需的访问权限，平台会配置范围化的访问权限，代理通过我们的执行层调用 API，而无需接触底层密钥。这意味着您可以立即撤销每个代理的访问权限，在调查期间暂停访问，并获得每次 API 调用的时间戳审计跟踪。这与“API 密钥存储在 .env 文件中”截然不同。 .“env 文件”非常重要。

许多团队正在销售、工程和数据科学等领域尝试使用代理框架。随着企业从实验阶段过渡到生产阶段，您观察到的最常见的安全失误有哪些？

同样的模式反复出现：权限过高的代理仍然使用原型设计时设置的管理员凭据运行；凭据通过提示或上下文窗口传递，最终出现在日志、遥测数据以及潜在的训练数据中；多个代理实例共享凭据，导致无法隔离单个恶意行为者；没有终止开关来在不影响整个系统的情况下停止代理；没有真正意义上的审计跟踪；提示注入攻击未被重视——尽管任何读取电子邮件、处理文档或浏览网页的代理都会遇到恶意构造的内容。共同点在于，这些团队当初构建系统时只考虑了理想情况，而现在却发现生产环境大多是问题重重的。

Jentic 将自身定位为位于代理框架和外部系统之间的托管执行层。这个中间层如何在不减慢开发人员速度或降低代理灵活性的情况下实施治理？

开发者无需将代理连接到五十个不同的 API（每个 API 都有各自的身份验证方案、速率限制和特性），只需连接到一个统一的端点。该端点提供工具，用于搜索我们完整的 API 功能目录、加载详细信息并执行任何调用。这通过单一的统一接口访问无限的 API，最大限度地提高了灵活性，同时实现了有效的治理——哪些代理在什么条件下、以什么限制访问哪些 API——所有这些都在平台内管理，而不是在客户端代码中管理。执行层是直通的；代理仍然可以构建多步骤工作流、链接调用并动态处理错误。实现无摩擦的治理并非易事。捷径是将负担转嫁给开发者。但基础设施应该反其道而行之——承担这些复杂性，让开发者无需为此操心。

鉴于信息窃取恶意软件现在积极攻击代理配置文件和存储的凭据，您是否认为攻击者会将注意力转移到人工智能基础设施上，将其视为一个新的高价值攻击面？

没错——而且逻辑显而易见。代理配置文件实际上是一个多服务超级密钥：它包含了电子邮件系统、CRM、计费平台、内部API和GitHub帐户的凭据。一次成功的窃取信息攻击就能让攻击者获得长达数月的整个公司外部系统访问权限。这比单独攻击任何一项服务带来的收益要高得多。另一个方面是，在生产环境中持续运行的代理是持久的、拥有凭据的存在——而不是像用户那样登录和注销。被攻破的代理可以作为长期立足点，在检测阈值以下运行。令人不安的现实是，攻击面的扩展速度超过了防御工具的更新速度。Jentic可以显著缩小凭据攻击面，但我们无法阻止代理滥用其被授予的权限范围。这个更棘手的问题需要在模型层面解决，通过设置防护机制和及时注入检测来实现。

除了任何单一框架之外，如果组织想要安全地大规模部署智能体人工智能，应该采取哪些更广泛的安全原则？

大多数受监管的组织无法将非确定性系统部署到其最有价值的业务流程中。银行或保险公司不能让一个自主代理访问其计费系统，然后说“自己去摸索”。那么，如何在不让风险成为阻碍的情况下进行创新呢？答案是沙盒。创建一个与您的 API 环境具有相同结构和工作流程的数字孪生，但没有生产环境的凭据或后果。在沙盒中部署代理，让它们探索，观察结果。成功的路径会被记录为结构化的、确定性的工作流程自动化，并使用 Arazzo（OpenAPI Initiative 开发的开放式工作流程规范）进行管理——任何合规团队都可以对其进行审计、重复和审查。这意味着您可以在沙盒中以 AI 的速度运行，在生产环境中以企业级的速度运行，并且这两种模式可以共存。其他原则仍然适用——最小权限原则、审计跟踪、终止开关、编排与执行分离。但沙盒为企业团队真正遇到的问题提供了一个结构化的解决方案：我们如何在不影响合规性的前提下尝试非确定性 AI？你不会直接运用非确定性，而是在受控条件下从中提取价值，并且只运用确定性的输出结果。

感谢您的精彩采访，想要了解更多信息的读者可以访问 詹蒂克.