内网 AI 不泄密：Apifox 私有化接私有模型与 MCP 的落地指南

私有化部署的团队，对 AI 通常有两种极端态度：

一种是“不能用，AI 会把接口文档和密钥传到公有云”；另一种是“先开了再说，反正部署在内网”。

这两种都不对。Apifox 私有化里的 AI 不是默认开启的，也不是只能连厂商的公有模型。它的正确用法是：由管理员控制开关、接企业自己的模型、把 MCP 请求留在企业服务器、对生成结果做人工复核。

这篇文章讲清楚安全边界、参考架构和落地步骤。具体模型接入方式和参数以 Apifox 官方文档为准。

一、先记住三条安全边界

1. AI 默认关闭，管理员启用

私有化环境里，AI 功能默认不开启。需要组织或团队管理员主动启用，并自行配置模型。

这意味着：

不会因为部署了平台，就自动把数据发给某个外部模型。
管理员可以按团队、按项目决定是否开放。
可以先在小范围试点，再逐步扩大。

2. 不内置外部模型，不使用企业数据训练

Apifox 私有化不内置外部模型，模型由企业自己选择、自己部署或自己接入。官方口径明确：不使用企业数据训练。

这两句话很关键：

不内置外部模型：数据流向由企业自己决定。
不用于训练：企业数据不会变成模型厂商的训练材料。

3. 密钥本地加密，MCP 请求走企业服务器

生成带鉴权的测试用例时，密钥值按产品设计在本地加密处理，避免把完整密钥明文交给模型侧。

MCP 也一样。私有化部署下，MCP 请求会打到企业自己的服务器，而不是公有云地址。这样 Cursor、Claude Code 等客户端读取的是企业内部的接口规范。

免费使用 Apifox

二、参考架构：把 AI 关在内网里

一个典型的私有化 AI 架构可以分成四层：

┌─────────────────────────────────────────────────────────┐
│  开发者客户端                                            │
│  Apifox 客户端 / Cursor / Claude Code / 其他 MCP Client  │
└───────────────────────┬─────────────────────────────────┘
                        │ 企业内网 / VPN
                        ▼
┌─────────────────────────────────────────────────────────┐
│  Apifox 私有化服务                                       │
│  项目 / 接口 / 文档 / Mock / 测试 / 权限 / 审计          │
│  MCP Server（指向企业私有化地址）                        │
└───────────────────────┬─────────────────────────────────┘
                        │ 仅允许白名单模型网关
                        ▼
┌─────────────────────────────────────────────────────────┐
│  企业模型网关 / 私有模型服务                             │
│  vLLM / Ollama / 企业大模型平台 / 内部推理集群           │
│  统一鉴权、限流、日志、脱敏                              │
└───────────────────────┬─────────────────────────────────┘
                        │
                        ▼
┌─────────────────────────────────────────────────────────┐
│  安全与可观测                                            │
│  DLP / 审计日志 / 提示词与响应留存策略 / 告警            │
└─────────────────────────────────────────────────────────┘

这张图里有三个关键控制点：

模型网关：只允许 Apifox 访问白名单模型，不允许直连公网。
审计日志：记录谁在什么时候、对哪个项目用了 AI，输入输出是否留存由企业策略决定。
MCP 地址：客户端配置的是企业私有化地址，不是公有云地址。

三、5 个最适合先落地的场景

不要一上来就让 AI 改核心接口。先从低风险、高重复的场景开始。

场景	输入	输出	人工复核点
补全接口文档	接口路径、参数、响应示例	字段说明、示例、错误码解释	业务含义是否准确
规范检查	接口定义、命名、Schema	命名/描述/示例改进建议	是否符合团队规范
批量生成测试用例	接口定义、业务规则	正常/边界/异常用例	是否覆盖真实业务
生成 Mock 数据	字段类型、约束	手机号、姓名、地址等假数据	是否含真实个人信息
Agent 读取 API 规范	OpenAPI/项目规范	Cursor/Claude Code 生成代码	是否按真实契约生成

场景 1：补全接口文档

最容易被低估。很多团队的接口文档只有字段名，没有业务含义。AI 可以根据上下文补出“这个字段什么时候为空”“这个状态有哪些取值”，但必须由接口负责人确认。

场景 2：规范检查

把团队的命名规范、错误码规范、分页规范整理成提示词或规则，让 AI 做第一轮检查，人做第二轮审核。适合在合并请求前跑。

场景 3：批量生成测试用例

AI 擅长从接口定义里扩展边界值、异常组合、权限场景。但它不知道你的业务约束，所以生成结果要经过测试同学筛选。

场景 4：生成 Mock 数据

用 AI 生成更真实的假数据，比纯随机字符串更适合前端联调。注意不要用真实用户数据做示例。

场景 5：让 Agent 读取真实规范

通过 MCP 把接口规范暴露给 Cursor、Claude Code 等客户端，Agent 就不用猜字段名。对“生成客户端代码”“补测试”“改调用方”这类任务，准确率提升最明显。

下面两张图来自已发布的《一个好用的 MCP 客户端调试工具推荐》，展示的是 Apifox 里调试 MCP 的界面，不是私有模型的部署架构。

在接口目录里可以直接新建 MCP，用来连接企业自己的 MCP Server。

连上之后可以直接看 Tools，并发起 tools/call，确认 Agent 读到的是企业内的接口能力。

四、落地六步：从试点到推广

第 1 步：做数据分级

先明确哪些数据可以给模型，哪些不可以：

公开文档、示例数据：可以。
内部接口定义：按项目授权。
真实用户数据、生产密钥、支付信息：默认不可以。
审计日志、权限配置：只给管理员。

第 2 步：选模型和部署方式

常见选择：

企业已有大模型平台：直接接内部网关。
自建推理：vLLM、Ollama 等。
混合：敏感任务走私有模型，通用任务走企业批准的外部模型。

无论哪种，都要经过安全评审。

第 3 步：配网络策略

Apifox 私有化服务只能访问白名单模型地址。
MCP 客户端只能访问企业私有化地址。
禁止从模型服务反向访问数据库。
记录出站连接和异常重试。

第 4 步：小范围启用

先选 1 个团队、1 个非核心项目，启用文档补全和规范检查。观察：

生成质量
响应延迟
模型调用成本
是否有敏感数据误发
开发者是否愿意用

第 5 步：建立复核流程

AI 生成的内容不能直接进主分支。建议：

文档补全：接口负责人确认。
测试用例：测试同学筛选后入库。
代码生成：走正常合并请求和 CI。
Mock 数据：检查是否含真实个人信息。

第 6 步：推广和度量

按团队扩大，指标建议看：

文档完整率
测试用例覆盖率
用例生成到入库的采纳率
平均文档补全时间
AI 相关告警/误报数

五、安全评审要问的 10 个问题

#	问题	期望答案
1	AI 默认是否关闭？	是，管理员启用
2	模型是谁的？部署在哪？	企业自有或批准的内部服务
3	提示词和响应是否留存？	有明确策略，可审计
4	是否用于训练？	不用于训练
5	密钥如何保护？	本地加密，不明文出内网
6	MCP 请求发到哪？	企业私有化地址
7	谁能开启 AI？	组织/团队管理员
8	是否有项目级授权？	有，按项目/团队控制
9	是否有调用日志？	有，可按用户/项目检索
10	出问题如何关闭？	管理员可一键停用