A governance layer for MCP servers.
SENTINEL sits between your AI agents and the tools they call, evaluates every request against your policies, and writes an audit trail of what happened.
Self-hosted, with Postgres as the only hard dependency. No API keys, no cloud account, no phoning home.
Why
Giving an agent a set of MCP tools hands it the ability to act. Most setups have no answer to three questions:
- Which tools is this agent allowed to call, and under which conditions?
- What did it actually do?
- Who approved the thing that touched production?
Capabilities
- policy engine
- ALLOW/DENY rules with condition trees. DENY always wins; no later ALLOW can override it.
- conditions
- SIMPLE flat arrays, or ADVANCED nested AND/OR expression trees, evaluated per call.
- mcp proxy
- Multi-transport: HTTP, STDIO, WebSocket, SSE.
- audit log
- Every tool call, policy change, auth event and admin action, with before/after snapshots.
- approvals
- Flag tools as sensitive; those calls block pending human approval.
- multi-tenancy
- Organizations, workspaces and members, scoped at the query layer.
- credentials
- AES-256-GCM encryption at rest for upstream server credentials.
- admin mcp server
- 40 tools, so an agent can administer SENTINEL itself.
- a2a proxy
- Agent-to-Agent protocol support alongside MCP.
- web console
- Full admin and user UI for servers, policies, approvals and audit.
Quick start
Requires Node 20+, pnpm and Postgres.
git clone https://github.com/gong8/sentinel-oss.git cd sentinel-oss cp .env.example .env # point DATABASE_URL at your Postgres pnpm setup # install, generate, push schema, seed pnpm dev
Then point an agent at the proxy:
{
"mcpServers": {
"sentinel": {
"url": "http://localhost:3001/mcp",
"headers": { "Authorization": "Bearer YOUR_ACCESS_TOKEN" }
}
}
}
Register upstream servers in the console, write policies against their tools, and every call now routes through the policy engine.
sentinel