[Feat]: Optional container-backed skill execution for high-risk domains (sub-issue of #17)

[rosspeili]

Feature Description

Sub-issue of #17. Design RFC Option 3 (containerization) as an opt-in path for high-risk skill categories (e.g. future security/, network-heavy, or operator-supplied skills) — not the default for the core registry.

Design deliverables:

1. Manifest extension proposal (comment on [RFC]: Security Sandboxing Strategies for Untrusted Skills #17 before coding):

   • e.g. execution: in_process | container
   • Optional container.image or Dockerfile path relative to skill bundle

2. Host contract:

   • How SkillLoader (or external orchestrator) invokes container with JSON params on stdin / env
   • Network policy defaults (deny egress except allowlist?)
   • Single-use vs reusable containers

3. Reference implementation or detailed pseudo-flow for one demo skill

4. Document operator requirements (Docker/Podman installed, rootless mode, CI implications)

Phasing: Design + POC acceptable; making pdf_form_filler containerized is out of scope unless needed for demo.

Out of scope: Replacing in-process execution for all bundled registry skills

Rationale

Some proposed skills (#61 gatekeeper, #77 tool_call_guard, etc.) imply sensitive operations where in-process execution is unacceptable. Container path satisfies #17 for high-risk tier while keeping simple skills easy for junior contributors (in-process default).

Implementation Idea

• Optional skill bundle layout: Dockerfile + thin skill.py wrapper or HTTP entrypoint inside container
• CLI: skillware run --isolated compliance/example_skill --params '{"key": "value"}'
• Use docker run --rm -i --network none (spike) with mounted read-only skill data only
• Security review checklist for container images in CONTRIBUTING
• Link parent [RFC]: Security Sandboxing Strategies for Untrusted Skills #17 and trust-model tiers (Tier C external + container = recommended path)