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

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

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

您曾创立和领导过多家技术公司，从DemonWare（被动视暴雪收购）到PageFair，现今的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，OpenAPI倡议内部开发的开放工作流规范——可审计、可重复、可由任何合规团队审查。这意味着您可以在沙盒中以人工智能的速度移动，在生产中以企业的速度移动，这两种模式共存。其他原则仍然适用——最小特权、审计跟踪、杀死开关、编排与执行的分离。但是，沙盒是企业团队实际陷入的结构性答案：如何在不将合规态度押注于它的情况下进行非确定性人工智能的实验？您不部署非确定性。您在受控条件下从中提取价值，并仅部署确定性输出。

感谢您接受这次精彩的采访，希望了解更多的读者可以访问Jentic。