Excalidraw AI防止敏感信息泄露的设计

Excalidraw AI 防止敏感信息泄露的设计

在当今的远程协作环境中，AI 正以前所未有的速度渗透进我们的工作流。从自动生成会议纪要到一键绘制系统架构图，智能辅助看似提升了效率，却也悄然埋下了数据泄露的风险。尤其是在技术团队频繁使用白板工具设计系统、绘制流程图的场景下，一句“帮我画个微服务架构”可能就包含了认证逻辑、数据库结构甚至内部域名——这些内容一旦被传入第三方大模型服务，后果不堪设想。

Excalidraw 的出现，提供了一种截然不同的思路：它没有选择将 AI 功能作为云端黑箱服务强加给用户，而是构建了一个以用户控制为核心、隐私优先的开放架构。这种设计不是简单的功能取舍，而是一次对“谁拥有数据、谁掌控决策”的深刻回应。

从“默认上传”到“主动选择”：重新定义 AI 辅助的信任边界

大多数带 AI 功能的绘图工具都遵循一个隐含假设：用户的输入会自动发送到厂商的服务器进行处理。这个过程往往是静默的、不可逆的。你点击按钮，内容就走了，至于去了哪里、存不存在日志、会不会用于训练，普通用户无从知晓。

Excalidraw 打破了这一范式。它的 AI 模块本质上是一个插件化的请求转发器，而非内置服务。当你在界面上输入一段描述并触发 AI 生成功能时，系统不会立即行动，而是停下来问你：“你想用哪个后端？”选项通常只有两个：你自己部署的本地模型，或者你自己配置的远程 API（比如你个人账户下的 OpenAI 密钥）。

这意味着什么？意味着Excalidraw 自身不接收、不存储、也不转发任何数据——它只是把你的指令，按你指定的方式，发给你信任的目标地址。整个过程中，平台方没有任何中间介入的机会，自然也就无法成为数据泄露的源头。

这种“零默认追踪”的设计理念贯穿始终。即使是官方演示站点excalidraw.com，其主应用中也完全不包含 AI 插件代码，除非你主动访问/ai路径或手动安装扩展。这不仅减少了攻击面，更是一种明确的心理暗示：启用 AI 是一项需要深思熟虑的操作，而不是随手一按就能完成的功能。

如何实现真正的“数据不出内网”？

很多人说“我们支持私有化部署”，但真正能做到“数据闭环”的并不多。Excalidraw 的关键在于，它把 AI 推理能力的归属权彻底交还给了用户。

你可以将整个工作流部署在企业内网：

• 前端界面运行在内部 Web 服务器上；
• 后端 AI 推理由 Ollama、Llama.cpp 或 Hugging Face Transformers 等开源框架承担，部署在专用 GPU 节点；
• 用户通过浏览器访问内部实例，所有通信均在防火墙之内完成。

在这种模式下，哪怕是最敏感的系统拓扑图生成请求，也不会跨越组织边界。原始文本不会出现在公网流量中，响应结果也不会被记录在外部日志里。这就是所谓的“空气间隙”（air-gapped）环境下的 AI 协作——听起来像是理想主义，但在 Excalidraw 上已经成为现实。

而且，由于项目采用 MIT 开源许可证，任何人都可以审查packages/excalidraw-ai中的网络请求逻辑。有没有偷偷上报 telemetry？是否硬编码了某个监控 endpoint？这些问题不再依赖厂商的承诺，而是可以通过代码审计来验证。这种透明性本身就是一种强大的安全保障。

安全不只是功能，更是架构与细节的总和

Excalidraw 的防护机制并非仅靠“本地运行”这一点撑起全局，而是在多个层面叠加了纵深防御策略。

首先是运行时隔离。AI 功能作为一个独立插件动态加载，主应用只关心最终输出的图形数据（如 Mermaid 字符串或 JSON 结构），并不参与自然语言的理解与解析。这种职责分离确保了即使插件层存在漏洞，核心绘图模块也不会受到影响。

其次是内容安全策略（CSP）的严格实施。以下是一个典型的 CSP 配置片段：

<meta http-equiv="Content-Security-Policy" content=" default-src 'self'; script-src 'self' 'unsafe-inline'; connect-src 'self' http://localhost:11434 https://api.openai.com; img-src 'self' blob: data:; style-src 'self' 'unsafe-inline'; ">

