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

Sean Blanchfield，Jentic联合创始人兼首席执行官，是一位拥有数十年经验的科技创业者，曾创建过多家大规模软件和基础设施公司。现居都柏林，他目前领导Jentic，同时还担任爱尔兰人工智能咨询委员会成员，为政府提供人工智能政策建议。在早期职业生涯中，他联合创立了DemonWare，一家为主要视频游戏发行商提供的高规模在线服务平台，后被动视暴雪收购；他还联合创立了PageFair，一家专注于广告屏蔽分析的风险投资初创公司，后被Blockthrough收购。他还创立或领导过多家初创公司，并通过诸如Techpreneurs等举措继续支持爱尔兰的初创生态系统。

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

您创立并领导了多家科技公司，从DemonWare（被动视暴雪收购）到PageFair，现今的Jentic，并且您还担任爱尔兰人工智能咨询委员会成员。是什么吸引您回到基础设施层，创立Jentic？您在新兴人工智能代理生态系统中看到哪些空白，其他人又忽略了什么？

当你第三次注意到一个模式时，你必须认真对待它。在DemonWare，每个人都在谈论在线多人游戏——但真正困难的是底层的网络基础设施。同样的事情正在发生在人工智能代理身上。模型非常出色。瓶颈在于集成层——一直都是这样。人工智能代理运行在API上，这些API是为人类设计的：为人类编写文档、为人类提供安全保障、为人类结构化。将一个自治代理指向这种基础设施，它很快就会崩溃。企业人工智能试点不会因为模型误解任务而失败；它们失败是因为代理无法可靠地连接到所需的系统。生成式人工智能提供了一种新的解决方案——将集成视为知识问题，而不是编码问题。这种洞察力吸引了我。

您在2024年创立Jentic时，代理安全是首要假设，还是随着您观察组织在生产中实际部署自治代理而变得更加清晰？

第一个线索我拉出来的是凭证。我想象代理正在扩散，每个代理需要数十个系统的凭证，所有这些秘密流入LLM上下文窗口，被泄露——一团糟。答案与二十年前一样：集中认证和授权。但是拉动这个线索直接导致了下一个问题：如果使用传统集成工具集中，回到静态连接器的领域，代理不是静态的。什么巩固了愿景是认识到能力发现应该紧密耦合到访问控制——代理应该只被提供它实际被授权使用的功能，而且提供发现的系统也可以成为单一的执行和可观察性点。

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

缺陷很简单：代理——一个运行LLM提示的系统——也是持有凭证并进行API调用的系统。破坏代理，您就能获得它能做的一切。我们在早期网络时代犯了同样的错误——应用服务器具有超级用户数据库访问权限，因为这样很方便。Jentic作为代理和API之间的层。代理永远不会持有凭证。它通过我们的托管执行层发出请求，该层注入凭证、执行策略并记录每个调用。当出现问题时，有一个单一的杀死开关——一个操作可以同时停止代理对所有连接系统的访问。

您谈到了分离编排和执行以包含爆炸半径。可以解释一下这种分离如何在实例被破坏时改变风险状况吗？

在平面模型中，LLM推理要做什么并直接使用它持有的凭证调用API。破坏推理层，您就控制了执行层。通过分离，LLM发出一个意图——“调用带有这些参数的Stripe计费API”——托管执行层验证该请求针对策略，注入凭证并进行调用。LLM永远不会触摸凭证。在实践中：横向移动变得更加困难，爆炸半径由执行层为特定代理身份允许的内容所界定，您还获得了一个杀死开关。一个切换，代理的访问在每个连接的系统上都停止。代理仍然可以被操纵——但操纵不再自动意味着完整的凭证泄露。

在现实世界的企业部署中，集中凭证管理和即时吊销实际上是什么样子，它与团队目前如何处理代理的API密钥和令牌有何不同？

