mia-trust

MIA-Trust Pipeline - Memory-Intelligent Assistant 信任守门+记忆进化 pipeline

Key things to check before installing or running this skill: - Metadata mismatch: the registry says no env vars/credentials required, but the code expects API keys and endpoint URLs (MIA_PLANNER_API_KEY, MIA_TRUST_API_KEY, MIA_PLANNER_URL/MIA_TRUST_URL, etc.). Do not assume it runs without credentials; planner will exit if API mode is selected without keys. - Outbound requests: by default the code will call configurable LLM endpoints (defaults to api.openai.com). Review and if needed override MIA_*_URL to a trusted internal endpoint before sending real data. - Persistent storage: user queries, plans, evaluation results, and distilled experiences are written to local files (memory.jsonl, trust/trust_experience.json, feedback.jsonl). These files may contain sensitive content — restrict file permissions, or change paths via env vars (MIA_MEMORY_FILE, MIA_TRUST_EXPERIENCE_FILE, MIA_FEEDBACK_FILE) and/or run in an isolated environment. - Source and provenance: package.json points to a placeholder GitHub URL (https://github.com/yourname/mia-trust). Confirm the package source/repo and review its upstream history before trusting it. - Least-privilege: provide dedicated API keys with minimal scope, and run the skill in an isolated container or VM if you will process sensitive inputs. - Review config: examine trust_experience.json and memory files shipped with the package (they may contain example data) and the SKILL.md/Pipeline documentation to understand what will be stored and sent externally. - If you need guarantees: ask the author for a clear manifest update that lists required env vars/primary credential and the exact network endpoints the skill will contact; otherwise treat the mismatch as a risk. If unsure, run tests with synthetic non-sensitive inputs in a controlled environment first.

Type: OpenClaw Skill Name: mia-trust Version: 1.0.0 The bundle implements a security-oriented 'MIA-Trust Pipeline' designed to detect prompt injections and evaluate agent plans for safety. However, it is classified as suspicious due to a critical shell injection vulnerability in the main entry point, `run.mjs`. This script uses `child_process.execSync` to orchestrate sub-modules and embeds user-provided input (`QUESTION`) directly into shell commands with inadequate sanitization (only escaping double quotes), allowing for potential Remote Code Execution (RCE) via shell metacharacters or command substitution. While the intent appears defensive, the implementation of the runner script poses a significant security risk.