-
-
gallery-01-product
-
gallery-02-architecture
-
gallery-03-evidence
-
volc-agent-launchpad-judge-handout
Inspiration
Autonomous coding agents can reason, read files, write code, and execute shell commands. That power creates a control problem that prompt filtering alone cannot solve. A request such as “clean up the build output” is harmless, yet an agent may choose a recursive delete. A clean prompt may also lead the agent to read a poisoned workspace file containing an indirect prompt injection. In both cases, the dangerous intent appears only after the agent has started running.
We built Volc Agent Launchpad to put an enforceable policy boundary between an operator's request and the agent's real actions, while leaving evidence that a reviewer can audit later.
What it does
Volc Agent Launchpad is a lightweight three-layer policy gate integrated into the Agent control plane and Runtime path.
Layer 1 — deterministic prompt rules. Obvious requests for credential exfiltration, broad destructive filesystem operations, workspace escape, or network exfiltration are stopped before Runtime dispatch. These checks spend zero model tokens and remain in the single-digit-microsecond range in the included benchmark.
Layer 2 — semantic intent classification. If patterns allow a prompt, a small ModelArk call judges intent instead of vocabulary. Against nine paraphrases of three attacks, deterministic patterns blocked 1/9; the combined prompt gate blocked 9/9, with 0/3 ordinary coding prompts falsely denied.
Layer 3 — runtime action and content inspection. A per-run inspector reads the Codex JSON event stream, evaluates each command, and scans file-read output for indirect prompt injection. A denied action is recorded and the Runtime is terminated after the event is reported. This is detect-and-terminate rather than pre-execution authorization. Across seven paraphrased injected instructions, patterns alone blocked 1/7; semantic escalation blocked 7/7, while 0/4 ordinary documents were blocked.
Every run exposes the decision, matched evidence, agent actions, token use, and
correlated trace events. Trace events form a forward SHA-256 hash chain, so
editing an earlier event breaks each later link. Correct policy stops use the
first-class status blocked; genuine provider or Runtime failures use
failed.
The console includes eight one-click scenarios: two green positive controls (Safe Review and Safe Build) and six threat probes. This makes it possible to prove both containment and normal operation in a single short demo.
How we built it
The starter platform's lifecycle remains intact. AgentService calls a
framework-independent PolicyGate before dispatch and receives a RunInspector
callback for Runtime events. Any agent framework that emits command and output
events can reuse the same two-step interface.
The backend uses Node.js 22, strict TypeScript, Fastify, and Zod. The interface
uses React 19 and Vite. Codex CLI runs in a disposable Docker, Colima, or Podman
Runtime and talks to BytePlus ModelArk through the Responses API. The gate adds
no HTTP dependency: semantic calls use Node's native fetch.
We deliberately designed graceful degradation. If semantic classification
times out, deterministic layers remain armed, the run may continue, and the
audit record is stamped semanticStatus: unavailable. The console makes this
degraded posture visible instead of silently hiding it.
Challenges we ran into
The most important blind spot was interpreter-based evasion. Early rules
understood shell vocabulary such as printenv and rm -rf, but not equivalent
logic inside node -e, python -c, or ruby -e. Five of nine probes initially
passed. We fixed the class of bypass by recognizing inline interpreters and then
judging the script in that runtime's syntax. All twelve adversarial probes are
now denied, with no regressions across ten legitimate inline scripts.
The second challenge was false positives. A policy gate that blocks ordinary work will be disabled. The project therefore maintains a benign corpus of 30 developer prompts, 20 file contents, and 15 shell commands, including examples that legitimately mention secrets and cleanup. The current corpus has zero false positives.
The third challenge was audit honesty. A self-computed digest over one record does not prove immutability because an editor can recompute it. We replaced that claim with a forward hash chain and a verifier that distinguishes verified, broken, and unverifiable legacy traces.
Accomplishments that we're proud of
- 139 collected tests across 15 suites: 138 pass and 1 is explicitly skipped.
- Zero false positives across the 65-item benign corpus.
- A real three-boundary path: prompt, runtime command, and runtime-read content.
- A distinct
blockedoutcome that cannot be confused with infrastructure failure. - One-command local startup and a public, reproducible repository.
- OWASP LLM Top 10 mappings for LLM01, LLM02, LLM05, LLM06, and LLM10, without claiming categories the middleware cannot observe.
What we learned
Adversarial testing is not a final phase; it tells us which rules deserve to exist. We also learned that evidence must be designed for human comprehension. Streaming each inspected action to the store turned the same data from a report read after the run into a moment an evaluator can watch.
Finally, a security demo must include an allow path. Two explicit positive controls now bracket the threat probes so that “safe work still completes” is a visible product property, not an assumption.
What's next
The next integration is pre-approval rather than detect-and-terminate: connect the gate to the Codex approval hook so a denied command is never dispatched. After that, add per-agent identities and time-bound scopes, plus proxy- or eBPF-level outbound enforcement that compiled binaries cannot bypass.
Log in or sign up for Devpost to join the conversation.