演讲者背景与 Venice AI 的隐私定位

本次分享由 Joshua Mo 主讲，他目前担任 Venice AI 的首席开发者关系工程师，负责合作伙伴、文档及开发者优先支持工作。Joshua Mo 曾是 Rust 语言中领先 AI 框架 Rig 的主要维护者，这一技术背景使他深刻理解底层架构对隐私的影响。Venice AI 定位为“私密且无限制的 AI 平台”，其核心承诺包括：托管最新开源模型、100% 兼容 OpenAI API，且绝不存储任何提示词（Prompts）或对话记录。平台提供 Web 应用及面向内容创作者的 Studio，涵盖视频、音频生成与转录功能。在隐私保护方面，Venice 强调默认私密（Private by Default）策略，针对 OpenAI 和 Claude等提供商，通过匿名化处理用户足迹，确保无法仅凭提示词识别具体用户。此外，平台采用隐私优先的软件架构，在可信执行环境（TEE）中托管模型推理过程，以提供可验证的隐私保证。对于视频生成等需拉取端点的场景，Venice 使用拆分密钥保管（Split Key Custody）技术对结果进行加密存储，确保即使团队账户被盗，攻击者也无法访问数据。

隐私泄露的风险与可观测性陷阱

数据泄露已成为必然事件，声誉风险至关重要。Joshua Mo 指出，“你只需要一次数据泄露，用户就会停止信任并转向其他提供商”，对于企业客户而言，这可能意味着失去贡献近 90% 年收入的支柱客户。敏感数据的存储会显著增加安全事件的影响范围，而减少直接存储用户数据则能缩小潜在的攻击面。然而，构建完整的 AI Agent 系统比单纯使用 LLM 更复杂，也更容易发生数据泄露。以可观测性（Observability）为例，虽然指标、日志和追踪是生产系统的核心调试工具，但默认情况下不当的日志记录可能意外存储提示词和密钥。Joshua Mo 强调：“如果你不小心，可能会默认存储包含个人信息的提示词和秘密。”Venice 通过架构设计避免了这一问题，但普通开发者需警惕日志中暴露的敏感信息。

Agent 架构中的秘密流动与泄露路径

Secrets（密钥/敏感信息）在常规 Agent 架构中极易通过 LLM 推理层泄露。Joshua Mo 以 OpenClaw 为例详细拆解了这一过程：用户请求进入 Agent 运行时后，系统可能从 Vault（如 OnePassword）获取密钥；该秘密随后被直接发送给 LLM 推理层，并通过工具调用（Tool Call）发起 API 请求。由于这种架构设计，“秘密被直接馈送到 LLM，这意味着它可能会被用于训练数据”。这种泄露路径揭示了传统 Agent 设计的致命弱点：为了执行任务，敏感凭证往往需要明文传递给模型，从而破坏了隐私边界。Joshua Mo 指出：“虽然模型是 AI 系统的重要组成部分，但它们只是整个流程的一部分。”构建围绕 LLM 的完整工作流时，必须解决数据在各个环节间的流动安全问题。

隐私保护模式：哈希、密钥分割与句柄设计

Venice AI 采用多种技术模式来阻断秘密泄露。首先，使用哈希值代替直接数据标识用户。例如，“为了速率限制目的识别用户时，存储其数据的哈希值而非直接个人信息”，这样既能唯一标识用户又保护了隐私。其次，采用拆分密钥保管（Split Key Custody）技术，“加密密钥被分为读取半部分和写入半部分”，攻击者因无法同时获取两半而无法解密数据。此外，引入句柄（Handles）设计模式，“句柄是授予访问权限的对象”，例如数据库池的访问权通过句柄管理，一旦撤销句柄即切断访问。这种模式特别适用于 JWT 或会话密钥等授权系统。工程化提示词设计也至关重要，Joshua Mo 建议“缩小 Agent 的作用范围以降低风险”，例如从 NCP 服务器获取工具时，仅加载必要的单一工具而非全部 15-20 个工具，从而减少 API Key 暴露给恶意 Web 服务器的可能性。

代理架构中的输入过滤与上下文优化

在构建AI代理系统时，除了设置专门的执行器（actor）外，还需要在代理前端部署分类层以检测提示注入等安全风险。实现这一目标有多种技术路径，可以使用基于大语言模型（LLM）的过滤层进行语义分析。另一种选择是引入语义搜索层，例如利用向量数据库（如Qdrant或LanceDB）进行检索匹配。此外，还可以采用内存处理进程（in-memory process）来即时验证输入内容。这种前置过滤机制对于保障代理行为的安全性至关重要，能够有效拦截恶意的提示词攻击。

