Nobody runs a single security tool on their infrastructure.
You have a firewall. An antivirus. A password manager. Disk encryption. Maybe a WAF, maybe an IDS, maybe both. Each one covers a specific surface and is clear about what it doesn't cover. Nobody expects their firewall to also manage passwords. Nobody expects their antivirus to encrypt their disk.
This isn't a limitation. It's how security has worked for decades. Scope clarity is a feature.
With AI agents, the instinct is different. The surface is new, the risks feel unfamiliar, and the temptation is to look for a single tool that covers all of it at once.
What "total" agent security requires
To control everything an AI agent does — every tool call, every HTTP request, every file read, every shell command — you need deep access to the machine. Runtime hooks injected into the agent's process. An HTTP proxy that intercepts encrypted traffic with custom certificates. System-level permissions to monitor file operations.
These are legitimate approaches, and there are teams building exactly this. But it's worth understanding what you're opting into. You're installing something that hooks into processes, inspects encrypted traffic, and sits between your applications and the operating system. On every developer's machine. The tool gains the same level of access you're trying to restrict in the agent.
That's a tradeoff, not a flaw. More surface coverage requires more invasiveness. Some organisations need that coverage and are willing to manage the complexity. But it's not the only way to think about agent security.
We wanted something different. Not because deep integration is wrong — but because we wanted to build something where the user can see exactly what it does, verify that it doesn't touch anything else, and stay in control of their own machine. That meant choosing a narrower scope and covering it completely.
One point, covered completely
MCP is a different kind of opportunity. The protocol has an architectural property that matters here: when an agent uses tools through MCP, every call goes through a server. If you put a proxy between the agent and those servers, every tool call must pass through it. Not most of them. All of them.
The agent doesn't have an alternative path. The proxy is the only address it knows. If the proxy says deny, the action doesn't happen. This is worth dwelling on, because the type of guarantee matters.
There are roughly three levels of enforcement you can apply to an AI agent. Prompt-based safety — "don't delete anything without my approval" — works as long as the agent remembers the instruction, and we've already seen what happens when context compaction silently drops it. Runtime hooks work if the agent cooperates — standard libraries, respected proxy settings — but a native extension or a direct syscall bypasses them. An MCP proxy is different in kind: the agent connects to localhost:8080/mcp, the upstream servers are configured inside the proxy, and the agent can't bypass it because it doesn't know where else to go. Not enforcement by cooperation or memory. Architecture. The difference between saying "don't open this door" and removing the door from the building.
You get that 100% interception without touching the operating system, without injecting hooks into processes, without inspecting encrypted traffic. A proxy on localhost:8080, one install command, sub-millisecond overhead, everything managed from a browser. Every tool call hits an eleven-step interceptor chain and denied actions get logged with the same detail as allowed ones. You see what your agents are attempting, not just what they succeed at. (We wrote a longer piece on the interceptor chain, CEL policies, and audit trail if you want the technical details.)
This bet on MCP specifically isn't a bet on a niche protocol. MCP was donated to the Linux Foundation in December 2025 under the Agentic AI Foundation, co-founded by Anthropic, OpenAI and Block, with every major cloud provider as a supporter. It has native support in ChatGPT, Claude, Gemini, Copilot, VS Code, Cursor and Codex. The New Stack compared its community-driven momentum to Docker in its early days. As more tools migrate to MCP, the surface an MCP proxy covers grows automatically — without changing a line of configuration.
What about the rest? HTTP calls the agent makes directly. Native file operations that don't go through MCP. Shell commands routed outside the protocol. For those, you use containers, VM sandboxes, OS-level permissions — the tools designed for that job.
This is the same pattern as traditional security. Your firewall handles network traffic. Your disk encryption handles data at rest. Neither pretends to do the other's job.
Do one thing. Be clear about the rest.
There's a second argument here, beyond architecture. It's about trust.
When you install a tool that takes deep control of your machine, you're making a significant trust decision. You're betting that the vendor — or the open-source maintainer — got everything right. Every process hook, every certificate, every interaction with every agent on every operating system. The surface area for things to go wrong is large.
A proxy that does one thing is easier to reason about. You can read the code. You can understand exactly what it does and what it doesn't do. It intercepts MCP tool calls. It evaluates them against your CEL policies — the same expression language behind Kubernetes admission control and Google Cloud IAM. It logs everything with full context: identity, arguments, decision, matched rule, timestamp. That's it. It doesn't touch your processes, your filesystem, or your network stack.
For an open-source project, this transparency isn't optional. If someone is going to install your tool on their development machine — where their SSH keys live, where their cloud credentials are stored, where their private repos are cloned — they should be able to verify exactly what it does. A smaller, well-defined scope makes that possible.
Non-invasive doesn't mean weak. It means auditable.
What we cut, and why
Until last week, SentinelGate had runtime hooks — code that attached to agent processes and intercepted calls from inside. They worked. But making them work well — reliably, across agents, across updates, across operating systems — required exactly the kind of invasiveness I described above. Deep integration with each agent's internals. System-level access that varied per platform. A different implementation for every agent runtime.
We removed them. Not because they were broken, but because doing that properly means building a fundamentally different kind of tool. An endpoint agent. That's not what SentinelGate is.
We kept the MCP proxy. It covers every MCP tool call, with zero invasiveness, and we can look any user in the face and say: if it goes through MCP, we intercept it. No caveats, no "in most cases," no "as long as the agent cooperates."
For everything outside MCP, there are tools built specifically for that job. The user combines what they need — as they've always done in security.
Our threat model spells this out. SentinelGate protects against agent mistakes, prompt injection, and overreach — cases where the agent isn't actively trying to evade. For adversarial isolation, combine with sandboxes. We'd rather be precise about our scope than vague about a larger one.
The bigger picture
That's not how security works. It never has been. The answer has always been: clear tools with defined scope, composed by the operator. A firewall that does its job. Encryption that does its job. An MCP proxy that does its job.
If you're evaluating security for your agents, the question isn't "does this cover everything?" It's "what exactly does this cover, and is it honest about what it doesn't?"
We wrote a longer piece on the technical architecture — the interceptor chain, CEL policies, audit trail, content scanning. If you want the details, start there.
Sentinel-Gate
/
Sentinelgate
Access control for AI agents. MCP proxy with RBAC, CEL policies, and full audit trail.
SentinelGate
Access control for AI agents.
Every MCP tool call intercepted, evaluated, and logged — before it executes.
RBAC · CEL policies · Full audit trail
Get Started · Website · Docs
The problem
AI agents have unrestricted access to your machine — every tool call, shell command, file read, and HTTP request runs with no policy, no authentication, and no audit trail. One prompt injection or one hallucination is all it takes.
How SentinelGate works
SentinelGate sits between the AI agent and your system. Every action is intercepted, evaluated against your policies, and logged — before it reaches anything. Denied actions are blocked at the proxy.
No code changes. No agent modifications. Single binary, zero dependencies, sub-millisecond overhead.
Quick start
Install (macOS / Linux):
curl -sSfL https://raw.githubusercontent.com/Sentinel-Gate/Sentinelgate/main/install.sh | sh
Install (Windows PowerShell):
irm https://raw.githubusercontent.com/Sentinel-Gate/Sentinelgate/main/install.ps1 | iex
Manual
Top comments (0)