跨设备脚本零暴露授权

它要解决的问题

把脚本交给别人跑，通常等于把源码交出去。只要对方不是完全可信，脚本里的业务逻辑、内部路径、密钥处理方式就会一并暴露：同事之间共享工具，没人想顺手看到别人写死的临时逻辑；跨组织合作时，把自动化脚本发给合作方，等于把内部实现一起发出去；即便只是把任务下发到边缘设备，任务脚本里也可能带着中央侧的判定规则。

这个技能的做法是让脚本在加密状态下跨设备流转：源节点用目标节点的 RSA 公钥密封脚本，传输阶段、目标节点存储阶段都保持密文，只有目标节点在黑盒执行时才在内存中解密，用完立即释放。目标节点拿到的是不可读的密封包，而不是源码。

技能如何工作

核心流程分六步，每一步对应一个明确的 MGC 操作：

1. 获取目标节点公钥（__NODE_PUB__），必须是多行 PEM、每行真实换行；单行拼接会触发 Invalid PEM format。
2. 源节点密封脚本，用 mgc_seal，密封时会自动从脚本的 argparse 提取默认参数。
3. 传输密封包，content、ext01、ext02、ext03 四个字段必须完整一起传。
4. 目标节点存储，用 mgc_save，同样四个字段一起写入。
5. 黑盒执行，用 mgc_run（推荐 1.4.10+），返回 pid 和 status，不返回 stdout。
6. （可选）查询，用 mgc_find 做模糊搜索。

依赖一致性是这里最容易踩的坑：目标节点需要按相同的 info_type / info_owner 存入 MGC 凭据（格式一致、内容按节点定制）、外部文件路径保持一致、环境变量在目标节点显式设置、Python 库版本对齐。源脚本若有动态 default（如 os.path.expanduser("~")），会被标记为 dynamic_args_detected，建议显式传入 ext02。

适用边界与注意点

• 不是完整性方案：密封包是密文，但 MGC 不阻止篡改，仍需走可信传输渠道。
• 无 root 防护：恶意 root 可以在执行瞬间读到内存里的明文，目标节点必须先确认可信。
• 执行权不等于所有权：AES key 只绑定目标节点公钥，目标节点无法把脚本转密封给第三方。
• 看不到执行输出：mgc_run 只返回启动状态，需要脚本自己把结果写文件并在 stdout 输出路径。
• 这是文档技能：不含可执行代码，也不做自动审批，只把跨设备信任链的做法讲清楚。