夜雨聆风做了快二十年 SAP，我自己最清楚——任何一个新工具，我问的第一个问题永远是："这个安全吗？"这篇文章把 mcp-sap-assistant 的安全设计一条条摊开。你自己判断，过了再装。
一、先讲一个真实场景
上周我给一个甲方 IT 经理做演示。
我打开 Claude Code，输入"帮我查一下生产系统最近的 dump"，AI 刷刷几下就读出了 dump 列表、点进去看了详情、还顺手读了报错的那段 ABAP 源码。
他看完第一句话不是"这个功能好厉害"，而是：
"等等，你这个工具连的是生产系统？"
我说是。
他沉默了三秒，问了第二句：
"你能改数据吗？"
我知道他在担心什么。换成是我，一个陌生的工具说能连我的生产系统，我第一个问题也是这个。
所以我做这个工具的时候，安全不是最后加的一个"功能"——安全是第一天就定下的架构底线。
二、结论我放在最前面
只读。17 个工具，全是读取操作。没有修改、没有删除、没有执行。
这不是一句广告语，是一个设计决策：写操作，永久不做。
为什么这么绝对？因为我见过太多"只是看看"结果把数据改了的事故。工具能写，就总有一天会写错——不管是 bug 还是配置失误。
最安全的代码，是根本不存在的代码。 最安全的写操作，是工具压根就不会写。
三、四条安全设计，我逐条讲为什么这样做
1. 17 个工具，全部只读
查 dump、读源码、搜对象、查表数据、看系统信息、查接口日志、读系统公告、列传输请求——你能想到的"看"类操作都有，"改"类操作一个没有。
我为什么不做写操作？不是技术上做不到——是我不敢做。你想想：一个 AI 工具，能改你生产系统的数据。出了事，谁担责任？我担不起，你也担不起。
2. 默认不激活系统
安装完之后，工具不连接任何 SAP 系统。你必须手动调用 set_active_systems 选系统，它才会启用。
换句话说：AI 想读你的系统，也得先经过你同意。
这是从"最小权限"原则延伸来的——默认什么都不做，用户显式授权了才做。很多工具的问题不是功能多，是默认开得太多。
你装一个工具，它上来就连你的生产系统，这本身就不对劲。
3. 密码本地加密存储
密码存在本机 加密文档中 AES-256-GCM 加密，不存明文 不写进 配置文件，不进任何云端 SAP 密码、token、cookie 绝不写入日志
为什么我特别在意这一点？因为我见过太多工具把 SAP 密码明文存在配置文件里。这种事故，一次就够了。
还有日志。很多工具出了问题就打日志，打日志的时候图省事，把请求头里的 token、cookie 全打进去了。日志文件一传出去，账号就等于泄露了。
我的原则是：密码是用户的，不是工具的。 工具只负责存和用，不负责"方便地管理"。
4. 数据不出你的网络
工具跑在你自己电脑上，直接连 SAP 。
你的源码、业务数据、dump 内容，不经过任何第三方服务器——中间没有中转，就没有泄露点。
这一点我要特别讲清楚，因为很多人搞混：
AI 的推理确实是在 AI大模型的服务器上做的——但那是你和AI之间的事,和你对话框里面喂给AI数据和图片是一样的道理。我们的工具本身不存数据、不转发数据、不缓存数据，它只是在你调用的时候，把你要查的内容从 SAP 读出来，递到 AI 的上下文里。
SAP 系统 ↔ 你的电脑 ↔ AI 推理。中间没有我的服务器，没有"云端处理"，没有任何额外的节点。
多一个节点，多一个风险。我选择不做那个节点。
四、权限清单（建议专用账号）
权限最小化：给什么权限，AI 就只有什么权限。不给写权限，AI 物理上写不了。
我上次给一个客户做安全评估，对方拿到这个清单只问了两个问题："只能读？"——嗯。"数据不经过你们服务器？"——嗯。然后就给权限了。前后 15 分钟。
五、和"能写"的方案对比
我可以选择做全能型的，能创建对象、能传输请求、甚至能执行代码。
我为什么刻意不做？
"只能读"不是缺陷，是负责，是信任。
客户的信任，是从"你物理上不能闯祸"开始的。
六、我的原则
安全不是嘴上保证，是架构上就不做。
我不想卖"AI 替你做一切"，我只卖"AI 帮你看到真相"。
打个比方：这就像你请了一个做了三十年的老 SAP 顾问来你的系统里看一看。他看的懂配置、懂 dump、读得懂代码、能告诉你问题出在哪——但他只有显示权限，不能改配置、不能改数据、不能跑程序。
他看完走了，你的系统还是原样。
风险为零，信息增量巨大。
一个只会读、不能写的工具，在客户的生产系统里，才有存在的资格。
八、想试试？
私信我，微信号 YYSAI365, 我们共同来交流。
建议你先在测试系统跑，跑通了再考虑生产。
安全这事，不急。