Vin Sharma，Vijil 联合创始人兼首席执行官——系列访谈

Vin Sharma是 Vijil 的联合创始人兼首席执行官，在网络安全、开源、云计算和 AI 基础设施领域拥有超过 30 年的经验。在创立 Vijil 之前，他曾在 AWS 负责 Amazon SageMaker 和 Amazon Bedrock 的深度学习工程工作，在 Intel 开发数据中心基础设施，并在 Hewlett-Packard 担任产品和工程职务。他的职业生涯始于针对可信 UNIX 系统的自动化红队测试；这段经历奠定了他的关注重点：让企业 AI 智能体变得可靠、安全且无害。

Vijil为企业 AI 智能体提供信任基础设施，帮助组织评估智能体的行为、实施管控，并提升其在整个生命周期中的韧性。其方法结合测试、安全防护和持续反馈，使智能体的行为符合组织的预期目的和政策。在本次访谈中，Sharma 谈到了如何定义和衡量信任、智能体测试为何有别于传统软件安全，以及随着智能体自主性不断增强，企业需要怎样的监督机制。

在创立 Vijil 之前，您曾在 AWS、Intel 和 Hewlett-Packard 等公司工作，累计超过 30 年。究竟是什么让您确信，AI 信任与安全是一个足够重大、尚未解决的问题，值得为此创立一家公司？

30 年前，在加入一家安全初创公司之前，我还在研究生院学习 AI 和机器学习。此后，我参与过多个产品团队的工作：为基于 Unix 和 Linux 的操作系统构建军用级安全防护，为网上银行打造安全 Web 服务器，为云计算开发可信执行环境，将加密技术融入数据分析平台；最近，我又回到了起点，在 AWS 构建可用于企业的 AI/ML 服务。这段经历让我坚信，为智能系统建立信任，比构建智能系统本身更具挑战性。AI 行业似乎普遍致力于提升智能体的能力，但我认为，我们也需要投入同等资源，为智能体构建可扩展的监督和控制机制。如果没有针对特定组织需求设计的这些衡量指标和机制，最初那波热情高涨的应用浪潮终将搁浅在风险与投资回报率的浅滩上，因为企业将无法证明智能体确实在为自身利益行事。

Vijil 的核心理念是，许多 AI 智能体之所以无法投入生产，是因为企业无法充分验证其可靠性、安全性和无害性。随着企业将 AI 从原型推进到生产部署，您观察到最大的信任缺口出现在什么地方？

随着智能体自主性不断增强，部署更多智能体所面临的瓶颈在于：组织能否明确规定智能体的预期行为，并验证智能体是否按预期行事。不仅如此，组织还必须能够以适应智能体运行规模和速度的方式完成这项工作。因此，我们显然需要一种方法，让智能体能够衡量和调整其他智能体的行为。最大的两个缺口之一是，不知道该衡量什么（对于智能体而言，什么才算好）；另一个是，不知道该调整什么（为了引导智能体呈现其委托方所期望的行为，应当调整智能体系统的哪些组成部分：模型及其参数、系统提示词、用户指令、智能体运行框架，还是多智能体系统的图结构）。

Vijil 如何定义和衡量 AI 智能体的“信任”？在判断智能体是否已准备好在企业环境中运行时，哪些信号或基准最为重要？

我们将信任定义为：委托任务给自主智能体所带来的预期收益，扣除智能体背离我们意图所造成的风险。也就是说，如果智能体在正常、有噪声和恶意环境下都能正确行事，并且在发生故障时能将影响范围降至最低，我们就可以信任它。接下来，我们可以从三个支柱衡量信任：可靠性、安全性和无害性。可靠的智能体能在各种条件下按预期执行任务；安全的智能体能在恶意条件下按预期执行任务；无害的智能体则能够最大限度地降低业务、法律和技术风险。

AI 智能体结合了模型、工具、数据源、记忆和外部系统，因此其行为可能难以预测。智能体测试与传统的应用安全测试或常规模型评估有何不同？

传统软件的失效方式如今已相当为人熟知：概括来说，包括无法处理格式错误的输入、逻辑和系统设计上的弱点、实现中的漏洞、攻击者可能利用的隐蔽漏洞，以及输出造成的意外副作用。对这些失效情况进行测试，其结果具有相当高的可预测性。智能体则大幅扩大了失效面，甚至扩大到模型评估、单元测试、集成测试、应用安全测试、渗透测试和合规检查都无法从根本上覆盖的程度。要测试智能体带来的新风险面，我们需要新的衡量指标和机制，根据委托方规定的智能体用途、用户的不同角色，以及智能体运行所在组织、行业和地区的政策，对智能体行为进行评估。

