SentnelOpsTrust & reliability — the hard questions
Straight answers to the questions a security lead should ask before putting anything in the path of production traffic — including 'what happens when your product fails?' No marketing; where a failure mode is ugly, we say so.
If your MCP gateway goes down, what happens to my company?
Agent tool calls routed through the proxy fail until it is back. The gateway sits in the data path, and an unreachable gateway is a hard outage for proxied traffic — fail-closed by architecture, not by configuration. There is no cached "pass-through" mode that lets calls skip a dead gateway.
What does not break:
| Unaffected during a gateway outage | Why |
|---|---|
| Your MCP servers themselves | They are separate processes; the gateway proxies to them, it doesn't host them. |
| Agents not routed through the proxy | Anything pointed directly at an upstream never touches the gateway. |
| Your audit history | It lives in the database, append-only. An application outage loses no history. |
Mitigations that exist today — not roadmap:
| Mitigation | What it buys you |
|---|---|
| Multiple replicas behind a load balancer | A single replica dying is invisible. Approval decisions and token revocation are replica-safe, so replicas are interchangeable. |
| Self-hosting in your own VPC (docker-compose install) | The gateway runs next to your agents; our cloud is not in your data path, and our outages are not your outages. |
| SDK integration mode (identity + policy checks in your process) | Degrades independently of the gateway — an agent using the SDK against a healthy API is not affected by proxy-path issues. |
To be explicit about the trade: if the gateway's uptime is worse than your MCP servers' uptime, we have made you less reliable. That is the risk you are pricing in when you put any control plane in the data path — and it is why we publish it instead of burying it.
If agent identity is down, can my agents still work?
Partly. Agent tokens are self-contained JWTs — their signature is verified without a network call. But the gateway also looks up the agent's identity and revocation status in the database (cached for about 5 seconds), so a database outage degrades proxied calls once that cache expires. Registration, login, and the dashboard stop entirely during an API outage. Already-running agents pointed at healthy upstreams directly — not via the proxy — are unaffected. And remember the framing note above: because identity and gateway are one service, you won't see one down and the other up.
What if the policy engine errors while the gateway is healthy?
You choose, explicitly, per environment. The default fail mode is open: the call passes and a warning is logged — availability first. Set fail_mode: closed for an environment and the same error returns a 403 and raises an alert — security first. What never happens is silence: an errored policy check is always logged either way. If you run security-critical environments and haven't set closed, you are running open — go set it.
A related guarantee: your org's own policy document can never crash the gateway. It is strictly validated on save (an invalid document is never written), and if a stored document somehow becomes unreadable, the gateway logs a warning and falls back to the platform default — your overrides degrade, traffic does not.
What if the database goes down?
The database is the source of truth, so this is the outage that matters most: the dashboard, approvals, and — after the ~5 second identity cache expires — proxied calls all degrade. Run managed, highly available Postgres. The audit log is append-only at the database layer, so history survives an application compromise — but in self-hosted mode, database durability (backups, replication, restore drills) is your responsibility, not ours.
What if the dashboard goes down?
Zero impact on agent traffic. The dashboard is a static site that reads the API — it is not in the data path. Enforcement and logging continue exactly as before; you just can't watch them until it's back.
What if our upstream MCP server goes down?
The gateway returns a 502 to the caller and logs the call as an error. Nothing is silently dropped: the failed call appears in the feed and the audit record like any other, so an upstream outage is visible in the same place as everything else.
What do you see of our data, and where does it go?
Tool-call metadata and parameters are logged — we won't pretend it's metadata-only, because parameters are what make would-block analysis and audit useful. They are logged to your database. Alert channels are off by default, so there is zero egress until you configure one. Self-hosted, nothing leaves your VPC at all.
Can a compromised SentnelOps application rewrite history?
No. UPDATE and DELETE on audit rows are disabled at the database layer — the rules live in the schema, not in application code. An attacker with full control of the application can still write new events, but cannot alter or erase what was already written.
What happens to in-flight approvals during a deploy or restart?
The held connection drops with the restarting replica — the caller sees the connection fail and can retry. The pending approval row survives in the database, and on timeout it resolves to deny. A restart can never convert into an implicit approval.
How much latency do you add?
About 2 ms at p99, measured. The tested budget is 15 ms — the gateway is held to that bound in tests, and the measured number is what we actually see.