Integration Modes

MITRITY ships two purpose-built governance binaries, each designed for a different integration pattern. Deploy the one that fits your architecture. (For agents that run inside a SaaS platform -- GitHub Copilot, Microsoft 365 Copilot, Salesforce Agentforce -- where no binary can be deployed, see SaaS-Embedded Agent Governance instead.)

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. Install Mitrity Gateway where the agent runs -- a binary on the host, or the image baked into the agent's container or pod
2. Configure upstream MCP servers and native HTTP API connectors in mitrity-gateway.yaml
3. Point your MCP client at the gateway binary -- it launches the gateway over stdio and sees 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: a Linux or macOS amd64/arm64 binary, launched over stdio by the agent's MCP client -- on a host, or inside the agent's own container or pod. There is no Windows gateway build, and no detached gateway service (the one exception, --standalone, serves only the admission API described below). 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 listening socket. 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: a binary installed on the same machine as your agent and launched by its MCP client. Ships for Linux, macOS and Windows -- it is the only option on Windows. See the deployment guide for details.

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

The third entrance: framework built-in tools

Both binaries can also serve a loopback admission API -- a Unix socket (or 127.0.0.1) that is never reachable from the network. mitrity-hook, running as Claude Code's or the Claude Agent SDK's PreToolUse hook, asks it before a built-in tool (Bash, Write, Edit, WebFetch) runs, and the edge answers with the same pipeline, the same holds and the same audit trail as an MCP call, stamped surface=agent_hook. The hook fails closed: when nothing answers, the tool call is blocked. On a developer machine the gateway runs this and nothing else with --standalone. Available from edge release v0.20; install steps and what it covers per framework: Governance Coverage.

Comparison

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.

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

Related Documentation

• Governance Coverage -- what each mode governs, what it does not, and how to close the gap
• Deployment Guide -- installation and deployment options for both binaries
• Configuration Reference -- full YAML configuration reference
• Mesh Enforcement (Istio) -- the same decision engine applied at an Istio service-mesh decision point
• Writing Policies -- writing governance policies
• Getting Started -- end-to-end quickstart guide
• SaaS-Embedded Agent Governance -- govern agents that run inside GitHub, Microsoft 365, or Salesforce, where no edge can be deployed