Ae1
- Category
- analysis-evasion
- Confidence
- 100% confidence
- Finding
Referenced artifact was not completely inspected
- Content
md mgc_get(info_type="file", info_owner="my_workflow", diff_2="my_workflow", diff_3="SKILL.md")
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent local workflow-sealing skill, but it deserves Review because it promotes black-box code execution and direct reuse of a local MGC auth token.
Install only if you trust MGC Blackbox and the people providing sealed packages. Avoid copying raw MGC tokens into scripts, prefer official tool calls when possible, and run sealed packages in a restricted account or sandbox because their source is intentionally hidden and may perform local subprocess or file operations.
Referenced artifact was not completely inspected
mgc_get(info_type="file", info_owner="my_workflow", diff_2="my_workflow", diff_3="SKILL.md")
The skill instructs users to read a local authentication token directly from ~/.mgc/.../.mgc_token and reuse it in a custom script to invoke a sensitive API. Encouraging manual extraction and reuse of bearer-like credentials expands the attack surface, normalizes credential handling outside the intended client, and makes token theft or misuse by other local code much easier.
The manifest ID includes the locale suffix -en, indicating an English-specific variant, but the document does not offer any language selection or explain why English is required. Under the language/locale policy, forcing a specific language without user opt-in or documented justification is a policy concern.
The documentation states that MGC 'connects to no cloud' and 'has no external endpoints,' which conveys a purely local/non-networked execution model. Later, the skill explicitly demonstrates using requests.post to call an HTTP API on http://127.0.0.1:57219, so the documentation contradicts the code by denying endpoints while relying on one for cross-package orchestration.
The skill promotes a reusable API-call pattern based on a locally stored authentication token, enabling session persistence outside the normal MGC client boundary. That increases the chance that long-lived credentials are reused by scripts, copied into logs or code, or retained in environments not designed to protect them.
## Rule 1 — Same-package paths are OK; cross-package calls use the MGC API
Scripts inside the **same folder package** can freely use `import / relative paths / subprocess`** — MGC 1.5.2's `ext08` automatically recognizes and routes them through sealed execution at runtime. **No need to rewrite as API calls.**
Only **cross-folder-package calls** (different `info_owner + diff_2`) require the MGC API:
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
MGC_TOKEN = f.read().strip()
def call_remote_script(info_owner, ext02=None):
return requests.post(
"http://127.0.0.1:57219/api/mgc/sensitive/get",
headers={"X-MGC-Token": MGC_TOKEN},
json={
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
MGC_TOKEN = f.read().strip()
def call_remote_script(info_owner, ext02=None):
return requests.post(
"http://127.0.0.1:57219/api/mgc/sensitive/get",
headers={"X-MGC-Token": MGC_TOKEN},
json={
Code issues a request to a loopback, link-local, or private-range host. This can reach internal services not meant to be exposed and is a common SSRF pivot.
MGC_TOKEN = f.read().strip()
def call_remote_script(info_owner, ext02=None):
return requests.post(
"http://127.0.0.1:57219/api/mgc/sensitive/get",
headers={"X-MGC-Token": MGC_TOKEN},
json={
The README explicitly instructs users to run scripts that create multiple files in the user's Desktop or home directory, which is a real filesystem side effect. While the behavior is disclosed elsewhere in the document, it is framed as expected demo output rather than a clear up-front safety warning or consent prompt, so users may execute it without appreciating that local files will be written outside the project directory.
The top-level documentation frames this file as a shared configuration/module utility and emphasizes import/subprocess usage, which suggests a helper component. However, when run as a script it performs a side effect by writing txt2_via_a.txt to the Desktop or home directory at L52-L53, which is a materially different intent than a passive config/helper module.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
target = here / "config_a.py"
# ── subprocess: literal list form (MGC 1.5.2 ext08 recognizes this) ──
proc = subprocess.run(
[sys.executable, str(target), "--user", user, "--greeting", greeting, "--print"],
capture_output=True, text=True,
)
No manifest is available, so there is no declared purpose that would make spawning a separate executable an obviously necessary implementation detail. The code explicitly invokes config_a.py via subprocess.run, which is a privileged capability beyond simple local computation or formatting.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
# 2. C (subprocess) — runs in a sealed subprocess
c_target = here / "script_c.py"
proc = subprocess.run(
[sys.executable, str(c_target), "--user", user, "--greeting", greeting],
capture_output=True, text=True,
)
The manifest description advertises behavior like 'auto-routes through sealed execution' and broad support for imports, relative paths, and subprocesses without describing clear user-controlled triggers or safety boundaries. In an agent ecosystem, this kind of expansive automation language can cause over-trust, unintended invocation, or execution of complex workflows in contexts the operator did not explicitly authorize.
The README explicitly encourages running sealed packages that can invoke subprocesses and notes an example that creates files on the user's Desktop, but it does not give a clear safety warning about local side effects or advise users to inspect behavior in a sandboxed environment first. In a skill centered on executing opaque, encrypted code, the lack of a prominent warning materially increases the chance that users run code with filesystem or process side effects they do not fully understand.
No suspicious patterns detected.