除了安全防护，窄范围的代理作用域（narrow agent scope）所导致的紧密上下文循环也能显著提升性能。由于工具数量减少，代理能够更高效地运行。众所周知，当上下文窗口被填满并接近极限时，模型性能会出现显著下降。因此，保持上下文的空旷或近乎空状态是确保代理处于最佳表现的关键策略。通过限制工具调用和精简上下文，可以避免性能衰减，从而提升整体响应质量。

分离推理层与执行层以保护密钥安全

为了防止敏感信息泄露，关键在于将密码库（password vault）与代理运行时环境绑定，而非直接连接至推理层。在这种架构下，代理运行时本质上转变为执行层（execution layer），该层级具有确定性特征。这种分离使得在LLM层面因隐私和安全原因无法执行的操作，可以在执行层安全地进行。例如，当需要使用浏览器工具登录需要凭据的网站时，将凭证直接喂给推理层并调用外部API存在巨大风险。相比之下，这种软件架构使得数据处理更加合理且安全。通过隔离推理与执行，可以确保凭据不会暴露在具有非确定性输入的推理层中。

"By tying the password vault to the agentic runtime instead of the reasoning layer... we can consider it deterministic."

这种架构设计的核心优势在于将非确定性的推理过程与确定的执行过程解耦。推理层负责生成指令，而执行层负责安全地调用工具和访问资源。这种方式不仅提升了安全性，还允许在执行层实施更严格的隐私保护措施。对于需要处理敏感凭据的场景，这种分层架构是比直接将密码输入LLM更优的解决方案。

沙箱隔离与自主运行时环境的必要性

在代理安全领域，使用沙箱和虚拟机（如Firecracker、AWS EC2及VPC）已被证明能显著提升系统安全性。然而，沙箱并非万能药（cure-all）。如果代理启用了互联网访问权限且未谨慎配置，仍可能通过外部API意外泄露数据。因此，对代理的权限进行持续监控是不可或缺的安全环节。鉴于现有通用方案的局限性，构建自定义的代理运行时环境（agentic runtime）是更可靠的建议。这意味着开发者应拥有自己的代码执行框架，在其中集成自定义步骤、可观测性工具以及专用功能模块。

"My personal suggestion is building your own agentic runtime... Essentially owning the execution layer and reasoning layer."

通过自主掌控执行层和推理层，开发者可以实施更精细的安全策略。这种深度定制允许在代码层面添加特定的安全检查点，并实现端到端的可观测性。仅仅依赖外部的沙箱环境不足以应对所有威胁，特别是当代理需要与外部世界交互时。因此，构建内部化的、可控的执行环境是提升AI代理整体安全性的根本途径。这不仅包括代码层面的控制，还涉及对工具调用权限的严格管理。

硬件级机密计算与端到端加密挑战

在硬件层面，机密计算（confidential compute）技术通过可信执行环境（TEE）实现了推理过程的隐私保护。以Venice为例，当用户发送请求并获得响应后，系统会返回一个证明（attestation）。用户可以通过验证器核实该证明，从而在密码学层面完全隔离代理的推理层。TEE技术在工具调用方面表现良好，但仍有一些工作亟待完成。尽管提供了端到端加密功能，但在提供用户友好的API体验的同时实现完全加密的工具调用仍是一个持续的挑战。目前较为可靠的解决方案是允许提供商拥有运行工具调用的计算层，但这仍在探索和优化阶段。

"Confidential compute where a trusted execution environment essentially at the hardware level enables the inference process to be run privately."

当前技术的主要瓶颈在于平衡安全性与易用性。虽然TEE提供了强大的隔离能力，但如何在保持API简洁性的同时确保工具调用的完全加密仍需突破。端到端加密的落地难度在于复杂的密钥管理和验证流程。尽管存在挑战，硬件级的机密计算仍是保护AI代理隐私的重要方向。未来的发展将集中在简化证明验证流程以及优化加密工具调用的用户体验上。

结论

Venice AI 通过架构解耦与硬件隔离，构建了抵御 Agent 隐私泄露的多层防线。其核心优势在于将确定性执行层与非确定性推理层分离，结合 TEE 机密计算与拆分密钥保管技术，从根源阻断了敏感凭证进入 LLM 的路径。配合哈希标识、句柄管理及前置过滤机制，有效缩小了攻击面并提升了系统可观测性。

然而，该方案并非万能。沙箱隔离无法完全消除外部 API 交互带来的泄露风险，且端到端加密工具调用在易用性上仍面临挑战。因此，构建自主可控的执行层、实施最小权限原则及持续监控，是确保 AI Agent 安全落地的必要前提。