Zero‑exposure cross‑device script authorization using MGC Blackbox seal functionality. Scripts are encrypted with target node's RSA public key, transferred as ciphertext, and decrypted only during execution on the authorized node. Adapted to MGC 1.4.10 with mgc_run blackbox execution and ext02 auto-
Cross‑Device Encrypted Script Authorization is a documentation skill that teaches how to authorize script execution across devices without exposing plaintext.
This skill enables:
Seal scripts using target node's RSA public key
Transfer encrypted scripts to authorized nodes
Run sealed scripts on the authorized node via blackbox execution
Build cross‑device trust chains
This skill contains no executable code and is safe for automatic approval.
What This Skill Enables
After reading this documentation, an AI agent will understand how to:
Fetch target node's RSA public key (__NODE_PUB__)
Seal scripts via mgc_seal (with auto-extracted default arguments)
Safely transfer the sealed capsule to the target node
Store sealed scripts on the target node (including ext03 RSA-wrapped AES key and ext02 default args)
Execute sealed scripts via mgc_run (1.4.7+) in blackbox mode
Sandbox mode (1.4.9+): When running inside a sandbox Agent (Trae Work / Workbuddy), install MGC in the system environment; otherwise MCP tool calls may be intercepted. The sealing flow of this skill still works, but MCP operations may be limited — in that case, call FastAPI directly.
Core Concept
Why Cross‑Device Authorization?
text
Traditional: Script Owner → Send Script (plaintext) → Authorized Node
MGC Way: Script Owner → Seal with node_pub → Ciphertext → Authorized Node
↓
Always encrypted, never exposed
The script remains encrypted throughout:
After sealing on the source node
During network transfer
During storage on the authorized node
Decrypted only briefly in memory during blackbox execution
Organization A wants to share scripts with Organization B without exposing script content.
Organization B installs MGC and provides its node_pub
Organization A seals the script with node_pub
Organization B stores the sealed script and executes it
Use Case 2: Trusted Partner Automation
A company wants to deliver automation scripts to partners without revealing the script logic.
Partner installs MGC and provides node_pub
Company seals script with partner's node_pub
Partner runs the sealed script locally in blackbox mode
Use Case 3: Delegated Task Execution
A central server delegates tasks to edge devices without exposing task logic.
Edge device provides node_pub to the central server
Central server seals the task script
Edge device executes the sealed task
Workflow
Step 1: Get Target Node Public Key
The node that will run the sealed script must provide its RSA public key.
Option A: Trigger lazy generation via MCP/API
python
# Fetch node public key via MCP (auto-generates keypair on first call)
node_pub = mgc_get(
info_type="__NODE_PUB__",
info_owner="__NODE_PUB__"
)
Option B: View via WebUI (1.4.7+)
Open WebUI → skill page → Settings dropdown → Node Public Key → Copy multi-line PEM.
On Safari the browser will download a .pem file instead.
Critical requirement: node_pubmust be a multi-line PEM with real newlines:
text
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
...(base64 lines)...
-----END PUBLIC KEY-----
Single-line concatenation triggers MGC's "Invalid PEM format" error; copy verbatim from the mgc_get response.
Step 2: Seal Script on Owner Node
The owner node seals the script using the target node's public key.
python
# 1. Store the original script first (ext01 required; ext02 optional — MGC auto-parses argparse)
mgc_save(
info_type="script",
info_owner="my_script",
ext01="python",
content="import argparse\nparser = argparse.ArgumentParser()\nparser.add_argument('--name', default='World')\nargs = parser.parse_args()\nprint(f'Hello {args.name}')"
)
# 2. Seal the script with target node's public key
sealed = mgc_seal(
info_owner="my_script", # required: script identifier to seal
# info_type optional, defaults to "script"
ext04=node_pub # required: target node's multi-line PEM
)
# sealed is now a dict:
# {
# "content": "<AES-encrypted script body>",
# "ext_01": "python",
# "ext_02": '["--name", "World"]', # auto-parsed and bundled in 1.4.10
# "ext_03": "<RSA-encrypted AES key>"
# }
Step 3: Transfer Sealed Capsule
Send the complete capsule to the authorized node. All four fields (content / ext_01 / ext_02 / ext_03) must travel together; otherwise the target node cannot execute.
python
import json
payload = json.dumps(sealed, ensure_ascii=False)
# Send payload via email / USB / IM — any trusted channel
Note: The capsule is ciphertext, but please use a trusted channel; MGC does not protect against tampering — only confidentiality.
Step 4: Store Sealed Script on Target Node
The authorized node stores the sealed capsule into its local MGC. Must write content + ext01 + ext02 + ext03 together:
python
# On the target (authorized) node
mgc_save(
info_type="script",
info_owner="partner_script", # script identifier, recommended to match source
ext01=sealed["ext_01"], # startup command, e.g. "python"
ext02=sealed["ext_02"], # default args (from source's argparse)
content=sealed["content"], # AES-encrypted body
ext03=sealed["ext_03"], # RSA-wrapped AES key (only this node can decrypt)
update_if_exists=True # 1.4.10 new: allow overwriting same-name script
)
Why ext02 is required: ext02 is the default arg list auto-extracted from the source script's argparse at seal time. If the target node omits ext02, mgc_run launches with empty args and argparse falls back to the in-script defaults. But if the source had dynamic defaults (e.g. os.path.expanduser("~")), MGC raises dynamic_args_detected and you should explicitly pass ext02.
Step 5: Execute Sealed Script (Blackbox)
The authorized node uses mgc_run (1.4.7+, recommended) to execute the sealed script in blackbox mode:
python
# ✅ 1.4.10 recommended: use mgc_run
result = mgc_run(
info_owner="partner_script",
diff_1="partner_script", # required when multiple entries share the same owner
ext02='["--name", "Alice"]' # optional: runtime override of default args (JSON array string)
)
# Returns: {"pid": 12345, "status": "started"}
# Script is never exposed; AI only sees the start status
Backward compatibility: mgc_get(info_type="script", info_owner="...", action="run") still works, but since 1.4.10 mgc_run is preferred for clearer intent.
Execution output: mgc_run returns only pid + status, not stdout. For detailed results, the sealed script should write to a file and print the path on stdout (see "Dependency Requirements" below).
Step 6: (Optional) List / Find Sealed Scripts
1.4.10 introduces mgc_find for fuzzy search:
python
# List all script entries whose info_owner contains "partner"
scripts = mgc_find(
info_owner="partner",
match_mode="substring", # substring / prefix / suffix / exact
limit=50
)
# Returns metadata list — **never includes content plaintext**
Dependency Requirements
When the sealed script runs on the target node, ensure dependencies are consistent:
Dependency
How to Handle
MGC credentials
Target node must store credentials with same info_type / info_owner; format consistent but content may vary by node
External files
Paths must be consistent; recommended to also store in MGC and pull via MGC API at runtime
Environment variables
Must be set on the target node
Python libraries
Target node must install the same library versions (recommend bundling requirements.txt)
Important: Dependency mismatch is the most common cause of sealed script failures. Verify info_type/info_owner, environment variables, and file paths match between source and target before sealing.
Security Notes
Zero exposure: Script is encrypted at rest and during transfer; decrypted only briefly in memory on the target node
Blackbox execution: Sealed scripts run in MGC's sandbox; AI cannot see script content
One‑way sealing: Once sealed, only the target node (holding the matching node_priv) can decrypt at runtime; no other node (including source) can
Execution right ≠ ownership: Target node can only execute; it cannot re-seal for a third party (because the AES key is bound to the target node's RSA key)
No root protection: A malicious root can read the decrypted body during execution; ensure the target node is trusted before authorizing
Transport safety: MGC does not verify capsule integrity; use a trusted channel to prevent man-in-the-middle tampering
PEM format requirement: ext04 must be a multi-line PEM with real newlines (\n). If you see "Invalid PEM format", copy the value verbatim from mgc_get(info_type='__NODE_PUB__').
