You connected an MCP server to your AI agent. Now it can read files, write files, list directories — everything. But what happens when it reads credentials.env? Or writes to a path it shouldn't touch?
Right now, nothing stops it. Every call goes through. No logs, no rules, no control.
SentinelGate is an open-source MCP proxy that intercepts every tool call before it executes. Deterministic rules, not AI judgment.
Here's what that looks like — 54 seconds, before and after:
What just happened
Before — no rules. The agent calls read_file on a credentials file. Allowed. Calls write_file to create a new file. Allowed. The dashboard shows every request going through with zero denials. Security score: 30/100.
After — one click. The "File Server — Read Only" template creates two rules: allow read operations, deny everything else. Same agent, same calls. read_file still works. write_file gets denied instantly — "Access denied by policy." Security score jumps to 80/100.
The activity log records everything: who called what, when, and whether it was allowed or denied. Every decision is traceable.
Try it yourself
Install:
curl -sSfL https://raw.githubusercontent.com/Sentinel-Gate/Sentinelgate/main/install.sh | sh
Start:
sentinel-gate start
Open http://localhost:8080/admin. Add your MCP server, create an identity with an API key, and point your agent to http://localhost:8080/mcp.
Go to Tools & Rules → Use Template → File Server — Read Only → Apply Template.
Done. Your agent can read, but it can't write, delete, or modify anything.
What's next
This was the simplest rule — a one-click template. SentinelGate also does:
-
CEL-powered policies — fine-grained rules like "block shell access for non-admins" or "deny any action containing
secretin the arguments" - Content scanning — detect and block PII, API keys, and credentials in tool calls
- Session-aware rules — detect patterns like read-then-exfiltrate across multiple calls
- Kill switch — one command stops all agents instantly
Full source and docs: github.com/Sentinel-Gate/Sentinelgate
Top comments (2)
This is the right direction.
The useful shift is moving the boundary out of the model's judgment and into deterministic pre-execution policy. Once write denial happens before the tool runs, “the agent understood the prompt wrong” stops being enough to create a real file mutation.
The next thing I would want from systems like this is explicit authority classes:
That makes a “read-only file server” more than a template. It becomes a legible trust class the runtime can expose, govern, and audit.
And the denied write matters twice: it is a block, but it is also a signal that the task or agent state is trying to escalate beyond the declared boundary.
Thanks. The separation is already there — tool patterns (read_, write_, delete_*) define operation classes at the policy level, and CEL covers execute and egress (dest_domain_matches(), role-based shell access). The template in the demo creates real rules that the runtime enforces and audits — not just a preset.
On the deny-as-signal point — every denial hits the audit trail with identity, arguments, and timestamp. Session-aware CEL rules can detect cross-call escalation, like an agent that reads credentials and then tries to send data out.