OpenConnector：给 AI Agent 加上一道凭据防火墙
内容提要
OpenConnector 是面向AI Agent的开源连接网关，解决外部账号授权问题。它提供近1000个Provider和超万个预置Action，统一管理Gmail、GitHub等服务的凭据，避免原始Token直接暴露给Agent。支持MCP协议，兼容OpenClaw，提供权限策略、脱敏日志和多种部署方式。虽不能完全消除风险，但通过最小权限和隔离设计，提升连接安全性与可控性。
延伸解读
凭据隔离的实际意义
OpenConnector 的核心价值在于将原始凭据与 Agent 隔离，Agent 仅获得调用特定 Action 的权限。这种设计缩小了凭据泄露的范围，并支持独立撤销和轮换权限。但需注意，Runtime Token 本身也是能力凭证，若被窃取，攻击者仍可通过网关执行操作。因此，最小权限原则至关重要，应配置尽可能小的 Action 白名单。
部署方式的权衡
OpenConnector 提供多种部署方式：本地自托管适合个人开发者，Fly.io 适合减少运维，Cloudflare 适合 Serverless，OOMOL 托管则最便捷。自托管能更好掌控凭据，但需自行申请 OAuth App；托管方式更省事，但凭据会进入第三方环境，企业需进行供应商和合规评估。选择时需权衡控制力与便利性。
安全边界与局限
OpenConnector 并非绝对安全保险箱。它不能自动消除提示词注入风险，恶意内容仍可能诱导 Agent 调用合法工具执行危险操作。此外，若 OpenClaw 与 OpenConnector 运行在同一主机且可读取其环境变量或数据库，凭据边界可能被绕过。建议使用独立容器或虚拟机，并设置独立的管理 Token 和 Runtime Token。
Q&A
OpenConnector 是什么？它主要解决什么问题？
OpenConnector 是一个面向 AI Agent 的开源连接网关，位于 Agent 和外部应用之间，统一管理 Gmail、GitHub 等服务的凭据，避免原始 Token 直接暴露给 Agent，解决外部账号授权和连接安全问题。
OpenConnector 如何避免把原始凭据直接交给 AI Agent？
OpenConnector 将真正的 OAuth Token、API Key 等凭据保存在网关运行环境中，Agent 只获得受限的 Runtime Token，并通过统一接口调用 Action。原始 Token 不会进入模型上下文，从而缩小凭据泄露范围，并支持独立撤销和轮换。
OpenConnector 支持哪些外部服务？
OpenConnector 提供近 1000 个 Provider 和超万个预置 Action，覆盖 Gmail、GitHub、Notion、Slack、Google Calendar、Google Drive、Airtable、Supabase 等常见服务。
OpenConnector 如何与 OpenClaw 集成？
OpenConnector 原生提供 MCP Endpoint（http://localhost:3000/mcp），新版 OpenClaw 可以登记 Streamable HTTP MCP Server，从而加载 OpenConnector 的工具。配置时通过 openclaw mcp set 命令设置 URL 和 Runtime Token，并建议通过环境变量注入 Token。
OpenConnector 有哪些部署方式？分别适合什么场景？
OpenConnector 提供四种部署方式：本地自托管（适合个人开发者和小团队，Docker 或 Node.js 运行）、Fly.io 自托管（适合希望减少运维的团队）、Cloudflare 部署（适合轻量 Serverless 架构）、OOMOL 托管（适合希望快速完成 OAuth 授权的团队）。
OpenConnector 能完全消除 AI Agent 的安全风险吗？
不能。OpenConnector 不能消除所有安全风险，例如 Runtime Token 本身可能被滥用、无法自动防止提示词注入、同一主机上凭据可能被绕过。需要配合最小权限、沙箱隔离和人工审批等措施。
OpenConnector 适合哪些用户使用？
适合使用 OpenClaw 并希望同时接入多个服务（如 Gmail、GitHub、Notion、Slack）的用户，正在开发需要用户授权第三方账号的 Agent 产品的开发者，希望统一管理 OAuth、API Key、Scope 和日志的团队，以及希望先使用托管 Connector 快速验证再迁移到自托管的用户。
