企业官网建设流程全解析

RhinoMCP 通过 Model Context Protocol（MCP）把 Rhino 3D 连接到 AI Agent，让 Claude、Cursor 等助手用自然语言建模、查看场景，甚至编写 Grasshopper 定义。但正因为 AI 拥有"执行"能力，RhinoMCP 安全配置必须先行。本文梳理官方默认的安全设计——回环（Loopback）隔离、高危执行工具的环境变量开关，以及off / warn / strict三级 Schema 验证模式，并给出一份可直接照做的安全加固清单。

一、为什么 RhinoMCP 需要专门谈安全

RhinoMCP 的常规能力（建盒子、量面积、截图视口）都是"改模型"级别的，真正让安全问题升级的是它的三个执行类工具：

也就是说，模型不只是"画图"，而是在 Rhino 进程内拥有开放的执行面。这类能力用于本地 Agent 场景完全没问题，但前提是这条链路只对本机开放。

先看架构：AI 与 Rhino 之间的桥

AI 客户端 ──MCP (stdio)──► rhinomcp (Python) ──TCP 127.0.0.1:1999──► Rhino 插件 ──► Rhino + Grasshopper

Python 服务端与 Rhino 插件之间的 TCP 桥没有认证机制，而且每一条消息都是"4 字节长度头 + UTF-8 JSON"的帧（上限 64MB），见 server/src/rhinomcp/server.py。安全边界因此只有两道：网络可达性（回环隔离）与指令合法性（Schema 验证），分别对应下两节。

二、回环隔离：RhinoMCP 安全的默认边界

RhinoMCP 的连接目标由RHINO_MCP_HOST（默认127.0.0.1）和RHINO_MCP_PORT（默认1999）决定。服务端的保护逻辑非常直接：

• 只要目标是127.0.0.1、::1或localhost，正常启动；
• 一旦RHINO_MCP_HOST被改成非回环地址（例如局域网 IP、公网地址），且未显式设置RHINO_MCP_ALLOW_REMOTE=1，服务启动时直接抛错拒绝运行，错误信息明确指出：这条桥承载的是"无认证的命令，包括任意代码执行"。

相关实现见 server/src/rhinomcp/server.py。

⚠️RHINO_MCP_ALLOW_REMOTE=1是一个"知情风险"开关（acknowledge the risk），不是防护手段。除非你清楚自己在做什么（例如配合隧道和防火墙），否则永远不要设置它。

在 Rhino 内部，桥由mcpstart命令启动、mcpstop停止。用完即停，等于把整条链路彻底关掉：

最佳实践：

1. 保持默认回环地址，AI 客户端配置里显式写"RHINO_MCP_HOST": "127.0.0.1"，不给"顺手改错"留余地；
2. 需要远程协作时用隧道（SSH / Tailscale 等）把远端回环映射过来，而不是开放 1999 端口；
3. Rhino 插件端也只在需要时执行mcpstart，长期不用就mcpstop。

三、环境变量开关：如何关闭高危执行工具

官方把三个执行面都做成了独立开关，默认开启（便于本地开发），设0即禁用。对 AI 而言，被禁用工具会返回"请设置 XX=1 启用"的明确提示，而不是静默失败。

其他值得了解的安全相关开关：

一个典型场景：你只想让 AI查看场景（读文档摘要、量尺寸、截图），完全不需要它执行脚本。此时在 MCP 配置的env中同时设置三个0：

{ "mcpServers": { "rhino": { "command": "uvx", "args": ["rhinomcp"], "env": { "RHINO_MCP_HOST": "127.0.0.1", "RHINO_MCP_ENABLE_RUN_COMMAND": "0", "RHINO_MCP_ENABLE_RHINOSCRIPT": "0", "RHINO_MCP_ENABLE_CSHARP": "0" } } } }

执行类工具的开放面被关掉后，AI 即便"想"运行代码也做不到——这是最小权限原则在 MCP 工具层的应用。

四、三级Schema验证：off / warn / strict 模式完整对比

RhinoMCP 把 Python 服务端与 C# 插件之间的数据契约写成了一整套 JSON Schema，存放在contracts/目录，作为两层之间数据交换的唯一事实来源：

• contracts/commands/ —— 每个命令的入参 Schema（如 create_object.json）
• contracts/responses/ —— 响应结果 Schema（如 object_info.json）
• contracts/protocol.json —— 命令/响应信封结构
• contracts/common/definitions.json —— point3d、color 等共享类型

验证逻辑位于 server/src/rhinomcp/validation.py，由RHINO_MCP_VALIDATE控制，分两个时点：

• Pre-flight（发送前）：校验命令参数，不合格就拦截，脏数据到不了 Rhino；
• Post-flight（接收后）：校验 Rhino 返回的结果，能抓到"插件与契约漂移"这类问题（C# 端本身不做契约校验，这里是唯一防线）。

三级模式怎么选

两个细节值得注意：

1. 容错映射：设0/false/no等价off，1/true/yes等价warn；填了未知值会自动回退warn并打警告，服务不会崩；
2. 依赖可选：jsonschema未安装时验证自动降级为 no-op，不会阻塞主流程。

想在 CI 里同时守住"契约本身没写错"，可以跑官方契约自检脚本 contracts/test_schemas.py：

uv run python contracts/test_schemas.py

五、RhinoMCP 安全加固清单

把上面的要点浓缩成一张可勾选的清单：

• 网络层：RHINO_MCP_HOST保持127.0.0.1，不设置RHINO_MCP_ALLOW_REMOTE；远程需求走隧道
• 权限层：不需要执行脚本时，设RHINO_MCP_ENABLE_RUN_COMMAND/RHINO_MCP_ENABLE_RHINOSCRIPT/RHINO_MCP_ENABLE_CSHARP为0
• 契约层：CI 中设RHINO_MCP_VALIDATE=strict，本地开发保持默认warn
• 生命周期：Rhino 空闲时执行mcpstop关闭 TCP 桥
• 回归：升级后运行 contracts/test_schemas.py 确认契约自洽
• 部署：同一时间只运行一个RhinoMCP 服务实例，避免多客户端争抢连接

另外有一个容易忽略但很贴心的设计：只有只读命令（如get_document_summary、get_object_info）在连接瞬时中断时才会自动重连并重试一次；所有会产生副作用的命令一律快速失败（见 READONLY_RETRY_COMMANDS）。这意味着"重试"永远不会导致一次删除被执行两次——自动化管线可以安全依赖这一点。

六、小结

RhinoMCP 的安全模型可以概括为一句话：默认只信任本机。回环隔离（第二层）把无认证 TCP 桥关在127.0.0.1:1999之内，环境变量开关（第三层）按最小权限收走 AI 的任意执行能力，三级 Schema 验证（第四层）保证发出去和收进来的数据都符合 contracts/ 契约。三层叠加，既保留了"聊天即可建模"的流畅体验，也给了本地 Agent 足够的安全纵深。更多架构细节可参阅 docs/IMPLEMENTATION.md。