SentnelOpsObservation — the MCP gateway
A transparent proxy between your agents and your MCP servers. It identifies, logs, and policy-checks every tool call — and in observe mode it never blocks anything.
Layers 1 and 2 tell you who your agents are and what they are allowed to do. The gateway is the layer that sees what they actually do. Adoption is one line of client configuration — the MCP server URL — pointed at /proxy/<server>/… instead of the upstream. From that moment every tool call arrives with an agent identity attached, gets written to a durable call log, streams to a live feed, and is evaluated against your policy. Bodies and responses pass through byte-identical; the agent and the MCP server behave exactly as before.
The shipped default is observe mode: the policy verdict is recorded, never acted on. A call your rules would deny still goes through — it is simply logged with would_block=true. That flag is a free dress rehearsal for enforcement: you validate every rule against real traffic at zero risk before layer 4 ever turns a deny into a 403.
At a glance
| What it governs | Every MCP tool call routed through the proxy — identified, logged, policy-checked, forwarded unchanged. |
| Key objects | An mcp_server registration (name → upstream URL), a call-log row per proxied call, the would_block flag, and the ghost diff (registered agents vs. observed callers). |
| Where it lives | /proxy/* (the data path), the /calls live feed page, and the /ghosts page in the dashboard. |
| Depends on | Layer 1 agent tokens authenticate every proxied call; layer 2 policy supplies the verdict that observe mode records. |
| Consumed by | Layer 4 enforcement runs on this exact pipeline — same proxy, same verdict; only what the verdict does changes. |
When you need this layer
Turn the gateway on when the question shifts from "which agents exist?" to "what are they doing right now?" — before an audit that asks for tool-call evidence, before you trust a new agent in a sensitive environment, and always before enabling enforcement: the would_block rows it accumulates are what make flipping to enforce a decision instead of a gamble. It is also how you find ghost agents — callers hitting your MCP servers that nobody registered.
Honest limits
| Limit | What it means for you |
|---|---|
| It sits in the data path | If the gateway is unreachable, proxied calls fail until it is back. Read Trust & reliability before routing production traffic through it. |
| Tool-call parameters are visible | The gateway logs params, not just metadata. If that matters for your data, deploy it self-hosted in your own VPC so nothing crosses your boundary. |
| Only routed traffic is governed | An agent pointed directly at an upstream bypasses the gateway entirely. Ghost detection tells you this is happening — it cannot stop it. |
| The Authorization header is forwarded upstream | The agent's bearer token travels to the upstream today, so upstreams needing their own bearer auth conflict with the proxy. Per-upstream header injection is on the roadmap. |
The same candor for every layer lives on The five layers.