Skip to main content
Noah DolinkoAll projects

Project case study · Beta

Gatekeeper

A control point for routing API access instead of distributing provider credentials across every application or agent.

Explore Gatekeeper ↗
Audience
Developers and teams connecting applications to APIs
My role
Product concept, direction, and implementation
Stage
Beta
Gatekeeper beta operator console showing an instance, budget display, and key management tabs
The beta operator console.Open full-size screenshot
The access path Gatekeeper is designed around
  1. Application or agentSends a request through one control point.
  2. GatekeeperCentralizes credential and usage controls.
  3. Provider APIHandles the request behind that control point.

Why I started it

While building with APIs and AI agents, I found myself exposing keys to too many tools and rotating them more often than I wanted. I wanted one place to manage access, limit usage, and understand which application made a request.

The control point

Gatekeeper explores a proxy between applications and provider APIs. The product direction includes:

  • Keeping provider credentials out of individual client applications
  • Applying rate or spending limits to requests
  • Inspecting API activity across connected applications
  • Making credential rotation easier to manage

A central proxy can make controls more consistent. It also becomes a sensitive part of the request path, so the exact behavior of each control matters.

What I built

I owned the idea, product direction, and application build. TypeScript and Supabase form the core of the project, with supporting services listed alongside this case study.

Where it stands

Gatekeeper is in beta and close to launch. The operator console shows instances and sections for keys, credentials, usage, and settings. I am not claiming measured savings, proven reliability, or a verified security outcome before those behaviors have been tested and documented.