New: Agent approvals, red teaming and model scanning. See how
MITRITY
Docs / Gateway, Sidecar & Mesh / Integration Modes

Integration Modes

MITRITY ships two governance binaries, Mitrity Gateway and Mitrity MCP Sidecar. Each one is built for a different integration pattern. This page explains how each one works and when to use it, so you can deploy the one that fits your architecture.

Some agents run inside a SaaS platform, such as GitHub Copilot, Microsoft 365 Copilot or Salesforce Agentforce, where no binary can be deployed. For those agents, see SaaS-Embedded Agent Governance instead.

Mitrity Gateway

Mitrity Gateway is the primary integration mode. It is a governed MCP server: it combines the tools of several upstream MCP servers and native HTTP APIs into a single, governed endpoint.

How it works:

  1. Install Mitrity Gateway where the agent runs: as a binary on the host, or inside the image of the agent's container or pod.
  2. Configure the upstream MCP servers and native HTTP API connectors in mitrity-gateway.yaml.
  3. Point your MCP client at the gateway binary. The client launches the gateway over stdio and sees one combined 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. The gateway routes allowed calls to the correct upstream. Denied calls get a governed error response.

What the gateway gives you:

  • Tool aggregation: tools from several MCP servers and HTTP APIs are combined into one governed endpoint. Agents see one MCP server with all available tools.
  • Credential isolation: the gateway holds the upstream credentials (API keys, tokens, service accounts) and never shares them with agents. Agents authenticate to the gateway, and the gateway authenticates to the 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: you define HTTP API endpoints as tools, next to the MCP upstreams. The gateway translates each tool call into an HTTP request and applies the same governance pipeline.
  • Local ML inference: with ml.enabled (off by default), the DriftGuard model runs directly on the gateway for behavioral analysis.

Use Mitrity Gateway when:

  • you have several upstream MCP servers or HTTP APIs to govern;
  • you need credential isolation, so agents never see upstream secrets;
  • you want a single governance point for all agent tool access;
  • you need native HTTP API connectors next to your MCP upstreams;
  • you are deploying governance across many agents with different tool needs.

The gateway is a Linux or macOS amd64/arm64 binary. The agent's MCP client launches it over stdio, on a host or inside the agent's own container or pod. There is no Windows gateway build. There is also no detached gateway service; the one exception, --standalone, serves only the admission API described below. See the deployment guide for details.

For all gateway fields, including upstreams[], native_tools[] and credentials, see the configuration reference.

Mitrity MCP Sidecar

Mitrity MCP Sidecar is a lightweight stdio wrapper for a single upstream MCP server. It intercepts tools/call JSON-RPC 2.0 requests, evaluates them against your governance policies and forwards the allowed calls to the upstream server.

How it works:

  1. Install the sidecar binary next to your AI agent.
  2. Configure the upstream MCP server's command and arguments in mitrity-mcp-sidecar.yaml.
  3. Point your MCP client at the sidecar instead of directly at the upstream server.
  4. The sidecar intercepts every tools/call request and validates it against your policies and the local ML model.
  5. The sidecar forwards allowed calls to the upstream server. Denied calls get a JSON-RPC error response.

What sets the sidecar apart:

  • Lightweight: no HTTP server and no listening socket. It communicates over stdio only.
  • Protocol-native: it works at the JSON-RPC 2.0 / MCP protocol level.
  • Local-only: it runs on the same machine as the agent and wraps a single upstream server.
  • Simple configuration: it needs only the upstream command, the agent ID and the control plane credentials.

Use Mitrity MCP Sidecar when:

  • 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 changing the MCP server or the client;
  • you run a single MCP server for file access, database queries or API calls.

The sidecar is a binary that you install on the same machine as your agent, and the agent's MCP client launches it. It ships for Linux, macOS and Windows, and it is the only option on Windows. See the deployment guide for details.

For sidecar-specific settings, including upstream_command, upstream_args and agent_id, see the configuration reference.

The third entrance: framework built-in tools

Both binaries can also serve a loopback admission API. This is a Unix socket (or 127.0.0.1) that is never reachable from the network.

mitrity-hook runs as the PreToolUse hook of Claude Code or the Claude Agent SDK. Before a built-in tool (Bash, Write, Edit, WebFetch) runs, the hook asks the admission API. The edge answers with the same pipeline, the same holds and the same audit trail as for an MCP call, and stamps the event surface=agent_hook.

The hook fails closed: when nothing answers, the tool call is blocked.

On a developer machine, the gateway runs the admission API and nothing else, with --standalone.

The admission API is available from edge release v0.20. For the install steps, and for what it covers in each framework, see Governance Coverage.

Comparison

CapabilityMitrity GatewayMitrity MCP Sidecar
Upstream serversMultiple MCP + HTTPSingle MCP
Credential isolationYes: agents never see upstream secretsNo: the agent has direct access to the upstream
Native HTTP connectorsYesNo
Tool aggregationYesNo
Governance pipelineFull (policies, DLP, injection, threats)Full (policies, DLP, injection, threats)
Local ML inferenceYesYes
Transportstdio, spawned by the agent's MCP clientstdio, spawned by the agent's MCP client
Deployment modelLocal process, on the host or in the agent's container or podLocal process (stdio wrapper)
Operating systemsLinux, macOS (amd64, arm64)Linux, macOS, Windows
CoverageMCP tools/call + native HTTP tools (full statement)MCP tools/call on the wrapped upstream (full statement)
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 gives you credential isolation, tool aggregation and native HTTP connectors, and these become essential as your agent infrastructure grows. Even if you start with a single upstream, the gateway gives you room to grow without re-architecting.

Use Mitrity MCP Sidecar when you have a simple, single-server setup and want the lightest possible footprint. The sidecar suits a single MCP server process where you do not need credential isolation or tool aggregation.

Both binaries report to the same MITRITY control plane. Whichever mode you deploy, you get the same governance and the same audit view.

Both modes govern the same thing: MCP tools/call, plus native HTTP tools on the gateway. Neither one governs the execution tools that your agent framework already has built in. Before you rely on either mode, read Governance Coverage.