A skill written by Wing Zero, Ethan Troy’s agent, for inbound "can you look at this / review this for me" requests.
Triage: classify artifact type and risk tier.
Evaluate: produce grounded, severity-ordered findings.
Sandbox: when runtime evidence is necessary, keep untrusted execution off the agent host.
Sandbox policy
Use cloud-first infrastructure placement to keep cold inbound workloads off hardware and networks the operator owns. This reduces operational blast radius; it does not prove that every cloud runtime has stronger isolation.
The backend inventory distinguishes purpose-built managed sandboxes from cloud VMs/GPU providers, deployment platforms, browser workspaces, coding-agent workspaces (including Cursor Cloud Agents), and self-hosted research tools. All account access must be verified locally.
Before execution, verify isolation, egress, credentials, tenancy, lifecycle, auditability, region, and cost.
Install
GitHub gists are flat. Clone this gist using the ID shown in its URL, then map the files into Hermes:
gh gist clone <GIST_ID> review-triage-eval-gist
BASE="$HOME/.hermes/skills/software-development/review-triage-eval"
mkdir -p "$BASE/references" "$BASE/templates"
cp review-triage-eval-gist/SKILL.md "$BASE/"
cp review-triage-eval-gist/artifact-routing.md "$BASE/references/"
cp review-triage-eval-gist/sandbox-policy.md "$BASE/references/"
cp review-triage-eval-gist/sandbox-backend-inventory.md "$BASE/references/"
cp review-triage-eval-gist/review-report.md "$BASE/templates/"
Start a new Hermes session or load /skill review-triage-eval.
This inventory prevents the main routing table from collapsing back to whichever three providers were used most recently. It is a consideration set, not a claim that every service is configured, equally isolated, or appropriate for hostile code.
Verify current account access, product docs, isolation, egress, credential handling, region, lifecycle, auditability, limits, and price immediately before use.
Purpose-built managed cloud sandboxes
Service
Access check
Isolation / shape
Best fit
Critical checks
Modal Sandbox
Verify locally
gVisor-based managed sandbox
General repo install/test, Python, CPU/GPU
Use Sandbox API; block/allowlist egress; no broad Modal workspace secrets
Daytona
Verify locally
Full composable cloud computer; verify current runtime
Get runtime evidence for untrusted or unfamiliar projects without contaminating the Hermes host, the operator laptop, owned bare metal, or the home/office LAN.
Policy (read this first)
For cold inbound “review / run / install this” work:
Use cloud-first infrastructure placement so workloads do not execute on infrastructure or networks the operator owns.
Do not equate “cloud” with proven stronger isolation. Verify the provider's isolation boundary, default egress, credential exposure, tenancy, lifecycle controls, auditability, region, and cost.
Prefer purpose-built managed sandboxes over generic serverless containers or persistent VMs.
Treat a self-hosted Firecracker lab as secondary: lab R&D, explicit operator request, or no suitable cloud backend with verified controls.
Never install/run untrusted inbound code on the Hermes host (terminal.backend: local).
Rationale: cloud-first placement keeps operational blast radius off owned hardware and the home/office LAN. Boundary strength is a separate question that must be checked per provider and configuration. A home Firecracker lab remains valuable for building and studying isolation, but it is not the default detonation chamber for random internet artifacts.
Isolation tiers
Tier
Mechanism
Role for inbound review
Managed cloud sandbox
Modal, Daytona, Novita Agent Sandbox
Preferred default for untrusted install/run
Disposable cloud VM
exe.dev / similar
Preferred when full Linux SSH is needed
Serverless container
GCP Cloud Run / jobs
Preferred for deploy-shaped container smoke
Self-hosted microVM
Firecracker + jailer on owned KVM host
Secondary; lab/research or fallback
Local container
Hermes Docker / Docker/Podman
Last resort; still on owned host kernel
Host
Hermes local
Forbidden for untrusted install/run
Backend catalog
Priority
Backend
Best for
Required controls / limits
Hermes skill
1
Purpose-built managed cloud sandbox whose controls fit
Default untrusted install/test
Verify isolation, egress, credentials, tenancy, TTL, auditability, region, and cost
provider docs/skill
1a
Modal Sandbox
General install/test, temporary dependencies, CPU/GPU
Sandbox API; restrict/block egress; no workspace secrets
hermes-modal-backend-setup, modal-serverless-gpu
1b
Vercel Sandbox
Full Linux microVM, snapshots/drives, Node/JS control
Rootless/constrained; no socket, host network, home mount, or privileges
Hermes config
✗
Hermes host local
Static read/clone only
Never execute untrusted inbound code
n/a
For the complete consideration set, including Browserbase, Cursor Cloud Agents, RunPod, Vast, AWS, Vultr, Railway, Hugging Face Spaces, Gondolin, Arrakis, AIO Sandbox, cagent, and Dyana, read references/sandbox-backend-inventory.md.
This is a selection default, not an isolation-strength leaderboard. Pick by required capability, then verify the controls. Cloud-first answers where blast radius lives; the provider's technical boundary answers how strong the isolation is.
Self-hosted Firecracker lab (plain English)
Optional secondary backend, not a brand requirement:
Linux host with KVM (/dev/kvm)
Firecracker microVMs, ideally under jailer, with cgroup/network limits
Public reports should say “self-hosted Firecracker microVM,” not private host nicknames.
When sandbox is mandatory
User asks to run, install, build, boot, or "try" inbound code
Dynamic malware/behavior suspicion after static scan
Need test suite results and environment is non-trivial
Need browser-against-local-server evidence for an untrusted app
When sandbox is optional
Pure docs/PDF/spec review
Public website copy/UX review
PR review answerable from diff + existing CI
Script fully understood statically and user only wanted a read
Preflight before any create
Confirm risk tier (R3/R4).
Prefer cloud backend auth check first (Modal/Daytona/Novita/exe.dev/GCP).
Estimate cost/quota; mention if non-zero or uncertain.
Ephemeral settings: auto-delete / short TTL / explicit destroy.
Egress: none → registries-only → open (open last).
Do not forward Hermes .env, cloud admin creds, or SSH agent by default.
Only after cloud options fail or operator opts in: consider self-hosted Firecracker, and say so in the report.
Backend notes
Modal Sandbox (preferred cloud default)
First choice for “install and smoke this repo” when the controls fit.
Use the purpose-built Modal Sandbox API for untrusted arbitrary code. Do not assume a generic Modal Function or simply setting a terminal backend has identical isolation or network controls.
Start with block_network=True when dependencies are already present; otherwise use explicit outbound CIDR/domain allowlists where supported.
Do not authorize the sandbox to access unrelated workspace resources or inject broad secrets.
If Hermes terminal.backend: modal is used, verify what runtime path it invokes and restore terminal.backend: local afterward.
Report cost/credits when non-trivial.
Daytona
Ephemeral create + auto-delete or explicit delete.
Network-block until install needs egress.
Capture id; never print API keys; report cost + deletion state.
Novita Agent Sandbox
E2B-compatible interpreter / agent sandbox.
Kill after evidence; pass only scoped secrets; report billable time.
exe.dev
Lobby/API for lifecycle; SSH for real shell.
Stop/delete when done; no tokens in remotes/chat.
GCP Cloud Run jobs (deploy-shaped validation only)
Cloud Run is a managed container platform, not a general arbitrary-code sandbox.
Use a job, not a public service, for one-shot validation whenever possible.
No public ingress; no privileged mode; no sensitive service account; no mounted production secrets; restrict outbound networking.
Select the correct account/project and enforce billing guardrails.
Delete the job and ephemeral images/artifacts after evidence collection.
If the project requires broader identity/network access, choose a purpose-built sandbox instead.
Self-hosted Firecracker (secondary)
Use for lab R&D or when operator explicitly wants local microVMs.
Prefer jailed VMs + deny/restricted egress.
Upload only needed files; reap after.
Report residual risk: workload ran on operator-owned host/network.
Do not default cold inbound malware-ish runs here.
Hermes Docker / local containers
No privileged, no docker.sock, no host network.
Clean work dir only; remove artifacts after.
Shared-kernel residual risk on owned host: say so.
GPU-only providers
Only if the review question requires GPU.
Credential hygiene
Do not forward Hermes .env, cloud admin creds, or SSH agent by default.
Scoped throwaway tokens only; revoke after.
Assume sandbox FS may be exfiltrated if egress is open.
Evidence to collect
Backend used and why (especially if not cloud-first)
Isolation class: managed cloud sandbox / cloud VM / serverless container / self-hosted microVM / local container
Triage and evaluate inbound 'can you look at this / review this for me' asks: classify the artifact, route the right review lens, optionally run untrusted projects in an isolated sandbox, and return a short severity-ordered verdict.
version
0.0.1
author
Wing Zero, Ethan Troy's agent
license
MIT
metadata
hermes
tags
related_skills
review
triage
evaluation
sandbox
untrusted-code
intake
second-look
software-design-review
web-application-security-review
website-review-audits
software-supply-chain-security
github-operations
firecracker-microvm-sandboxing
daytona
hermes-modal-backend-setup
modal-serverless-gpu
browser-automation-platforms
cloudflare-site-deployment-operations
exe-dev-vm-operations
gcp-cloud-run-sandbox-operations
novita-ai
Review Triage & Sandbox Eval
Use this when someone dumps an artifact on the user with:
"can you review this for me"
"look at this"
"what do you think of this"
"check this out / is this legit / is this safe / should I use this"
a bare URL, repo, PR, gist, PDF, screenshot, tarball, or "run this and tell me"
This is the intake desk, not a replacement for deep domain skills. Triage first, then evaluate, then sandbox only when execution evidence is needed.
Default posture: direct, grounded, severity-ordered. Lead with the verdict. Do not narrate the artifact.
Hard rules
Untrusted by default. Treat inbound code, installers, scripts, Dockerfiles, notebooks, browser extensions, and unknown repos as hostile until proven otherwise.
No host execution of untrusted code. Do not npm install, pip install, docker compose up, or run build/test/start scripts from an inbound project on the Hermes host or user machine. Use an isolated sandbox.
Read-only first. Prefer clone/fetch + static inspection before any runtime.
No third-party exploitation. Authorized local/sandbox analysis only. No attacking live third-party systems.
No secrets in reports. Redact tokens, cookies, private keys, and personal data. Never paste raw credentials into chat, gist, or skill files.
Paid compute needs a cost line. If you create Daytona/exe.dev/cloud sandboxes or other paid resources, report estimated cost and clean up unless the user wants persistence.
Do not auto-publish, email, or post reviews externally unless the user explicitly asks.
Workflow
- Intake — identify the artifact
Capture:
Field
Notes
Source
URL, repo, PR, file path, screenshot, paste, Slack/Discord/email link
Stated ask
What the requester wants (review, safety, quality, install help, opinion)
User goal
What this user needs from the review (personal use, security, OSS advice, product feedback)
Time budget
Quick pass vs deep dive (default: useful triage in one pass)
Trust context
Known author/org? internal? cold inbound?
If the ask is ambiguous but the artifact is clear, default to a useful triage review instead of asking clarifying questions. Only clarify when the ambiguity changes safety or cost materially.
Evidence — cite files, URLs, commands, status codes, sandbox output. Separate observation from opinion.
Decision — ship / use / fork / avoid / needs-more-work, with conditions.
For websites, load the page and verify links/assets rather than guessing. For repos, inspect tree, README, lockfiles, CI, entrypoints, and dependency manifests before concluding. For PRs, review the actual diff and tests, not only the PR body.
- Sandbox — only when runtime evidence is needed
Use sandbox when the ask requires:
"does it build / install / boot?"
"what happens when you run it?"
"repro this bug"
dynamic behavior you cannot prove statically
Never use the Hermes host shell as the untrusted workload runtime.
Sandbox selection
Pick by where the workload runs first, then feature fit. Full policy: references/sandbox-policy.md. Full provider inventory, including services that are known but not currently authenticated: references/sandbox-backend-inventory.md.
Policy for inbound untrusted code: use cloud-first infrastructure placement so cold inbound workloads do not execute on bare metal or networks the operator owns. This limits operational blast radius, but it does not prove that every cloud runtime has a stronger isolation boundary. Before execution, verify the selected provider's actual isolation model, default egress, credential exposure, tenancy, lifecycle controls, and auditability. Prefer purpose-built managed sandboxes over generic cloud containers or persistent VMs.
Default order, overridden by capability and verified controls:
Priority
Backend
Use when
Required security posture
Load skill
1
Purpose-built managed cloud sandbox whose controls fit
Default for untrusted install/test
Verify isolation, egress, credentials, tenancy, TTL, auditability, region, and cost
provider skill/docs
1a
Modal Sandbox
General install/test, temporary dependencies, CPU/GPU work
Use Sandbox API; restrict/block egress; generic Modal Functions are not assumed equivalent
hermes-modal-backend-setup, modal-serverless-gpu
1b
Vercel Sandbox
Full Linux microVM, Node/JS control plane, snapshots/drives/network policy
Verify account access; start deny-all; use scoped Vercel identity
Specialized hardware or full machine only when sandbox products do not fit
Disposable account/project, no trusted network, scoped identity, cost cap, destroy
provider skills
6
Self-hosted Firecracker microVM lab
Explicit lab/research work, operator opt-in, or suitable cloud backends unavailable
Jailer; deny/restricted egress; no trusted LAN reach; disclose owned-infrastructure residual risk
firecracker-microvm-sandboxing (+ private lab skill if any)
7
Hermes Docker backend / local Docker
Last resort
Rootless/constrained; no Docker socket, host network, home mount, or privileges
Hermes config
✗
Hermes host / terminal.backend: local
Static read/clone only
Never execute untrusted inbound code
n/a
This order is not an isolation-strength leaderboard. Choose the highest suitable cloud option whose controls are verified. For example, use Daytona for preview-heavy application review, Novita for an E2B-style interpreter, exe.dev when real SSH/persistence is essential, and Cloud Run only for deploy-shaped container checks.
Why cloud before home Firecracker: Even a well-jailed microVM still runs on your machine and network. For cold inbound “review/run this,” blast radius belongs in a provider sandbox with separate tenancy, not on a mini PC under your desk. Use the self-hosted lab when you are intentionally developing Firecracker/orchestrator behavior, not as the default malware/untrusted-run target.
What “self-hosted Firecracker lab” means (for readers): A dedicated Linux machine with KVM where you run Firecracker microVMs (usually under jailer). Host form factors include mini PCs, NUCs, or bare metal. Orchestration CLIs vary (firectl, custom tools, capsule/fcctl/fcx, etc.). Optional; skip if you do not operate one.
Fast chooser:
Default “run/install this for me” → purpose-built managed cloud sandbox with verified controls
General Python/Node test → Modal Sandbox, E2B, Vercel Sandbox, Daytona, or Novita based on access and controls
Need full Linux + preview URL / file APIs → Daytona or Vercel Sandbox
Need Firecracker-backed managed cloud → E2B or Vercel Sandbox; verify current product implementation
One-shot JS/Python isolate → Cloudflare Dynamic Workers with no bindings and outbound blocked
Full Linux on Cloudflare → Cloudflare Sandbox SDK; remember it is container-backed
E2B-style code interpreter API → E2B or Novita Agent Sandbox
Need full VM SSH, persistence, or branching → exe.dev or Vers VMs with explicit deletion
Need deploy-shaped container validation → Cloud Run job only, hardened identity/networking, then delete
Browser-only/UI review → Browserbase; pair it with a code sandbox if the reviewed app server is untrusted
Suspicious model/binary/file profiling → Dyana inside a purpose-built cloud sandbox
GPU-heavy review → Modal GPU, RunPod, Vast, or another verified cloud provider only if needed; report cost
No cloud backend with verified controls → static-only/refuse runtime, or operator-approved self-hosted fallback with residual-risk disclosure
Do not leave Hermes default terminal.backend stuck on a cloud backend after the review unless the user asked for that steady state. For Modal, prefer an explicit Modal run or a temporary backend switch with restore to local.
Minimum sandbox procedure:
1. Create ephemeral sandbox (name it review-<short-slug>-<date>)
2. Clone or upload ONLY the target artifact
3. Inspect before install (tree, manifests, scripts)
4. Install/build with pinned commands; capture logs
5. Run the smallest smoke that answers the question
6. Collect evidence (exit codes, key log lines, URLs, screenshots if UI)
7. Tear down sandbox unless user asks to keep it
8. Report cost/duration + residual artifacts
Network policy:
Prefer blocked or allowlisted egress for R3/R4.
If package install needs egress, allow registry domains only when possible.
Treat unexpected egress destinations as findings.
- Report — short by default
Use templates/review-report.md. Default shape:
## Verdict
<1-3 sentences: what it is + whether to use/ship/engage + main reason>
## Triage
| Field | Value |
|---|---|
| Type | ... |
| Risk tier | R0–R4 |
| Scope reviewed | ... |
| Sandbox | none / provider + id + destroyed? |
## Findings
| Pri | Finding | Evidence | Fix / next step |
|---|---|---|---|
| P0 | | | |
| P1 | | | |
| P2 | | | |
## What’s good
- ...
## Recommended action
- For the requester / for you:
- Keep / fork / ignore / deep-dive next:
## Verification performed
- commands, URLs checked, sandbox smoke results
Severity:
P0 — unsafe to run/use, broken primary promise, active secret exposure, critical trust failure
P1 — important security/quality gap, misleading docs, missing authz, high footgun
Promote to R3 + sandbox only if user wants run/build proof
"Run this project and tell me"
R3/R4
Sandbox immediately after light static preflight
Report runtime evidence + cleanup
PR / patch review
pr-diff
Diff-first; run tests in sandbox if environment is foreign or deps are heavy
Compose with design/security skills as needed
Screenshot / Slack "can you review this?"
Extract the actual ask and artifact
If the artifact is external, fetch/review the source of truth
Return: summary of ask + recommended reply + risks
Anti-patterns
Running curl | bash or unsigned installers on the host
Declaring a site "secure" from homepage copy alone
Security theater (generic OWASP laundry lists with no evidence)
Multi-page essays when a triage table answers the ask
Keeping sandboxes alive "just in case" without saying so
Trusting README architecture diagrams over code
Treating container isolation as equal to microVM isolation for hostile code
Backend catalog drift that omits the maintained consideration set (Modal, E2B, Vercel Sandbox, Daytona, Cloudflare Dynamic Workers/Sandbox SDK, Novita, exe.dev/Vers) or conflates adjacent platforms (Browserbase, Cursor Cloud Agents, generic GPU/VM/deploy services) with general sandboxes — maintain references/sandbox-backend-inventory.md
Defaulting cold inbound untrusted runs onto a home Firecracker lab when cloud sandboxes are available — keep blast radius off owned LAN hardware unless the operator explicitly wants lab/R&D execution
Maintaining the backend inventory
Do not reconstruct the provider list from model memory or the last few tools used.
Inspect the operator's source-of-truth platform/sandbox inventory first (for this installation: Obsidian AI/AI Sandboxing MOC.md, AI/Platforms/AI Platforms MOC.md, and System/AI Tooling Inventory.md).
Reconcile it with live capability evidence: enabled MCP/tools, command availability, and credential names only (never values).
Classify every candidate into one of four groups:
purpose-built managed cloud sandbox;
generic cloud VM/GPU/deploy platform;
browser or cloud-agent workspace;
self-hosted/research option.
Record status locally as connected, known but auth unverified, or research/watch; do not expose operator account status in the public package.
Verify current official docs for isolation, egress defaults, credential behavior, lifecycle, and product availability before recommending a provider. Product names in the inventory are a consideration set, not timeless security claims.
When the inventory changes, update SKILL.md, references/sandbox-policy.md, and references/sandbox-backend-inventory.md together, then bump the version and re-publish/verify the public artifact.
This source-first reconciliation is required whenever the user asks "did we consider all the services I use?" A shortlist inferred from current skills or environment variables is not an exhaustive inventory.
Support files
references/artifact-routing.md — deeper type → checks matrix