[RFC]: Security Sandboxing Strategies for Untrusted Skills

[rosspeili]

Summary

Currently, when SkillLoader loads a third-party Python skill, the loader.exec_module(module) call executes the skill's Python code within the identical process, memory space, and privileges as the host application.

If a user installs an untrusted or malicious skill from the internet, it has full access to the file system and environment variables (including all API keys). We need a community consensus on how to isolate or sandbox skill execution.

Motivation

To prevent catastrophic security breaches. As Skillware aims to be the "App Store" for Agents, users must be able to download and run community-created skills without fear of their root machine being compromised or their API keys being exfiltrated.

Detailed Design

We need community feedback on the most viable path forward for the core framework. Potential avenues for implementation:

1. Lightweight (Trust-Based): Add explicit documentation warnings and require a --trust-remote-code flag when loading skills not shipped with the core repo.
2. Medium (WASM/Pyodide): Restrict skill skill.py executions to a Python WebAssembly runtime via Pyodide, heavily constraining system imports like os and subprocess.
3. Heavy (Containerization): Deprecate raw Python execution for high-risk domains and instead require skills to provide a Dockerfile, executing their tool calls inside isolated, single-use, network-restricted containers.

The goal of this RFC is to decide which path balances "ease of use for contributors" vs "safety for users" before 1.0.

Drawbacks

• Implementing strict WASM or Docker sandboxing drastically increases the complexity of the framework.
• It will make it much harder for junior developers to contribute simple skills to the library.
• It may drastically slow down execution times for tool calls during the agent loop.