今天，大多数团队都有开发人员在API中提供密钥，将它们存储在.env文件中，并在代理启动时加载它们——通常直接加载到LLM的上下文窗口中。没有人对代理持有的哪些凭证有完整的了解。当有人离开时，他们提供的密钥不会被轮换。当代理表现异常时，没有审计跟踪来重现发生了什么。使用Jentic，开发人员永远不会处理原始凭证。他们声明代理需要什么访问权限，平台提供范围访问，代理通过我们的执行层调用而无需看到底层密钥。这意味着您获得每个代理的即时吊销，暂停访问的能力以及每个API调用的时间戳审计跟踪。这种差异与“API密钥在.env文件中”是显著的。

许多团队正在销售、工程和数据科学领域尝试代理框架。您看到组织从实验到生产转变时，最常见的安全失误是什么？

相同的模式反复出现：过度授权的代理仍在运行于它们原型时使用的管理员凭证；在提示或上下文窗口中传递凭证，凭证最终出现在日志、遥测和潜在的训练数据中；多个代理实例共享凭证，因此您无法隔离单个恶意代理；没有杀死开关来停止代理而不关闭整个系统；没有值得称赞的审计跟踪；以及提示注入不被认真对待——尽管任何读取电子邮件、处理文档或浏览网络的代理都会遇到对手方精心制作的内容。共同的线索是这些团队为快乐路径构建，并现在发现生产主要是悲伤的路径。

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

开发人员不需要将代理连接到50个不同的API，每个API都有自己的身份验证方案、速率限制和怪癖。开发人员连接到一个端点。该端点提供工具来搜索我们的整个API功能目录、加载详细信息并执行任何调用。这最大限度地提高了通过单一统一接口访问无限API的灵活性，同时实现治理——哪些代理访问哪些API，在什么条件下，什么限制——所有这些都在平台中管理，而不是在客户端代码中。执行层是一个传递层；代理仍然可以组合多步骤工作流、链式调用和动态处理错误。无摩擦的治理很难实现。捷径是将负担推给开发人员。基础设施应该做相反的事情——吸收这种复杂性，这样开发人员就不必这样做。

随着信息窃取恶意软件现在积极针对代理配置文件和存储凭证，是否认为攻击者将重点转向人工智能基础设施作为新的高价值攻击面？

绝对如此——逻辑很明显。代理配置文件本质上是一个多服务超级密钥：电子邮件系统、CRM、计费平台、内部API和GitHub帐户的凭证。一次成功的信息窃取运行可以在整个公司的外部系统中获得数月的访问权限。这比单独针对任何一个服务具有更高的回报率。另一个维度是，持续在生产中运行的代理是持久的、凭证化的存在——不是用户登录和注销。一个被破坏的代理可以作为长期的攻击平台，在检测阈值以下运行。令人不舒服的现实是，攻击面正在比防御工具更快地演变。Jentic可以显著减少凭证攻击面，但我们无法防止代理滥用已被授予的范围。这个更难的问题需要在模型级别解决，使用防护栏和提示注入检测。

超越任何单一框架，组织如果希望在规模上安全地部署代理人工智能，应该采用哪些更广泛的安全原则？

大多数受管理的组织无法将非确定性系统部署到其最有价值的业务流程中。银行或保险公司不能将一个自治代理指向其计费系统并说“去弄清楚”。那么，如何在不让风险态度成为制动器的情况下创新？答案是沙盒。创建API资产的数字孪生，具有相同的结构和工作流，但没有生产凭证或后果。将代理部署在那里，让它们探索，观察发生了什么。成功的路径被捕获为结构化的、确定性的工作流自动化，使用Arazzo，开放API计划内开发的开放工作流规范——可审计、可重复和可由任何合规团队审查。这样，您可以在沙盒中以人工智能速度移动，在生产中以企业速度移动，这两种模式共存。其他原则仍然适用——最小权限、审计跟踪、杀死开关、编排与执行的分离。但是沙盒是企业团队实际陷入的结构性答案：如何在不将合规态度押注于其上的情况下尝试非确定性人工智能？您不部署非确定性。您在受控条件下从中提取价值，并仅部署确定性输出。感谢您这次精彩的采访，希望了解更多的读者可以访问Jentic。