MITRITYMITRITY

Integration Modes

MITRITY ships two purpose-built governance binaries, each designed for a different integration pattern. Deploy the one that fits your architecture.

Mitrity Gateway

The primary integration mode. Mitrity Gateway is a governed MCP server that aggregates tools from multiple upstream MCP servers and native HTTP APIs into a single, governed endpoint.

How it works:

  1. Deploy Mitrity Gateway as a Docker container, standalone binary, or Cloud Run service
  2. Configure upstream MCP servers and native HTTP API connectors in mitrity-gateway.yaml
  3. Point your MCP client at the gateway -- it exposes a unified set of tools from all configured upstreams
  4. Every tools/call request passes through the governance pipeline: policy evaluation, DLP scanning, injection detection, and threat matching
  5. Allowed calls are routed to the correct upstream; denied calls return a governed error response

Key capabilities:

  • Tool aggregation: Combine tools from multiple MCP servers and HTTP APIs into a single governed endpoint. Agents see one MCP server with all available tools
  • Credential isolation: Upstream credentials (API keys, tokens, service accounts) are held by the gateway and never shared with agents. Agents authenticate to the gateway; the gateway authenticates to upstreams
  • Governance pipeline: Every tool call is evaluated against policies, scanned for DLP violations, checked for prompt injection patterns, and matched against threat indicators
  • Native HTTP connectors: Define HTTP API endpoints as tools alongside MCP upstreams. The gateway translates tool calls into HTTP requests, applying the same governance pipeline
  • Local ML inference: The DriftGuard model runs directly on the gateway for sub-millisecond behavioral analysis

When to use Mitrity Gateway:

  • You have multiple upstream MCP servers or HTTP APIs to govern
  • You need credential isolation -- agents should never see upstream secrets
  • You want a single governance point for all agent tool access
  • You need native HTTP API connectors alongside MCP upstreams
  • You are deploying governance across many agents with diverse tool requirements

Deployment: Docker container, standalone binary, systemd service, or Cloud Run. See the deployment guide for details.

Configuration: See the configuration reference for all gateway fields including upstreams[], native_tools[], and credentials.

Mitrity MCP Sidecar

A lightweight stdio wrapper for a single upstream MCP server. The sidecar intercepts tools/call JSON-RPC 2.0 requests, evaluates them against governance policies, and forwards allowed calls to the upstream server.

How it works:

  1. Install the sidecar binary alongside your AI agent
  2. Configure the upstream MCP server command and arguments in mitrity-mcp-sidecar.yaml
  3. Point your MCP client at the sidecar instead of the upstream server directly
  4. Every tools/call request is intercepted and validated against policies and the local ML model
  5. Allowed calls are forwarded to the upstream server; denied calls return a JSON-RPC error response

Key characteristics:

  • Lightweight: No HTTP server, no network stack. Communicates via stdio only
  • Protocol-native: Operates at the JSON-RPC 2.0 / MCP protocol level
  • Local-only: Runs on the same machine as the agent, wrapping a single upstream server
  • Simple configuration: Only needs the upstream command, agent ID, and control plane credentials

When to use Mitrity MCP Sidecar:

  • You have a single MCP server to govern and do not need tool aggregation
  • You want the simplest possible deployment with minimal configuration
  • You need protocol-native governance without modifying the MCP server or client
  • You are running a single MCP server for file access, database queries, or API calls

Deployment: Binary download, installed on the same machine as your agent. See the deployment guide for details.

Configuration: See the configuration reference for sidecar-specific settings including upstream_command, upstream_args, and agent_id.

Comparison

CapabilityMitrity GatewayMitrity MCP Sidecar
Upstream serversMultiple MCP + HTTPSingle MCP
Credential isolationYes -- agents never see upstream secretsNo -- agent has direct access to upstream
Native HTTP connectorsYesNo
Tool aggregationYesNo
Governance pipelineFull (policies, DLP, injection, threats)Full (policies, DLP, injection, threats)
Local ML inferenceYesYes
Deployment modelNetwork service (Docker, binary, Cloud Run)Local process (stdio wrapper)
Configuration complexityModerate (upstreams, credentials, native tools)Minimal (upstream command, agent ID)

Choosing the right mode

Start with Mitrity Gateway. It is the recommended default for most deployments. The gateway provides credential isolation, tool aggregation, and native HTTP connectors -- capabilities that become essential as your agent infrastructure grows. Even if you start with a single upstream, the gateway gives you room to scale without re-architecting.

Use Mitrity MCP Sidecar when you have a simple, single-server setup and want the lightest possible footprint. The sidecar is ideal for wrapping a single MCP server process where credential isolation and tool aggregation are not needed.

Both binaries report to the same MITRITY control plane, so you get unified governance and audit visibility regardless of which mode you deploy.

Related Documentation

PreviousDeployment GuideNextConfiguration Reference
Integration Modes — Documentation | MITRITY