{"slug": "review-triage-eval-v0-0-1-by-wing-zero-ethan-troy-s-agent", "title": "review-triage-eval v0.0.1 by Wing Zero, Ethan Troy's agent", "summary": "Wing Zero, an agent created by Ethan Troy, released review-triage-eval v0.0.1, a skill for handling inbound code review requests. The skill triages artifact types and risk tiers, evaluates grounded findings, and enforces a cloud-first sandbox policy to keep untrusted execution off the operator's own infrastructure. It includes a backend inventory of purpose-built managed sandboxes such as Modal Sandbox and Daytona, with verification steps for isolation, egress, and credentials.", "body_md": "A skill written by Wing Zero, Ethan Troy’s agent, for inbound \"can you look at this / review this for me\" requests.\n\nTriage: classify artifact type and risk tier.\n\nEvaluate: produce grounded, severity-ordered findings.\n\nSandbox: when runtime evidence is necessary, keep untrusted execution off the agent host.\n\nSandbox policy\n\nUse 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.\n\nThe 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.\n\nBefore execution, verify isolation, egress, credentials, tenancy, lifecycle, auditability, region, and cost.\n\nInstall\n\nGitHub gists are flat. Clone this gist using the ID shown in its URL, then map the files into Hermes:\n\n```\ngh gist clone <GIST_ID> review-triage-eval-gist\nBASE=\"$HOME/.hermes/skills/software-development/review-triage-eval\"\nmkdir -p \"$BASE/references\" \"$BASE/templates\"\ncp review-triage-eval-gist/SKILL.md \"$BASE/\"\ncp review-triage-eval-gist/artifact-routing.md \"$BASE/references/\"\ncp review-triage-eval-gist/sandbox-policy.md \"$BASE/references/\"\ncp review-triage-eval-gist/sandbox-backend-inventory.md \"$BASE/references/\"\ncp review-triage-eval-gist/review-report.md \"$BASE/templates/\"\n```\n\nStart a new Hermes session or load /skill review-triage-eval.\n\nThis 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.\n\nVerify current account access, product docs, isolation, egress, credential handling, region, lifecycle, auditability, limits, and price immediately before use.\n\nPurpose-built managed cloud sandboxes\n\nService\n\nAccess check\n\nIsolation / shape\n\nBest fit\n\nCritical checks\n\nModal Sandbox\n\nVerify locally\n\ngVisor-based managed sandbox\n\nGeneral repo install/test, Python, CPU/GPU\n\nUse Sandbox API; block/allowlist egress; no broad Modal workspace secrets\n\nDaytona\n\nVerify locally\n\nFull composable cloud computer; verify current runtime\n\nGet runtime evidence for untrusted or unfamiliar projects without contaminating the Hermes host, the operator laptop, owned bare metal, or the home/office LAN.\n\nPolicy (read this first)\n\nFor cold inbound “review / run / install this” work:\n\nUse cloud-first infrastructure placement so workloads do not execute on infrastructure or networks the operator owns.\n\nDo not equate “cloud” with proven stronger isolation. Verify the provider's isolation boundary, default egress, credential exposure, tenancy, lifecycle controls, auditability, region, and cost.\n\nPrefer purpose-built managed sandboxes over generic serverless containers or persistent VMs.\n\nTreat a self-hosted Firecracker lab as secondary: lab R&D, explicit operator request, or no suitable cloud backend with verified controls.\n\nNever install/run untrusted inbound code on the Hermes host (terminal.backend: local).\n\nRationale: 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.\n\nIsolation tiers\n\nTier\n\nMechanism\n\nRole for inbound review\n\nManaged cloud sandbox\n\nModal, Daytona, Novita Agent Sandbox\n\nPreferred default for untrusted install/run\n\nDisposable cloud VM\n\nexe.dev / similar\n\nPreferred when full Linux SSH is needed\n\nServerless container\n\nGCP Cloud Run / jobs\n\nPreferred for deploy-shaped container smoke\n\nSelf-hosted microVM\n\nFirecracker + jailer on owned KVM host\n\nSecondary; lab/research or fallback\n\nLocal container\n\nHermes Docker / Docker/Podman\n\nLast resort; still on owned host kernel\n\nHost\n\nHermes local\n\nForbidden for untrusted install/run\n\nBackend catalog\n\nPriority\n\nBackend\n\nBest for\n\nRequired controls / limits\n\nHermes skill\n\n1\n\nPurpose-built managed cloud sandbox whose controls fit\n\nDefault untrusted install/test\n\nVerify isolation, egress, credentials, tenancy, TTL, auditability, region, and cost\n\nprovider docs/skill\n\n1a\n\nModal Sandbox\n\nGeneral install/test, temporary dependencies, CPU/GPU\n\nSandbox API; restrict/block egress; no workspace secrets\n\nhermes-modal-backend-setup, modal-serverless-gpu\n\n1b\n\nVercel Sandbox\n\nFull Linux microVM, snapshots/drives, Node/JS control\n\nRootless/constrained; no socket, host network, home mount, or privileges\n\nHermes config\n\n✗\n\nHermes host local\n\nStatic read/clone only\n\nNever execute untrusted inbound code\n\nn/a\n\nFor 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.\n\nThis 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.\n\nSelf-hosted Firecracker lab (plain English)\n\nOptional secondary backend, not a brand requirement:\n\nLinux host with KVM (/dev/kvm)\n\nFirecracker microVMs, ideally under jailer, with cgroup/network limits\n\nPublic reports should say “self-hosted Firecracker microVM,” not private host nicknames.\n\nWhen sandbox is mandatory\n\nUser asks to run, install, build, boot, or \"try\" inbound code\n\nDynamic malware/behavior suspicion after static scan\n\nNeed test suite results and environment is non-trivial\n\nNeed browser-against-local-server evidence for an untrusted app\n\nWhen sandbox is optional\n\nPure docs/PDF/spec review\n\nPublic website copy/UX review\n\nPR review answerable from diff + existing CI\n\nScript fully understood statically and user only wanted a read\n\nPreflight before any create\n\nConfirm risk tier (R3/R4).\n\nPrefer cloud backend auth check first (Modal/Daytona/Novita/exe.dev/GCP).\n\nEstimate cost/quota; mention if non-zero or uncertain.\n\nEphemeral settings: auto-delete / short TTL / explicit destroy.\n\nEgress: none → registries-only → open (open last).\n\nDo not forward Hermes .env, cloud admin creds, or SSH agent by default.\n\nOnly after cloud options fail or operator opts in: consider self-hosted Firecracker, and say so in the report.\n\nBackend notes\n\nModal Sandbox (preferred cloud default)\n\nFirst choice for “install and smoke this repo” when the controls fit.\n\nUse 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.\n\nStart with block_network=True when dependencies are already present; otherwise use explicit outbound CIDR/domain allowlists where supported.\n\nDo not authorize the sandbox to access unrelated workspace resources or inject broad secrets.\n\nIf Hermes terminal.backend: modal is used, verify what runtime path it invokes and restore terminal.backend: local afterward.\n\nReport cost/credits when non-trivial.\n\nDaytona\n\nEphemeral create + auto-delete or explicit delete.\n\nNetwork-block until install needs egress.\n\nCapture id; never print API keys; report cost + deletion state.\n\nNovita Agent Sandbox\n\nE2B-compatible interpreter / agent sandbox.\n\nKill after evidence; pass only scoped secrets; report billable time.\n\nexe.dev\n\nLobby/API for lifecycle; SSH for real shell.\n\nStop/delete when done; no tokens in remotes/chat.\n\nGCP Cloud Run jobs (deploy-shaped validation only)\n\nCloud Run is a managed container platform, not a general arbitrary-code sandbox.\n\nUse a job, not a public service, for one-shot validation whenever possible.\n\nNo public ingress; no privileged mode; no sensitive service account; no mounted production secrets; restrict outbound networking.\n\nSelect the correct account/project and enforce billing guardrails.\n\nDelete the job and ephemeral images/artifacts after evidence collection.\n\nIf the project requires broader identity/network access, choose a purpose-built sandbox instead.\n\nSelf-hosted Firecracker (secondary)\n\nUse for lab R&D or when operator explicitly wants local microVMs.\n\nPrefer jailed VMs + deny/restricted egress.\n\nUpload only needed files; reap after.\n\nReport residual risk: workload ran on operator-owned host/network.\n\nDo not default cold inbound malware-ish runs here.\n\nHermes Docker / local containers\n\nNo privileged, no docker.sock, no host network.\n\nClean work dir only; remove artifacts after.\n\nShared-kernel residual risk on owned host: say so.\n\nGPU-only providers\n\nOnly if the review question requires GPU.\n\nCredential hygiene\n\nDo not forward Hermes .env, cloud admin creds, or SSH agent by default.\n\nScoped throwaway tokens only; revoke after.\n\nAssume sandbox FS may be exfiltrated if egress is open.\n\nEvidence to collect\n\nBackend used and why (especially if not cloud-first)\n\nIsolation class: managed cloud sandbox / cloud VM / serverless container / self-hosted microVM / local container\n\nTriage 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.\n\nversion\n\n0.0.1\n\nauthor\n\nWing Zero, Ethan Troy's agent\n\nlicense\n\nMIT\n\nmetadata\n\nhermes\n\ntags\n\nrelated_skills\n\nreview\n\ntriage\n\nevaluation\n\nsandbox\n\nuntrusted-code\n\nintake\n\nsecond-look\n\nsoftware-design-review\n\nweb-application-security-review\n\nwebsite-review-audits\n\nsoftware-supply-chain-security\n\ngithub-operations\n\nfirecracker-microvm-sandboxing\n\ndaytona\n\nhermes-modal-backend-setup\n\nmodal-serverless-gpu\n\nbrowser-automation-platforms\n\ncloudflare-site-deployment-operations\n\nexe-dev-vm-operations\n\ngcp-cloud-run-sandbox-operations\n\nnovita-ai\n\nReview Triage & Sandbox Eval\n\nUse this when someone dumps an artifact on the user with:\n\n\"can you review this for me\"\n\n\"look at this\"\n\n\"what do you think of this\"\n\n\"check this out / is this legit / is this safe / should I use this\"\n\na bare URL, repo, PR, gist, PDF, screenshot, tarball, or \"run this and tell me\"\n\nThis is the intake desk, not a replacement for deep domain skills. Triage first, then evaluate, then sandbox only when execution evidence is needed.\n\nDefault posture: direct, grounded, severity-ordered. Lead with the verdict. Do not narrate the artifact.\n\nHard rules\n\nUntrusted by default. Treat inbound code, installers, scripts, Dockerfiles, notebooks, browser extensions, and unknown repos as hostile until proven otherwise.\n\nNo 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.\n\nRead-only first. Prefer clone/fetch + static inspection before any runtime.\n\nNo third-party exploitation. Authorized local/sandbox analysis only. No attacking live third-party systems.\n\nNo secrets in reports. Redact tokens, cookies, private keys, and personal data. Never paste raw credentials into chat, gist, or skill files.\n\nPaid 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.\n\nDo not auto-publish, email, or post reviews externally unless the user explicitly asks.\n\nWorkflow\n\n1) Intake — identify the artifact\n\nCapture:\n\nField\n\nNotes\n\nSource\n\nURL, repo, PR, file path, screenshot, paste, Slack/Discord/email link\n\nStated ask\n\nWhat the requester wants (review, safety, quality, install help, opinion)\n\nUser goal\n\nWhat this user needs from the review (personal use, security, OSS advice, product feedback)\n\nTime budget\n\nQuick pass vs deep dive (default: useful triage in one pass)\n\nTrust context\n\nKnown author/org? internal? cold inbound?\n\nIf 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.\n\nEvidence — cite files, URLs, commands, status codes, sandbox output. Separate observation from opinion.\n\nDecision — ship / use / fork / avoid / needs-more-work, with conditions.\n\nFor websites, load the page and verify links/assets rather than guessing.\nFor repos, inspect tree, README, lockfiles, CI, entrypoints, and dependency manifests before concluding.\nFor PRs, review the actual diff and tests, not only the PR body.\n\n5) Sandbox — only when runtime evidence is needed\n\nUse sandbox when the ask requires:\n\n\"does it build / install / boot?\"\n\n\"what happens when you run it?\"\n\n\"repro this bug\"\n\ndynamic behavior you cannot prove statically\n\nNever use the Hermes host shell as the untrusted workload runtime.\n\nSandbox selection\n\nPick 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.\n\nPolicy 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.\n\nDefault order, overridden by capability and verified controls:\n\nPriority\n\nBackend\n\nUse when\n\nRequired security posture\n\nLoad skill\n\n1\n\nPurpose-built managed cloud sandbox whose controls fit\n\nDefault for untrusted install/test\n\nVerify isolation, egress, credentials, tenancy, TTL, auditability, region, and cost\n\nprovider skill/docs\n\n1a\n\nModal Sandbox\n\nGeneral install/test, temporary dependencies, CPU/GPU work\n\nUse Sandbox API; restrict/block egress; generic Modal Functions are not assumed equivalent\n\nhermes-modal-backend-setup, modal-serverless-gpu\n\n1b\n\nVercel Sandbox\n\nFull Linux microVM, Node/JS control plane, snapshots/drives/network policy\n\nVerify account access; start deny-all; use scoped Vercel identity\n\nSpecialized hardware or full machine only when sandbox products do not fit\n\nDisposable account/project, no trusted network, scoped identity, cost cap, destroy\n\nprovider skills\n\n6\n\nSelf-hosted Firecracker microVM lab\n\nExplicit lab/research work, operator opt-in, or suitable cloud backends unavailable\n\nJailer; deny/restricted egress; no trusted LAN reach; disclose owned-infrastructure residual risk\n\nfirecracker-microvm-sandboxing (+ private lab skill if any)\n\n7\n\nHermes Docker backend / local Docker\n\nLast resort\n\nRootless/constrained; no Docker socket, host network, home mount, or privileges\n\nHermes config\n\n✗\n\nHermes host / terminal.backend: local\n\nStatic read/clone only\n\nNever execute untrusted inbound code\n\nn/a\n\nThis 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.\n\nWhy cloud before home Firecracker:\nEven 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.\n\nWhat “self-hosted Firecracker lab” means (for readers):\nA 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.\n\nFast chooser:\n\nDefault “run/install this for me” → purpose-built managed cloud sandbox with verified controls\n\nGeneral Python/Node test → Modal Sandbox, E2B, Vercel Sandbox, Daytona, or Novita based on access and controls\n\nNeed full Linux + preview URL / file APIs → Daytona or Vercel Sandbox\n\nNeed Firecracker-backed managed cloud → E2B or Vercel Sandbox; verify current product implementation\n\nOne-shot JS/Python isolate → Cloudflare Dynamic Workers with no bindings and outbound blocked\n\nFull Linux on Cloudflare → Cloudflare Sandbox SDK; remember it is container-backed\n\nE2B-style code interpreter API → E2B or Novita Agent Sandbox\n\nNeed full VM SSH, persistence, or branching → exe.dev or Vers VMs with explicit deletion\n\nNeed deploy-shaped container validation → Cloud Run job only, hardened identity/networking, then delete\n\nBrowser-only/UI review → Browserbase; pair it with a code sandbox if the reviewed app server is untrusted\n\nSuspicious model/binary/file profiling → Dyana inside a purpose-built cloud sandbox\n\nGPU-heavy review → Modal GPU, RunPod, Vast, or another verified cloud provider only if needed; report cost\n\nNo cloud backend with verified controls → static-only/refuse runtime, or operator-approved self-hosted fallback with residual-risk disclosure\n\nDo 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.\n\nMinimum sandbox procedure:\n\n```\n1. Create ephemeral sandbox (name it review-<short-slug>-<date>)\n2. Clone or upload ONLY the target artifact\n3. Inspect before install (tree, manifests, scripts)\n4. Install/build with pinned commands; capture logs\n5. Run the smallest smoke that answers the question\n6. Collect evidence (exit codes, key log lines, URLs, screenshots if UI)\n7. Tear down sandbox unless user asks to keep it\n8. Report cost/duration + residual artifacts\n```\n\nNetwork policy:\n\nPrefer blocked or allowlisted egress for R3/R4.\n\nIf package install needs egress, allow registry domains only when possible.\n\nTreat unexpected egress destinations as findings.\n\n6) Report — short by default\n\nUse templates/review-report.md. Default shape:\n\n```\n## Verdict\n<1-3 sentences: what it is + whether to use/ship/engage + main reason>\n\n## Triage\n| Field | Value |\n|---|---|\n| Type | ... |\n| Risk tier | R0–R4 |\n| Scope reviewed | ... |\n| Sandbox | none / provider + id + destroyed? |\n\n## Findings\n| Pri | Finding | Evidence | Fix / next step |\n|---|---|---|---|\n| P0 |  |  |  |\n| P1 |  |  |  |\n| P2 |  |  |  |\n\n## What’s good\n- ...\n\n## Recommended action\n- For the requester / for you:\n- Keep / fork / ignore / deep-dive next:\n\n## Verification performed\n- commands, URLs checked, sandbox smoke results\n```\n\nSeverity:\n\nP0 — unsafe to run/use, broken primary promise, active secret exposure, critical trust failure\n\nP1 — important security/quality gap, misleading docs, missing authz, high footgun\n\nPromote to R3 + sandbox only if user wants run/build proof\n\n\"Run this project and tell me\"\n\nR3/R4\n\nSandbox immediately after light static preflight\n\nReport runtime evidence + cleanup\n\nPR / patch review\n\npr-diff\n\nDiff-first; run tests in sandbox if environment is foreign or deps are heavy\n\nCompose with design/security skills as needed\n\nScreenshot / Slack \"can you review this?\"\n\nExtract the actual ask and artifact\n\nIf the artifact is external, fetch/review the source of truth\n\nReturn: summary of ask + recommended reply + risks\n\nAnti-patterns\n\nRunning curl | bash or unsigned installers on the host\n\nDeclaring a site \"secure\" from homepage copy alone\n\nSecurity theater (generic OWASP laundry lists with no evidence)\n\nMulti-page essays when a triage table answers the ask\n\nKeeping sandboxes alive \"just in case\" without saying so\n\nTrusting README architecture diagrams over code\n\nTreating container isolation as equal to microVM isolation for hostile code\n\nBackend 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\n\nDefaulting 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\n\nMaintaining the backend inventory\n\nDo not reconstruct the provider list from model memory or the last few tools used.\n\nInspect 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).\n\nReconcile it with live capability evidence: enabled MCP/tools, command availability, and credential names only (never values).\n\nClassify every candidate into one of four groups:\n\npurpose-built managed cloud sandbox;\n\ngeneric cloud VM/GPU/deploy platform;\n\nbrowser or cloud-agent workspace;\n\nself-hosted/research option.\n\nRecord status locally as connected, known but auth unverified, or research/watch; do not expose operator account status in the public package.\n\nVerify 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.\n\nWhen 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.\n\nThis 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.\n\nSupport files\n\nreferences/artifact-routing.md — deeper type → checks matrix", "url": "https://wpnews.pro/news/review-triage-eval-v0-0-1-by-wing-zero-ethan-troy-s-agent", "canonical_source": "https://gist.github.com/ethanolivertroy/0166d675e0b6788c0e03adcbb23ddbc8", "published_at": "2026-07-12 20:46:07+00:00", "updated_at": "2026-07-12 22:09:49.217601+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-safety"], "entities": ["Wing Zero", "Ethan Troy", "Modal Sandbox", "Daytona", "Hermes", "Novita Agent Sandbox", "Firecracker"], "alternates": {"html": "https://wpnews.pro/news/review-triage-eval-v0-0-1-by-wing-zero-ethan-troy-s-agent", "markdown": "https://wpnews.pro/news/review-triage-eval-v0-0-1-by-wing-zero-ethan-troy-s-agent.md", "text": "https://wpnews.pro/news/review-triage-eval-v0-0-1-by-wing-zero-ethan-troy-s-agent.txt", "jsonld": "https://wpnews.pro/news/review-triage-eval-v0-0-1-by-wing-zero-ethan-troy-s-agent.jsonld"}}