这段策略明确规定了哪些外部资源可以被加载。例如，connect-src列表中只允许连接本地 Ollama 服务（默认端口 11434）和 OpenAI API。如果你试图接入其他未列明的服务，浏览器会直接拦截请求。结合反向代理和网络防火墙规则，企业还能进一步限制出站 IP 和协议类型，形成多重约束。

再看实际的请求逻辑实现：

async function generateDiagram(prompt, apiUrl, apiKey) { const response = await fetch(apiUrl, { method: "POST", headers: { "Content-Type": "application/json", Authorization: `Bearer ${apiKey}`, }, body: JSON.stringify({ prompt, model: "mistral-openorca", format: "mermaid", }), }); if (!response.ok) { throw new Error(`AI request failed: ${await response.text()}`); } const result = await response.json(); return result.diagram; }

这个函数虽然简单，却体现了清晰的安全哲学：

• 所有参数（apiUrl,apiKey）均由用户显式提供，无预设值；
• 请求体最小化，仅包含必要字段，避免冗余信息暴露上下文；
• 使用标准 Bearer Token 认证，兼容主流 LLM 服务平台；
• 输出格式限定为 Mermaid 或 JSON，便于前端安全解析，防止注入类攻击。

甚至连调试体验都被纳入考量：在开发者工具中查看日志时，系统会自动脱敏Authorization头和 API Key，避免因截图分享而意外泄露凭证。这种对细节的关注，正是高可信度软件的标志。

实际落地中的权衡与建议

当然，完全本地化运行 AI 并非没有代价。最明显的是硬件门槛——要在本地流畅运行像 Llama 3 8B 这样的模型，至少需要具备一定算力的 GPU 支持。但对于多数图表生成任务而言，并不需要顶级模型。轻量级方案如 Mistral 7B、Phi-3-mini 在量化后可在消费级设备上运行，足以胜任常见的架构图、流程图生成需求。

基于实践经验，以下几个最佳实践值得推荐：

• 优先使用本地 LLM：对于涉及内部系统的绘图任务，坚决避免调用公共 API。可搭建统一的 Ollama 实例供团队共享，既降低成本又便于管理。
• 收紧 connect-src 策略：生产环境中应移除 CSP 中所有非必要的远程域名（如api.openai.com），并通过 iptables 或 SDN 规则封锁对应出口。
• 短期密钥 + 自动轮换：若必须使用远程服务（如临时验证效果），应结合短期有效的临时令牌（STS），并设置自动过期机制，降低密钥长期暴露风险。
• 沙箱化运行环境：在金融、军工等高安全等级场景中，可将 Excalidraw 部署在受控容器或沙箱浏览器中，限制剪贴板、文件系统访问权限，进一步收窄攻击面。

更重要的是，这类工具的引入应当伴随组织内部的数据分类与使用规范建设。并不是所有内容都可以交给 AI 处理，也不是所有员工都清楚其中的风险。技术手段只能防范“无意泄露”，而制度设计才能解决“认知盲区”。

当开源遇上 AI：一种可信任的未来范式

Excalidraw AI 的意义，远不止于“一个能画图的白板”。它代表了一种正在兴起的新范式：在 AI 增强时代，便利性与安全性不必是非此即彼的选择。

通过去中心化的插件架构、本地优先的推理支持、严格的运行时隔离和完全透明的代码实现，Excalidraw 展示了如何在不牺牲用户体验的前提下，把数据主权牢牢交还给用户。这对那些身处高度监管行业（如医疗、金融、国防）的团队尤为重要——他们终于可以在合规框架内，合法地享受 AI 提效带来的红利。

更重要的是，这种设计为整个智能办公生态提供了借鉴。未来的 AI 工具不该是封闭的“魔法盒子”，而应是开放的“协作管道”；不应要求用户盲目信任，而应允许用户自主验证。Excalidraw 用一行行公开的代码告诉我们：真正值得信赖的 AI，不是藏得最深的那个，而是看得最透的那个。

当我们在白板上写下第一行架构描述时，也许该问的不再是“这个 AI 准不准”，而是“我的数据去哪儿了”。而 Excalidraw，已经给出了它的答案。