GateKeeper

A 22-engine deterministic governance runtime for AI agent authorization. Governance decides before identity -- high-stakes actions are blocked before a credential is ever requested.

Comment

Inspiration

I built GateKeeper around a simple idea: for AI agents, governance should resolve before identity.

Most agent stacks ask the identity question first: does the agent have a valid token, does the user have the right scope, can the API call be made? That is necessary, but it still skips the more important question: should the action happen at all?

GateKeeper flips that order. It classifies the action first, resolves the enforcement tier first, and only then decides whether identity, credentials, approval, or authorization should be consulted.

This hackathon was the right place to prove that idea on a live deployed app.

What GateKeeper Does

GateKeeper is a deterministic governance runtime for AI agent authorization.

Every attempted action is resolved into one of three governance tiers before credentials are requested:

  • HARD_STOP — the action is blocked before identity is consulted
  • SUPERVISED — approval is captured before execution continues
  • FULL_AUTO — the action is allowed into the credential path automatically

On top of those three execution tiers, I added a fourth proof lane using OpenFGA: one real server-side fine-grained authorization check protecting an Audit Feed export surface.

The live dashboard exposes all of this through five proof surfaces:

  • Governance Matrix
  • Action Surface
  • Unified Receipt Ledger
  • Decision Trace
  • Enforcement Feed

The result is not just "allowed" or "denied." Every lane produces a proof artifact showing what happened, why it happened, whether approval was required, whether credentials were requested or suppressed, and whether a fine-grained authorization check ran.

How I Built It

GateKeeper is a two-layer system.

Layer 1 is the governance foundation: a deterministic 22-engine JavaScript runtime that classifies actions, resolves enforcement tiers, and preserves evidence.

Layer 2 is the web application I built for this hackathon:

  • Next.js
  • TypeScript
  • React
  • Tailwind CSS
  • Auth0
  • @auth0/nextjs-auth0
  • @auth0/ai-vercel
  • @openfga/sdk

The deployed app uses Auth0 Universal Login to protect the dashboard and then exposes four live proof lanes:

  • Red — pricing rule change → blocked before identity
  • Yellow — GitHub issue creation → approval-first supervised flow
  • Green — Google Calendar read → Token Vault path exercised
  • Blue — Audit Feed export → real server-side OpenFGA check

The system is live on Vercel, and the demo video walks through all four lanes on the deployed app.

Challenges

The hardest part of this build was not the happy path. It was making the failure path truthful.

The green lane uses the real Token Vault path for Google Calendar. In this environment, the external credential was not available, so the provider exchange did not complete. Instead of crashing or pretending the call succeeded, GateKeeper returned a deterministic HOLD with structured proof showing exactly what was missing and why the action could not continue.

That turned into one of the most important moments in the build.

The blue lane had a different challenge: keeping scope tight. Rather than trying to build a broad authorization platform in hackathon time, I landed one thin but real server-side OpenFGA-protected export lane and made the access decision visible in the same receipt, trace, and feed surfaces as the other lanes.

A third challenge was consistency. It is easy to make a dashboard look convincing while the backend tells a different story. I wanted the receipt ledger, decision trace, and enforcement feed to agree on the same facts for every lane.

What I Learned

I learned three things while building GateKeeper:

  1. Governance should resolve before identity. If an action is prohibited, the system should not waste a token request discovering that.

  2. Proof on failure matters as much as proof on success. Real systems hit missing credentials, revoked access, partial setup, provider gaps, and stale authorization constantly.

  3. Thin real proofs beat broad fake systems. A real hard-stop, a real approval-first gate, a real Token Vault path, and one real server-side OpenFGA check are more valuable than a larger but less truthful demo.

GateKeeper is my attempt to show that AI authorization gets much stronger when governance sits in front of identity instead of behind it.

Bonus Blog Post:Proof on failure is part of the product

The most important moment in GateKeeper was not a success state. It was a failure state.

The red lane worked exactly the way I wanted: the system classified a pricing rule change into a protected domain, resolved it to HARD_STOP, and blocked it before any credential was requested. That proved the thesis cleanly: governance decides first, identity follows second.

The yellow lane also proved something important: supervised execution is not just “prompt the user and hope.” The proof trail captured approval before execution and kept credentials suppressed until the approved step.

The blue lane then added a different kind of proof: one thin but real server-side OpenFGA-protected Audit Feed export. Instead of narrating fine-grained authorization, the app ran a real check and surfaced fga_checked: true in the same receipt, trace, and feed surfaces as the other lanes.

But the moment that changed how I think about production agent authorization was the green lane.

The green lane is the FULL_AUTO path. In theory, it is the smoothest lane in the whole app: governance clears the action, the system requests credentials through the Token Vault path, and the provider call executes. That is the demo path most systems want to show.

What actually happened was more useful.

The external credential was not fully available in the environment, so the provider exchange did not succeed. Instead of crashing, timing out, or pretending the step worked, GateKeeper returned a deterministic HOLD. The proof artifact showed the domain, tier, outcome, credential state, approval state, and the exact reason the call could not complete.

That is the lesson I am taking away from this project:

A good agent authorization system should not only prove what it allowed. It should also prove, with equal clarity, what it blocked, what it paused, and what it could not complete.

Real systems do not live only in healthy happy-path states. They live in missing credentials, revoked access, stale config, partial setup, missing tuples, and provider gaps. If the system only looks trustworthy when everything is configured perfectly, it is not actually production-ready.

For me, that is where governance earns its keep.

GateKeeper started as a governance-first authorization experiment. By the end of the build, it became a stronger argument: proof on failure is part of the product, not just proof on success.

Built With

Share this project:

Updates