T09 · Insecure Skill Coding Practices
- Location
SKILL.md:120- Finding
Untrusted Skill Execution Without Sandboxing or Access Control
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:120-121,SKILL.md:337,SKILL.md:353, andSKILL.md:468-469
Vulnerability Type: Untrusted instructions executed through an agent with Bash access
Risk Level: HighVulnerable Code and Instructions
English rendering of
SKILL.md:120-121:text - Do not implement security sandbox isolation during the MVP phase. - Do not implement user authentication or permission management during the MVP phase.SKILL.md:337:python skill_path = f"skills/{skill_name}/SKILL.md"The execution example subsequently loads the selected Skill into an agent and executes it:
python with open(skill_path, "r", encoding="utf-8") as f: skill_content = f.read() agent = Agent(skill_content=skill_content) result = await agent.execute(parameters)English rendering of
SKILL.md:353:text The Agent SDK executes the Skill and may invoke Bash tools and the Claude API.English rendering of
SKILL.md:468-469:text Security is deferred to a later iteration. Skills can execute arbitrary CLI commands.Technical Analysis
The proposed platform accepts user-supplied
SKILL.mdcontent and passes that content to an execution-capable agent. The agent is explicitly expected to have access to Bash and external APIs. At the same time, the MVP design explicitly excludes authentication, authorization, and execution sandboxing.A
SKILL.mdfile is not passive data when supplied to an agent. It contains instructions that can influence tool calls and command execution. Consequently, an uploaded Skill must be treated as untrusted executable content. Passing it directly to an agent with Bash access crosses a critical trust boundary.No command allowlist, filesystem boundary, network restriction, credential isolation, approval workflow, or per-execution container is specified. An attacker could therefore construct Skill instr ...[truncated 1771 chars]
- Remediation
View remediation
Remediation Suggestions
Treat isolation and access control as release blockers rather than deferred enhancements.
-
Authenticate every operation
- Require authentication for upload, analysis, execution, status, and deletion endpoints.
- Enforce ownership and explicit authorization checks for each Skill and execution job.
- Apply rate limits and execution quotas per identity.
-
Use an isolated execution environment
- Run each Skill invocation in a new ephemeral container or microVM.
- Use a non-root identity with no host namespace access.
- Do not mount the Docker socket, host filesystem, SSH agents, or cloud credential directories.
- Make the root filesystem read-only and provide only a small disposable working directory.
- Destroy the environment after each invocation.
-
Restrict tools and commands
- Disable Bash by default.
- Grant only the tools explicitly required by an approved Skill.
- If command execution is essential, use an argument-aware allowlist rather than shell-string filtering.
- Prohibit shell metacharacters, indirect interpreters, and arbitrary subprocess creation.
-
Restrict network access
- Deny outbound network access by default.
- Allow only explicitly approved domains and protocols through an egress proxy.
- Block cloud metadata endpoints, localhost services, private address ranges, and internal control-plane networks.
-
Protect credentials
- Do not expose backend-wide secrets to Skill processes.
- Issue short-lived, narrowly scoped credentials for individual executions.
- Use a secret broker and redact sensitive values from prompts, logs, and results.
-
Add admission controls
- Parse and statically inspect uploaded Skills before publication.
- Require manual approval for Skills requesting command execution or network access.
- Record immutable audit logs for upload, approval, tool calls, ...[truncated 204 chars]
-