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
Build activity
Quiet latelyNo changes in the last 90 days
Updated automatically from the project's build history. Last refreshed Oct 12, 2026.
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.