Boundary

Boundary makes agent authorization visible, reviewable, and safe before the agent acts.

Comment

Inspiration

Most agent demos stop at “the OAuth flow worked” and then jump straight to automation. That felt incomplete to us.

We were inspired by a simpler question: once an agent is connected, who still owns authority? We wanted to build something that makes that boundary visible. Instead of treating identity, scopes, and approval as backend plumbing, we turned them into the product itself.

Boundary came from that idea. We wanted a project that shows agent systems should not inherit quiet blanket access just because a connection succeeded. They should operate inside clear limits, pause for human approval when risk increases, and leave evidence behind.

What it does

Boundary is a permission plane for agent tool use.

For the hackathon demo, Boundary is shown through a focused workflow called Release Copilot. It connects GitHub and Google, inspects repository context, prepares release coordination work, drafts communication, and proposes the next steps for a launch.

The difference is that Boundary does not let the agent act invisibly. It keeps permissions, policies, approvals, and receipts in one surface:

  • connected accounts show what the agent can access
  • a policy matrix shows which actions run automatically and which require approval
  • high-impact actions stop behind step-up control instead of executing silently
  • receipts record approvals, denials, revocations, and execution outcomes

The result is an agent workflow that is useful without becoming opaque.

How we built it

We built Boundary as a Next.js 15 + React 19 + TypeScript application with a judge-facing landing layer and a live operator workspace.

Auth0 is the core trust boundary. We used the Auth0 Next.js SDK for authentication and designed the product around Auth0 audiences, delegated access, and Token Vault-style connected account flows. We also modeled step-up approval as a first-class part of the experience rather than an afterthought.

For persistence, we used libSQL/Turso so policies, approvals, revocations, and receipts survive beyond a single session and can be shown reliably in a hosted demo.

We kept the demo focused on one strong story instead of building a generic assistant. That made it possible to design the entire flow around one question judges can understand immediately: what is the agent allowed to do, under which scopes, with whose approval, and what proof remains afterward?

Challenges we ran into

The hardest challenge was not building another workflow UI. It was making authorization legible.

A lot of identity and permissions logic normally lives in dashboards, logs, or configuration files. We had to translate that into a product surface that a judge could understand in seconds.

Another challenge was balancing realism with safety. We wanted a live, convincing workflow across GitHub and Google, but we also needed a judge-safe sandbox path so risky actions could be demonstrated responsibly.

We also spent a lot of time tightening the narrative. In a hackathon setting, a project does not just need to work. It needs to explain itself quickly and clearly.

Accomplishments that we're proud of

We are proud that Boundary feels like a product, not just a demo.

We turned permissions, approval, and revocation into visible parts of the user experience. We built a guided workflow instead of a vague chatbot. We created an approval queue and a receipt trail that make delegated actions explainable. And we packaged the whole thing in a way that is understandable to judges in one walkthrough.

Most of all, we are proud that the central idea stayed intact from end to end: agent speed should not come at the cost of operator control.

What we learned

We learned that authentication is only the beginning. The more important product question is what happens after an agent gets access.

We learned that approval is not just a security feature; it is a UX problem. If the boundary is confusing, users will either distrust the system or bypass it.

We also learned that the strongest hackathon projects are narrow and opinionated. Choosing one flagship workflow gave us better product clarity, a better demo, and a better chance of being memorable.

What's next for Boundary

Next, we want to deepen the live connected-account path so the full GitHub and Google workflow can run through production-grade delegated access and step-up approval.

After that, we want to expand Boundary into a broader authorization layer for agent tools:

  • more providers and action classes
  • richer policy templates for teams
  • stronger step-up and revocation flows
  • clearer evidence and audit exports
  • support for more high-trust workflows beyond releases

The long-term goal is simple: make agent authorization visible, reviewable, and trustworthy by default.

Bonus Blog Post

Boundary came out of a frustration with how agent demos usually present trust. Most of them prove that OAuth worked, then immediately shift the story to productivity. That leaves out the harder question: what happens after an agent is connected? We wanted to build around that missing layer.

The biggest technical and product challenge was making delegated access visible instead of invisible. Token Vault is powerful, but if it only exists behind the scenes, the user still experiences authorization as a black box. So we treated it as a product surface. We designed Boundary so the operator can see connected accounts, understand action classes, know which scopes matter, and tell the difference between low-risk work and high-impact actions.

That led directly to our strongest implementation choice: Boundary is not a generic assistant. It is a permission plane. The demo is deliberately narrow, focused on a Release Copilot across GitHub and Google, because that let us show a complete story. The agent can prepare useful work, but merge and send actions stop behind step-up control. Approvals, denials, revocations, and outcomes leave receipts.

One of the most useful lessons from building with Token Vault was that least privilege is not just a backend principle. It becomes much more trustworthy when it is legible in the UI. Our biggest takeaway is that the next generation of agent products should not just authenticate users. They should make delegated authority inspectable, reviewable, and reversible by default.

Built With

Share this project:

Updates