您曾领导 Amazon SageMaker 和 Amazon Bedrock 的深度学习工程工作。在 AWS 构建 AI 基础设施的经历中，哪些经验对您在 Vijil 推进智能体安全与可靠性的方式影响最大？

最让我受益匪浅的一点是：在开发周期早期发现服务在可靠性、安全性和合规性方面的问题，远比等到发布前夕（这是过去的惯常做法）才发现有效、也高效得多；更糟的是，如果等到服务投入生产后才发现，就意味着一觉醒来便接到电话，得知服务出了故障。

Vijil 不仅专注于在智能体部署前进行测试，也致力于在其投入生产后提供防护并持续改进。智能体开始与真实用户、数据和企业系统交互后，哪些风险才会显现？

现实世界总能以无穷无尽的方式带来意外，而受到意外冲击的智能体就容易出错。智能体生成表情包时犯错，无关紧要。但如果智能体旨在协助或取代财务顾问、律师助理、律师、护士、医生、患者，或任何必须证明自身履行了受托责任的行业从业者，那么除非严格界定容错范围、谨慎监控，并迅速纠正智能体的行为，否则它就无法正常运行。

随着企业部署越来越自主、能够采取行动而不只是生成回复的智能体，安全模型需要如何演进？权限、身份和访问控制等传统概念是否足够？

不够。随着智能体成为组织中的行动主体，必须为其分配可验证的唯一身份；为其设定角色，既约束其行为，也约束其功能组件（即拥有资源访问权限的工具），并配套强制访问控制策略；持续监控其是否偏离预定用途；同时引导其在遭受攻击时保持韧性。

Vijil 从 600 万美元的种子轮融资发展到 1700 万美元的 A 轮融资，组建了一支约 20 人的创始团队，并实现了首个 100 万美元的年度经常性收入。在从早期技术构想迈向商业应用的过程中，哪些决策最为关键？

我们很早就决定构建一个信任层，使其能够与客户选择的平台集成；同时，我们也预见到，企业会越来越希望在采用开放模型的多智能体系统方面获得更高程度的定制、更精细的控制和更低的成本。长期来看，打造平台层而非单一产品能带来相对优势，但也会带来挑战：要找到已准备好大规模实施智能体治理的企业，并不像销售一种直接迁移服务那么容易。

您于 1995 年开启职业生涯，为可信 UNIX 系统开发自动化红队测试。近三十年后，当被测系统变成能够推理、适应环境并使用外部工具的 AI 智能体时，红队测试的原则发生了哪些变化？

传统上，红队测试是指检验组织抵御协同攻击的能力。其基本原则至今仍然适用。我们仍需在受控条件下协同发起攻击，以探查受测组织的弱点。然而，在红队演练中通过预设脚本来测试软件系统的那段时期已经过去，这种方法不再够用，因为 AI 智能体并非确定性软件——它们旨在适应所处环境，因此无法以可预测的方式重复同一种攻击。我认为，智能体应当被视为企业。由此，智能体红队测试必然需要根据智能体的用途调整测试方式，探查其行为是否偏离用户意图，以及它是否愿意并有能力规避其所处环境的策略。

展望未来，您认为独立测试和可量化的 AI 智能体可信度标准会成为企业部署的先决条件吗？要让这种保障水平成为行业标准实践，全行业还需要采取哪些行动？

如今，开发者会评估智能体的能力，红队会测试其抵御提示注入和越狱攻击的能力，而 GRC 团队才刚开始测试其是否符合相关法规。很少有组织建立行为验证机制，在智能体的整个生命周期中持续于后台运行，即使模型、工具、资源、工作流和目标环境发生变化，也不间断地进行验证。更重要的是，Vijil 能够以独特的方式帮助企业，将智能体在生产环境中的实际行为追溯到其规范，并通过反馈循环持续改进智能体。能够在攻击中幸存下来的智能体，正是那些会通过适应来保持韧性的智能体。

感谢您接受这次精彩的采访。希望进一步了解企业 AI 智能体的测试、防护和持续改进的读者，请访问 Vijil。