Bouncer

Inspiration

Agent platforms are being built and shipped faster than the security thinking that should go with them. The Agent Launchpad starter kit for this hackathon made that gap explicit: it ships a working control plane, a Playground, persistent workspaces, and Codex execution but no identity, no authorization, and no audit trail. Anyone who reached the API could touch anyone's Agent.

That gap is exactly where my background sits. I'm a Cybersecurity major, and the question I kept coming back to wasn't "does this platform work" it clearly did but "what happens the moment two people, or two Agents, are on it at once." Bouncer is my answer: the missing piece that turns a single-user proof of concept into something that could actually be trusted with more than one user.

What it does

Bouncer adds real, server-side identity and authorization to the Agent Launchpad:

Every Agent has an owner. Ownership is stamped at creation and enforced on every subsequent action — read, edit, chat, start/stop, delete.
Enforcement lives at the trust boundary, not the UI. The check happens inside the service layer, before any request reaches the data or execution layer — a hidden button in the frontend was never going to be a security control.
It doesn't only stop humans. The same boundary holds even when an Agent is manipulated — via a prompt injection — into attempting to reach another user's workspace or data. The Agent has no more authority than the human who owns it, no matter what it's told to do.
Every denial is attributed and logged: who (or what) attempted the action, what they targeted, who actually owns it, and when — so "not your Agent" isn't just enforced, it's provable.

How I built it

I started by reading the existing codebase closely before touching anything — types.ts, app.ts, and agent-service.ts — to find the real trust boundary rather than guessing at one. The architecture doc's extension seams table confirmed it: API routes and Agent ownership were the intended surface for this track.

From there, the build followed a deliberately narrow path:

Extended the Agent type with an ownerId field.
Added a lightweight identity layer that reads an X-User-Id header and attaches a requester identity to every request — a mock model, since a real auth provider was out of scope for one night, but the enforcement behind it is real.
Added a single shared assertOwner check inside AgentService, applied consistently across every Agent-scoped method, so there's one enforcement path to reason about and test — not eight slightly different ones.
Added a denial log that records every rejected attempt with full attribution, exposed through a small read-only endpoint so it's demoable and testable, not just theoretical.
Wired a minimal frontend user-switcher so the isolation between two users is visible, not just something you have to take on faith from the code.
Wrote automated tests proving the isolation holds — including the Agent-initiated case, not just the human one.

Challenges I ran into

Deciding what not to build. The brief offered four other rich middleware directions — trace/audit, threat modeling, layered architecture, multi-agent coordination. Solo, in one night, the real challenge wasn't technical difficulty, it was discipline: picking one coherent story and making it airtight rather than spreading four half-finished ones across the codebase.
Making the enforcement boundary actually matter. It's easy to add an if check that happens to work for the happy path. The harder part was making sure it held under an adversarial case I hadn't explicitly coded a test for first the Agent itself being tricked into reaching past its owner's scope. Proving the boundary holds there too, using the exact same enforcement path, was the moment the project stopped feeling like a login screen and started feeling like actual security engineering.

What I learned

The most useful realization was how little "security" sometimes has to mean, if it's real. Bouncer isn't a big system, it's one consistently applied check and an honest audit trail. But because it sits at the actual trust boundary instead of the UI, it holds up under exactly the kind of pressure, a manipulated Agent, not just a careless human that real Agent platforms will face. That's the lesson I'm taking past this hackathon: in agent security, the size of the fix matters less than where you put it.