Volc Agent Launchpad — Agent Pixel World

Inspiration

The AI-agent starter kit we built on top of ships with no middleware at all: no identity, no authorization, no audit trail. Anyone who can reach the API can read, edit, or run any agent's files. That's fine for a single-user toy, but it falls apart the moment more than one person's data lives on the same platform. We wanted to prove an agent platform can actually enforce "this agent may only touch what its owner explicitly, revocably permitted," in the backend, and make that provable on stage instead of buried in a test file nobody reads.

What it does

Every agent belongs to one human owner. To touch a file, an agent needs a scoped, time-limited keycard (read:res://owner/glob) issued by its owner, and that keycard can be revoked at any moment. Every request, whether it comes from a human or an agent, gets decided by a single Policy Decision Point before it ever reaches anything real, and every decision lands in an audit trail scoped so nobody can see another user's entries. On top of that sits the World: a pixel-art office where agents roam and walk toward whichever room their current task actually names. Every door, keycard, and access request drawn on screen is the real permit/deny decision the backend just made. The animation only relays it. It never decides anything itself.

How we built it

It's a Node/TypeScript monorepo: a Fastify control plane and a React + PixiJS frontend. One decide() function is the entire authorization surface, enforced on every protected route by a policy layer nothing can bypass. Capabilities and resources are real objects, not placeholders: actual scoped, expiring records and actual files on disk under res://owner/name. Agents run through Codex CLI against Volcengine's Ark API, with secret redaction stripping API-key-shaped strings from run output before anything is stored or shown. We backed all of it with two kinds of proof: an automated test suite that asserts the decision-maker itself (demonstration.test.ts on both ends), and standalone shell scripts (demo-test-cases/) that drive the live server over real HTTP and print, case by case, what the platform allows and what it refuses.

Challenges we ran into

The sharpest one was self-inflicted, and honestly the most useful thing that happened. For a stretch of the project, the World's decision.ts was deciding permit/deny against an in-memory Map in the browser, while a complete, correct PDP, capability store, and audit log sat behind API endpoints that nothing ever called. The office looked exactly like a real authorization demo and underneath it was pure decoration, which broke the one rule that mattered most to us. Catching it meant actually reading the request path end to end instead of trusting that a convincing UI implied a convincing backend. Fixing it meant rewiring decision.ts to call the real API and relay its answer verbatim, then adding tests that check whether a backend call actually happened rather than just checking whether the right color flashed on screen. There was a smaller, related problem too: real backend decisions can resolve faster than a UI poll cycle, so a request that was genuinely enforced could finish before the animation ever caught it. We solved that by separating how long the decision took from how long its visual result stays on screen, without ever faking or slowing down the decision itself.

Accomplishments that we're proud of

190 server tests and 80 web tests, all passing, including the negative paths (path traversal, revoked and expired capabilities, cross-owner access, malformed input) that most demos skip entirely. A cross-owner denial that's actually verified end to end, not just a 403 status code but the response body checked to confirm the other user's secret never appeared in it. The World's Security Log and the terminal test scripts read the exact same live audit trail, so you can run the scripts and watch the identical events land in the UI in real time, which is the strongest evidence we have that neither one is theater. And limitations documented plainly instead of hidden, with zero real secrets anywhere in source, history, or demo output.

What we learned

"The UI looks secure" and "the system is secure" are different claims, and the gap between them is exactly where our decorative-mock bug lived. The fix wasn't some clever technique. It was reading the real request path instead of trusting the visual result, and writing a test that asks who made the decision, not just what the decision was. That's a habit worth keeping past this hackathon.

What's next for Volc Agent Launchpad

We'd want to persist capabilities past a server restart, since they're in-memory right now. Opaque capability ids should become signed, unforgeable tokens. Revocation should be able to interrupt a run already in flight instead of only blocking the next request. The two deny-reason vocabularies, one for agent ownership and one for resource capability, should get merged into one. And the two hard-coded demo accounts should give way to real user registration.