Guardrail

Inspiration

Agent Launchpad's Starter Kit gives any Agent full API access with no concept of ownership. Any client that can reach the API can create, invoke, or delete any Agent, and there's no record of who performed which action. This becomes a real problem the moment more than one person shares the platform—there's no way to safely delegate access to a teammate, and no way to take it back if something goes wrong. We wanted to build the layer that makes multi-user access to Agents actually safe.

What it does

Guardrail adds ownership, scoped delegation, and enforcement to Agent Launchpad. Each Agent has an owner, who can grant other users limited, time-bound access to specific actions instead of full control. Every request is checked against these grants at the backend before it reaches the Agent Runtime—not filtered in the UI. Every decision, whether granted, allowed, denied, or revoked, is written to an audit log with the acting user, target Agent, action, and outcome. Revoking a grant takes effect immediately: the next request from that user is denied, even if an identical request succeeded moments earlier.

How we built it

We started from the Starter Kit's Fastify control plane and added a policy service that checks a Grant model—owner, delegate, scopes, expiry—before any request is allowed to proceed. Rather than enforcing access in a single place, we added two checkpoints: one at the API request boundary, and a second at the AgentRunner layer itself, so a request couldn't reach Codex execution without passing both. Every decision made at either checkpoint is written to a new audit store with a consistent schema—actor, target Agent, action, decision, timestamp—exposed through a read API and a filterable table in the existing React UI. On the frontend, we added a lightweight user switcher and a grant/revoke panel so the full flow could be demonstrated without building a real authentication system.

Challenges we ran into

Coordinating the Grant data model between the person building enforcement and the person building the model itself was the biggest early bottleneck—until that contract was locked, no downstream work could start. We also underestimated how many places in the existing codebase implicitly assumed a single user, so adding an owner concept touched more of the control plane than expected. Making revocation take effect immediately, rather than only at the start of a new session, took an extra pass once we realized our first implementation only checked scope at request creation, not on every subsequent action. Finally, keeping the baseline lifecycle (create, start, stop, Playground) fully working while inserting two new enforcement checkpoints meant a lot of careful regression testing under a tight deadline.

Accomplishments that we're proud of

We're proud that our enforcement is provably real: a denied action is rejected by a direct API call, not just hidden behind a disabled button, which was a deliberate choice to avoid the most common shortcut teams take under time pressure. We're also proud of getting live revocation working end-to-end—an authorized user is blocked on their very next request after their access is pulled, with no restart or session reset required. Given our compressed timeline, shipping automated tests covering both the allow and deny paths, rather than only demoing the happy path, was a meaningful bar to clear.

What we learned

We learned that authorization is as much a data modeling problem as a code problem—getting the Grant schema right early saved far more time than it cost, while ambiguity there would have cascaded into every other component. We also learned the value of enforcing at more than one boundary: our two-checkpoint design caught a case where a request could otherwise have slipped past the API layer and reached the Runtime directly. On the team side, working under a hard deadline reinforced that a small, working, end-to-end scenario beats a broader set of half-finished features.

What's next for Guardrail

Beyond the hackathon scope, natural extensions include automatic expiry for time-bound grants, human approval workflows for high-risk actions before they execute, and generalizing the scope model beyond a single protected resource type. Replacing the mock user table with real authentication would let Guardrail move from a demo to a usable multi-user deployment of Agent Launchpad.