What it is
Sentinel is a small service that runs locally and acts as a guarded proxy for an AI agent. It holds the sensitive API keys and tokens, and exposes only a narrow set of scoped actions to the agent. A built-in model router also decides — per request — whether a task should go to a local model, a mid-tier model, or a top-tier one.
Why it exists
Giving an AI agent direct access to live credentials is a security anti-pattern: if the agent is ever compromised, so is everything it can reach. Sentinel enforces a boundary — the agent only ever sees a local proxy with scoped permissions, so it can't leak keys or make calls it wasn't granted. As a bonus, centralizing model routing keeps costs down.
Who it's for
Security-conscious teams running local AI agents who need isolated credentials and cost-aware model routing.
What it does
- A narrow capability API — read-only by default, sensitive actions gated
- A model router that picks the cheapest viable model per task
- Encrypted credential storage with hashed access keys
- An admin UI for managing connectors and viewing router stats
- Guided OAuth setup with safe token refresh
- Bound to localhost only — not reachable over the network
How it works
What made it interesting to build
Sentinel began as a fork of a much larger AI gateway, and the real discipline was subtraction: stripping out multi-tenancy, chat history, and broad connectors to leave a deliberately minimal, auditable surface. The model router was designed to keep decision-making out of the agent entirely — tasks are classified by size and context automatically. Handling OAuth carefully mattered most: consent, refresh, and encrypted storage all had to work without ever exposing a plaintext token to the agent or the logs.