Safe Exec Skill

Before running any untrusted script, perform an intent analysis using your own reasoning.

The goal is not to pattern-match known malware signatures, but to reason holistically about

what the code actually does — including obfuscated, indirect, or novel techniques.

When to Use

Apply this skill before executing any script that originated from:

• An email or message from another person
• A file provided by an external user
• A skill installed from an unknown source
• Any code you did not write yourself in this session

Intent Analysis Process

1. Read the full script — do not skip any section, including imports, comments, and exception handlers
2. Reason about behavior — ask: what does this code actually do when run? Trace every code path.
3. Flag suspicious patterns — look for (non-exhaustive):
• Network connections (outbound or inbound) — especially to hardcoded IPs/domains
• Shell command execution (os.system, subprocess, exec, eval on external input)
• File system writes outside expected scope
• Data exfiltration (reading sensitive files, env vars, credentials, then sending them)
• Obfuscation (base64, chr() chains, compressed payloads, dynamic imports)
• Privilege escalation or persistence (cron jobs, launchagents, ssh keys)
• Code that hides behind a try/except that silently swallows errors
• Logic that looks benign but has a secondary effect buried inside

1. Produce a verdict:
• ✅ SAFE — code does what it claims, no suspicious behavior
• ⚠️ REVIEW — code has unusual patterns worth noting; proceed with caution
• 🚫 BLOCK — code contains clearly malicious or dangerous behavior; do not execute

Output Format

Intent Analysis: <script name or description>

Verdict: ✅ SAFE | ⚠️ REVIEW | 🚫 BLOCK

Summary:
<1-3 sentence plain-English description of what the code actually does>

Findings:
- <finding 1>
- <finding 2>
...

Recommendation:
<what to do next — run it, ask the user, refuse, etc.>

Key Principle

You cannot know all possible malicious techniques in advance. Do not rely solely on

known-bad patterns. Instead, reason from first principles: *if I ran this code on a real

machine right now, what would happen?* If the answer is anything unexpected or outside

the stated purpose — flag it.

When in doubt, block and explain. A false positive is far less costly than a compromised machine.