Skip to main content
An agent that speaks the Model Context Protocol (MCP) is only as safe as the servers it connects to. Every MCP server is a fresh set of tools, a fresh credential, and fresh network reach — and the moment an agent dials one directly, nobody is watching the call. That is the whole problem mcp security has to solve: not “is this one tool safe” but “who governs all of them, on every call, with one audit trail.” OrcaRouter’s answer is a single audited choke point. You register each MCP server once; agents connect to one gateway; and every tools/call runs through the firewall engine before it reaches the real server. This page is the map of that surface — the gateway, the per-call verdict, skill governance, egress, and encrypted credentials — with links to the focused how-to for each.
Every management action here is configured from the console (or the REST API with your session/access token) and is role-gated. Only /v1/* relay calls and the firewall gateway routes carry an sk-orca-...-style key.

​
1. Why mcp security needs a gateway

Point ten agents at five community MCP servers directly and you get the worst of every world: no shared policy, no audit trail, credentials copied into ten agent configs, and a tool named shell.exec one redirect away from your cloud-metadata endpoint. The gateway collapses that into one governed connection.

One connection, every server

Agents connect to a single endpoint. The gateway aggregates the tools of every enabled, reachable server under a <server>.<tool> namespace.

Policy on every call

Each tools/call is evaluated by your firewall policy before dispatch.

Encrypted credentials

Server auth secrets are encrypted at rest, masked on read, and injected at dispatch — they never reach the model or client.

Egress under control

A registered server’s endpoint is validated against private and cloud-metadata IP ranges by default. For per-tool destinations, apply the baseline SSRF egress denylist or author your own host/CIDR rules.
For the foundations behind all of this, see Securing AI agents and Why zero trust.

​
2. The four building blocks

MCP governance on OrcaRouter is four cooperating pieces. Pick the one that matches the question you’re trying to answer.
A single endpoint your agents connect to instead of dialing servers directly. It aggregates every registered server’s tools, namespaced <server>.<tool>, and re-exposes each tool’s input schema verbatim. Start at Connect an MCP server and Authenticate; the full reference lives in Firewall: MCP servers.
The gateway runs each tools/call through the firewall on the mcp surface and returns a verdict — allow, audit, deny, sanitize, or pending_approval — before dispatch. See Allow-list MCP tools and Sanitize tool arguments.
Capabilities an agent self-installs — skills, BYO MCP servers, plugins — are scanned, assigned a risk band, and given an enforcement mode (allow / quarantine / block) that rides on top of every rule verdict. See Firewall: skills and Rug-pull defense.
Each server’s auth secret is encrypted at rest and masked on read. See Authenticate and Credential rotation.

​
3. How a tools/call is evaluated

When an agent calls a tool through the gateway, the call doesn’t go straight to the server. It is matched against your workspace policy, the owning skill’s enforcement mode is applied on top, and only an allow / audit / sanitize verdict reaches the real server.
VerdictWhat the agent sees
allow / auditForwarded. audit also logs an event.
sanitizeForwarded with arguments redacted (never the result).
deny / pending_approvalReturned as a tool error, so the agent can adapt instead of crashing.
A blocked MCP call comes back as a tool error (firewall deny: …), the same shape any failing tool returns — the agent can retry differently, ask the user, or stop. It is not a transport crash.
The verdict vocabulary, surfaces, and rule matching are documented in full under Firewall and Firewall rules; the conceptual model is in Enforcement modes and How OrcaRouter inspects.

​
4. Register a server (one concrete example)

You register each server once. A server record carries a name (unique per workspace, no .), an endpoint, an auth_mode (none / bearer / oauth / basic), and its encrypted credentials. Do this from the console — the write requires Developer+. 
# Console route, called with your session/access token (UserAuth).
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
Then probe it to discover its tools and record reachability (ok / degraded / down): 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
Now you can write rules against github.* knowing exactly what github.create_issue accepts. The end-to-end walkthrough lives in Connect an MCP server.
Secrets are never stored in plaintext. auth_json is encrypted at rest and masked on read; on an update, echo the mask back to keep the stored value. See Credential rotation.

​
5. Connect an agent to the gateway

Once servers are registered, point any MCP client at the gateway with a firewall-gateway-scoped key (a token without that scope gets 403): 
https://api.orcarouter.ai/api/v1/firewall/mcp
The gateway speaks streamable HTTP and advertises every enabled, reachable server’s tools under the <server>.<tool> namespace. An SDK that proxies calls itself can read the runtime registry from GET /api/v1/firewall/mcp_servers with the same gateway token.

​
6. Lock down what tools can reach

Per-call verdicts govern which tool runs; egress controls govern where it may reach. Two layers cooperate. First, when the gateway connects to a registered server’s endpoint, that URL is validated against private (RFC1918), loopback, link-local, and cloud-metadata ranges by default — and the host is DNS-resolved so a name that resolves into a blocked range is refused too. So a BYO server pointed at 169.254.169.254 or an intranet address is rejected unless you’ve explicitly whitelisted it. Second, for per-tool destinations, an egress rule carries a host/CIDR allow/deny list matched against the call’s outbound destination on the egress surface. The baseline use-case template ships a ready-made egress deny rule whose list already covers the private, loopback, link-local, and cloud-metadata ranges (including 169.254.169.254 and metadata.google.internal), so applying it gives you SSRF/metadata defense without authoring CIDRs by hand.
SSRF and egress are the difference between “this tool returned data” and “this tool exfiltrated your secrets to an attacker’s host.” Apply the baseline egress denylist and add your own host/CIDR rules — see Egress limits and Data exfiltration.

​
7. Watch it: events, runs, and anomalies

Every governed call leaves a trail. Firewall events record the verdict, surface, and matched rule; runs group a session’s calls; and the anomaly feed flags rate and cost spikes against a learned baseline. Reads of settings, policies, and discovered tools are open to any Member; event/run/aggregate reads require Developer+.

​
8. Where to go next

Connect an MCP server

Register, probe, and expose a server through the gateway.

Allow-list MCP tools

Default-deny a server and permit only the tools you’ve reviewed.

Rug-pull defense

Govern servers and skills that change after you approved them.

Firewall: MCP servers

The complete field-and-route reference.
New to the model? Read Guardrails vs. firewall to see where MCP governance fits, then MCP tool poisoning and Excessive agency for the threats it closes.