MCP Gateway

Monitor and enforce policies for MCP tool calls between AI agents and external services.

The MCP Gateway sits as a transparent proxy between AI agents and MCP servers. Every tool call passes through the Palveron Verify flow: Server-active check → Approval-anchor check → Policy Check → Trace → optional Flare Anchor.

Two Operating Modes

Mode	How it works	Use case
Enforcement Gateway	Palveron forwards Streamable-HTTP (JSON) traffic — tool calls are intercepted, inspected, and forwarded	Coding-agent target servers (GitHub, filesystem, database MCP servers), in-house MCP servers
Governance Control Plane	Native SaaS agents that cannot be proxied are registered as governed servers; their tool calls are governed by tool policies	Salesforce Einstein, Microsoft Copilot, ServiceNow

Clients vs. servers

Cursor, Windsurf and Claude Code are MCP clients, not servers you connect to Palveron. You register the target MCP server (a GitHub, database or filesystem MCP server) and paste its Palveron proxy URL into your client. See the Setup Guide.

How It Works

Register a target MCP server — from the searchable catalog or by custom address (Editor role)
Scan the server to discover its tools; Palveron auto-assigns a risk-based starting verdict per tool
An Admin activates the server — only an ACTIVE server serves tool calls (deny-until-active)
Route traffic through the Palveron proxy endpoint (your client points at it)
Every tool call produces a tamper-evident trace with optional Flare blockchain attestation

Proxy Endpoint

Agents connect to the Palveron-generated proxy endpoint instead of directly to the MCP server:

POST /api/v1/mcp/proxy/{server_id}
Content-Type: application/json
Authorization: Bearer {project_api_key}

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": { "name": "query_records", "arguments": { "query": "SELECT Id FROM Account" } },
  "id": 1
}

Palveron forwards the JSON-RPC request to the actual MCP server after all checks have passed.

Policy Actions

Four enforcement actions available per tool:

Action	Behavior
`ALLOW`	Tool call is allowed
`LOG_ONLY`	Tool call is allowed but produces a detailed audit trace
`REQUIRE_APPROVAL`	Tool call is queued for manual approval (pending approvals expire)
`DENY`	Tool call is blocked — the agent receives a JSON-RPC error

Since a scan auto-assigns a starting verdict to every discovered tool, most calls resolve against an explicit policy. When no policy matches at all, the call is allowed and the trace is marked DEFAULT_ALLOW_NO_POLICY so dashboards can surface ungoverned calls.

Security Features

Approval anchor + drift detection — when an Admin approves a server, Palveron freezes a per-tool fingerprint over the tool's name, description and input parameters (approvedHash). If a tool later deviates from that approved state, its calls are blocked (APPROVED_FINGERPRINT_MISMATCH) and audited (McpToolDrift → OCSF/SIEM) until an Admin re-approves. The cockpit reports "unchanged since approval", not "since last scan".
Risk classification — Automatic CRITICAL/HIGH/MEDIUM/LOW based on tool capabilities, which seeds the starting verdict
Emergency stop — Admin-gated and audited; instantly block all MCP servers or a specific server/agent
Blockchain audit trail — BLOCKED decisions and HIGH/CRITICAL-risk calls are attested on Flare

Connecting a Server

There are two ways to connect, both packageless — you always end up with a governed proxy URL:

From the catalog — browse the official MCP registry mirror (GET /api/v1/mcp/registry), searchable, with trust signals (last updated, source-repository link), and connect in one click.
Custom address — register any reachable MCP server by its URL.

Either way Palveron returns a server id; the governed endpoint your client uses is POST /api/v1/mcp/proxy/{id}. See Server Management.