Unikraft Cloud Sandbox

Run agent tasks inside an isolated Unikraft Cloud (UKC) sandbox VM. Use when the agent needs a clean, isolated execution environment — e.g. running untrusted...

Security Scan

The skill's code and runtime instructions mostly match its stated purpose (provisioning and using short-lived UKC sandboxes) but the registry metadata omits required credentials and required host binaries, and the runtime performs destructive syncs and manages private SSH keys — the mismatches and operational risks warrant caution.

Purpose & Capability

The SKILL.md and bundled scripts clearly require UKC credentials (UKC_TOKEN, UKC_METRO, UKC_USER, UKC_SANDBOX_IMAGE) and perform UKC API calls to create/delete instances; however the registry metadata lists no required environment variables. That metadata omission is an incoherence: the skill legitimately needs the listed UKC env vars, so the manifest is incomplete/misleading.

Instruction Scope

Instructions explicitly create SSH keypairs under /tmp, persist a private key and FQDN there, perform file syncs (rsync) and remote command execution (exec API or SSH), and warn that sync-to-sandbox.sh uses --delete. Those operations are expected for a sandbox but are consequential: files and secrets from the local session will be uploaded to the sandbox (and deletions on the remote can occur on sync), private keys are stored on disk until deletion, and the scripts assume binaries and tools that are not declared. No instructions ask for unrelated host data, but the destructive sync + private key lifecycle and missing binary declarations are notable.

Install Mechanism

This is instruction-only with shipped scripts (no package downloads or external installers). That limits install-time risk. However the scripts rely on host binaries (curl, jq, ssh-keygen, ssh, rsync, openssl, node) that the metadata does not declare; the absence of an install spec is reasonable, but the missing required-binaries declarations are an operational/incoherence issue.

Credentials

The skill requires a bearer token (UKC_TOKEN) and UKC_METRO base URL to create/delete instances — these are necessary for the stated purpose. But the registry claimed no required env vars, so the manifest underdeclares sensitive credentials. Also UKC_TOKEN is powerful (it can list/create/delete instances) — users should ensure the token has minimal privileges and that storing it in environment variables is acceptable. UKC_USER is declared in SKILL.md but not clearly used in scripts; that's another small inconsistency.

Persistence & Privilege

The skill is not always-enabled, does not request system-wide config changes, and limits persistent state to /tmp/<sandbox-name> (SSH keys, fqdn). It does create and delete remote cloud instances (expected) but does not modify other skills. The agent's ability to invoke the skill autonomously is the default and not by itself a red flag.

What to consider before installing

This skill appears to implement a real UKC sandbox workflow, but there are important mismatches and operational risks you should consider before installing: - Manifest vs runtime mismatch: the registry metadata lists no required environment variables or binaries, but the SKILL.md and scripts require UKC_TOKEN, UKC_METRO, UKC_USER, UKC_SANDBOX_IMAGE and host tools (curl, jq, ssh-keygen, ssh, rsync, openssl, node). Treat the SKILL.md as authoritative and ensure these exist. - Sensitive token risk: UKC_TOKEN is a bearer token able to manage instances. Only provide a minimal-scope, revocable token and understand that the skill will use it to create and delete instances via your UKC_METRO endpoint. - Private key lifecycle: create-sandbox.sh writes an SSH private key to /tmp/<sandbox-name>/id_ed25519 and delete-sandbox.sh removes that directory only when you run it. If you fail to delete the sandbox, the private key and instance may persist — remember to delete sessions to remove the key and instance. - Destructive sync: sync-to-sandbox.sh uses rsync --delete; files on the remote /workspace that don't exist locally will be removed. Do not rely on persistent data on the sandbox unless you know the sync behavior. - Data exposure on sandbox: anything you sync or run in the sandbox (including secrets) will be present on that remote VM while it exists. Avoid syncing credentials or other sensitive data unless you're certain the UKC provider and image are trusted. - Binaries and dependencies: confirm the host environment has curl, jq, ssh-keygen, ssh, rsync, openssl and node available and that their versions/behaviors are acceptable; the skill does not declare these requirements. If you still want to use it: provide a minimal-scoped UKC_TOKEN, verify and test create/delete on a disposable account, and ensure you always run the delete-sandbox.sh step to remove keys and instances. If possible, request the publisher to update the registry metadata to declare the required env vars and required host binaries to remove the manifest incoherence.

Unikraft Sandbox

Runs tasks inside a per-session Unikraft Cloud (UKC) sandbox VM. One sandbox per session.

Full API shapes: see references/ukc_api.md.

---

Prerequisites

Check that these env vars are set before proceeding. They are inherited by all child processes (scripts, curl calls) automatically — no injection needed.

• UKC_TOKEN, UKC_METRO, UKC_USER, UKC_SANDBOX_IMAGE

If any are missing, stop and ask the user to export them.

---

Session State

Hold these in memory for the duration of the session:

• sandbox_name — generated name (also the tmp dir name under /tmp/)
• session_dir — local directory to sync with the sandbox (task-specific)

The FQDN is persisted to /tmp/<sandbox-name>/fqdn by create-sandbox.sh and read from there by other scripts — no need to track it separately in memory.

---

Lifecycle

1. Create sandbox

Generate a name: sandbox-<short-session-id>-<unix-timestamp> (lowercase, hyphens only, valid as a directory name). Store as sandbox_name.

bash scripts/create-sandbox.sh <sandbox-name>

Capture stdout as sandbox_fqdn. The script:

• Checks if a sandbox with that name already exists — exits with an error if so
• Creates /tmp/<sandbox-name>/ with the SSH keypair inside
• Creates the UKC instance (passing the pubkey)
• Prints the instance FQDN

2. Sync local → sandbox (before a task)

bash scripts/sync-to-sandbox.sh <sandbox-name> <session-dir>

⚠️ Destructive sync: sync-to-sandbox.sh uses --delete, meaning any files present in /workspace on the sandbox that don't exist locally will be deleted. Do not manually create files in /workspace that you want to keep — they will be wiped on the next sync.

3. Execute commands

Prefer the exec API for most commands:

node scripts/exec-sandbox.js "$(cat /tmp/<sandbox-name>/fqdn)" "cd /workspace && <your command>"

Check exit code. Non-zero means the command failed. See references/ukc_api.md for response shape.

Use SSH directly only for interactive/PTY needs:

ssh -i /tmp/<sandbox-name>/id_ed25519 \
  -o StrictHostKeyChecking=no \
  -o ProxyCommand="openssl s_client -quiet -connect $(cat /tmp/<sandbox-name>/fqdn):2222 2>/dev/null" \
  root@"$(cat /tmp/<sandbox-name>/fqdn)"

4. Sync sandbox → local (after a task)

bash scripts/sync-from-sandbox.sh <sandbox-name> <session-dir>

5. Delete sandbox

When the session ends or the sandbox is no longer needed:

bash scripts/delete-sandbox.sh <sandbox-name>

This removes the UKC instance and the local /tmp/<sandbox-name>/ directory (including SSH keys).

---

Error Handling

Situation	Action
Required env var missing	Stop, ask user to export it
create-sandbox.sh fails	Surface the error; do not proceed
Exec API returns non-200	Surface .error; treat as hard failure
code non-zero in exec response	Command failed; surface .stderr
SSH connection refused	Sandbox may be suspended; retry after a few seconds