最近我在系统性地梳理 MCP 安全方案——随着越来越多的团队通过 MCP 把 AI Agent 接入外部工具，一个反复出现的问题是：怎么在不改动现有工具链的前提下，给 MCP 加上安全控制层？
研究过程中，我偶然发现了 Lasso Security 和它们的开源项目 Lasso MCP Gateway。这篇文章是我的调研记录。
公司背景
Lasso Security 总部在以色列特拉维夫，2023 年 6 月由 Elad Schulman（CEO）、Lior Ziv（CTO）、Ophir Dror（CPO） 和 Yuval Abadi 联合创立。公司至今融资 $3,050 万，现有约 75 人。2024 年被 Gartner 评为 Cool Vendor。
他们的客户包括美国国土安全部、eToro、Fiverr、Kaltura 等——大多是 AI 安全需求较严格的企业。
Lasso 的产品线覆盖四个领域：Discovery & AI-BOM（资产发现与物料清单）、AI Security Posture Management（安全态势管理）、Automated Red Teaming（自动化红队测试）、Runtime Enforcement（运行时防护）。我调研的 MCP Gateway 属于运行时层。
开源项目概况
Lasso MCP Gateway 的 GitHub 仓库（github.com/lasso-security/mcp-gateway）采用 MIT 协议。目前 386 stars、38 forks、40 commits，最新 release 为 v1.2.1。最近一次 commit 是 7 个月前。项目用 Python 3.10+ 编写，可通过 pip 安装：
pip install mcp-gateway
官方描述是：
「一个为 MCP 服务器设计的高级中介解决方案，集中化并增强你的 AI 基础设施。」
实操中，它位于 AI Agent（比如 Cursor 或 Claude Desktop）和你的 MCP 服务器之间，作为一个透明代理，能在每个请求和响应经过时进行检查、清理和记录。
架构拆解
Gateway 读取一个 mcp.json 配置文件——就是 Cursor 和 Claude Desktop 用的那个格式——然后把配置中的每个 MCP 服务器包装在一层统一接口之后。
Agent → MCP Gateway → MCP Server A
→ MCP Server B
→ MCP Server C
Gateway 向 Agent 暴露两个核心工具：
get_metadata— 列出所有代理的 MCP 服务器、工具和资源，相当于一个发现端点run_tool— 在指定代理服务器上执行工具调用，请求和响应经过插件链的处理后再传递
关键的设计决策：Agent 只看到一个 MCP 服务器（Gateway 本身），Gateway 在背后透明地管理路由、生命周期和安全检查。这有点像 API Gateway 的模式——把所有 MCP 服务器收拢到一个入口，统一加安全策略。
三层插件体系
架构中最有意思的部分是 guardrail 插件系统。每个插件专注于一个安全维度，可以链式组合。
| 插件 | Token/密钥脱敏 | PII 脱敏 | 自定义策略 | Prompt 注入检测 | 有害内容检测 |
|---|---|---|---|---|---|
| basic | ✅ | ❌ | ❌ | ❌ | ❌ |
| presidio | ❌ | ✅ | ❌ | ❌ | ❌ |
| lasso | ✅ | ✅ | ✅ | ✅ | ✅ |
Basic Plugin
最简模式。扫描工具响应对已知凭证模式——GitHub token、AWS 密钥、JWT、HuggingFace token、Slack token 等——做匹配和脱敏。零外部依赖，完全本地运行。
Presidio Plugin
使用 Microsoft Presidio（开源 PII 识别和匿名化工具包）检测信用卡号、邮箱、电话、SSN、IP 地址等个人信息。需要额外安装 pip install mcp-gateway[presidio]。
Lasso Plugin
功能最全的插件，但需要 Lasso API key（从他们的商业平台获取）。调用 Lasso 的云端 API 分析请求和响应，覆盖：
- Prompt 注入检测
- 有害或违规内容过滤
- 敏感数据泄漏（token + PII）
- 用自然语言描述的自定义安全策略
这个插件是连接开源 Gateway 和 Lasso 商业运行时防护平台的桥梁。没有 API key 就用不了。
Pre-load Security Scanner
除了内联防护，Gateway 还附带一个 预加载扫描器（--scan 参数），在 MCP 服务器实际加载前进行评估。它检查三件事：
- 声誉分析：在 Smithery、NPM 等市场和 GitHub 上查询 MCP 服务器发布者的数据
- 工具描述扫描：解析工具描述，检查是否有隐藏指令、敏感文件模式或恶意行为
- 自动拦截：声誉分低于阈值（默认 30）的服务器直接阻止加载
扫描后每个服务器得到一个状态：passed、blocked 或 skipped（手动放行），状态直接写入 mcp.json 配置文件。
这个机制的价值在于它在运行时之前就做了供应链安全评估。考虑到现在 npx 一个 npm 包就能当 MCP 服务器跑起来，预检查层挺有意义的。
Tracing 与审计
Gateway 还可以配置 xetrack 插件做监控和调试。它把每次工具调用的请求参数、响应内容、时间戳和服务器元数据记录到 SQLite 数据库中。日志可以用 xetrack CLI 或者直接用 DuckDB/SQLite 查询。
这对需要审计轨迹的团队来说挺实用的——不需要额外部署一套观测栈就能知道什么工具被调了、传了什么参数、返回了什么结果。
部署方式
Gateway 有三种部署路径：
- Python CLI：安装后配置
mcp.json即可 - Docker：使用仓库里的 Dockerfile 构建，通过环境变量传入 Lasso API key
- 内嵌模式：Gateway 本身作为一个 MCP 服务器运行，在它下面包装其他 MCP 服务器
Python CLI 是最简单的路径。Gateway 读取你已有的 mcp.json，包装每个服务器，然后自己作为唯一的 MCP 服务器呈现给 Agent。
我观察到的几个点
整个项目过一遍，有几个观察值得记录。
插件架构是合理的抽象层级
从 zero-dep 的本地 token 脱敏到云端 AI 安全分析，三级递进的选择给了团队一个清晰的升级路径。不需要一把梭——可以从 basic 起步，觉得不够再加 presidio，最后才考虑 lasso。这种梯度设计很适合实际落地场景。
Gateway 的 scope 刻意很窄
没有试图做语义聚合层、没有处理 Agent 间的认证、也没有做跨团队的工具生命周期管理。它的职责就是拦截 MCP 调用并做净化。40 个 commit、7 个月前的最后一次更新——从 commit 历史看是一个聚焦的项目。
Pre-load Scanner 加了一个供应链维度
大多数 MCP 安全工具聚焦运行时——工具被调用了怎么办。预加载扫描器在运行时之前先做一次供应链评估，判断一个服务器是否应该被加载。考虑到任意 npm 包都能当 MCP 服务器跑起来的现状，这个方向确实值得关注。
Lasso Plugin 绑定了云端
basic 和 presidio 插件完全本地运行。但提供最全面保护的 lasso 插件需要 API key，数据会发送到 Lasso 的云端做分析。团队在评估时需要权衡哪一层的保护值得开放数据流。
写在最后
Lasso MCP Gateway 是一个聚焦的、基于插件的 MCP 安全代理。它没有追求做一个全栈 MCP 管理平台，而是专注在拦截 MCP 调用并做可控的净化——并且用三层插件架构给团队提供了渐进式的选择。
对于已经在跑 MCP 服务器、想在不大改配置的情况下加一层安全防护的团队，这是一个值得看看的项目。MIT 协议加上几分钟的安装时间，足以快速上手验证。