skill_manager subprocesses inherit full `os.environ` — risk of secret leakage to user scripts

[edmicho]

In sdk/nexent/skills/skill_manager.py the two helpers that run user-supplied Python and shell scripts pass the full host environment:

# line 783-790 (_run_python_script)
result = subprocess.run(
    ["python", script_path] + cmd_parts,
    capture_output=True,
    text=True,
    timeout=300,
    env=os.environ.copy()
)

# line 813-820 (_run_shell_script)
result = subprocess.run(
    ["bash", script_path] + cmd_parts,
    capture_output=True,
    text=True,
    timeout=300,
    env=os.environ.copy()
)

The skill scripts are user-authored and may be shared via the agent marketplace per the README's "Agent Marketplace" feature. A malicious or careless skill can read everything in the host env: SUPABASE_KEY, SERVICE_ROLE_KEY, JWT_SECRET, MINIO_SECRET_KEY, NEXENT_POSTGRES_PASSWORD, EXA_SEARCH_API_KEY, etc. (all defined in backend/consts/const.py). A two-line skill like import os; print(os.environ) exfiltrates production secrets to the agent's stdout, which is then surfaced back through the LLM.

Suggested fix

Pass an allow-listed env explicitly:

ALLOWED_PASSTHROUGH = {"PATH", "HOME", "LANG", "LC_ALL", "TZ", "PYTHONPATH"}
safe_env = {k: v for k, v in os.environ.items() if k in ALLOWED_PASSTHROUGH}
safe_env.update(skill_specific_env)  # if the skill needs any
result = subprocess.run(..., env=safe_env)

…and document an explicit "your skill receives a sandboxed env; declare what you need" contract.

A stronger fix — given skills come from external authors — would be running them under a container/jail with no network and a read-only FS, but the env scope-down is the minimum.

Category: H (security hardening). Severity: High in a multi-tenant deployment.