Demo: Mitrity MCP Sidecar

Run a self-contained Docker demo that exercises every governance capability through a realistic, scripted scenario. A Claude-powered AI agent performs tool calls through Mitrity MCP Sidecar while your policies, DLP rules, injection detection, and hold workflows are enforced in real-time.

The demo takes about 10 minutes and requires only Docker Desktop and API keys.

Looking for the gateway version? See Demo: Mitrity Gateway for the multi-upstream variant with credential isolation and tool aggregation.

Want to see multi-agent delegation chains? See Demo: Multi-Agent Governance for a three-container compose stack exercising real agent-to-agent delegation, per-agent threat intel, and privilege boundaries.

Prerequisites

• Docker Desktop (or any Docker runtime)
• A MITRITY account with an active tenant
• An Anthropic API key for the Claude agent

Step 1: Configure your dashboard

Before running the demo, set up three things in the MITRITY dashboard:

Register an agent

Go to Agents > Register Agent and create an agent:

• Name: demo-agent
• Mission scope: "Workspace file management and system operations"

Copy the Agent ID (UUID). Also copy the Agent Key (ak_...). Save it — it cannot be retrieved later.

Create policies

Create the following policies to see the full range of governance decisions:

Policy	Type	Pattern	Scope
Allow workspace reads	allow	read_file	path starts with /workspace
Allow workspace writes	allow	write_file	path starts with /workspace
Allow safe commands	allow	run_command	ls, pwd, cat, echo, whoami
Block system files	deny	read_file, delete_file	path outside /workspace
Block destructive commands	deny	run_command	rm, curl, wget, nc, chmod
Block dangerous SQL	deny	query_database	contains DROP, DELETE, TRUNCATE
Hold production deploys	hold	call_api	url contains "production"

Also enable these global settings:

• Prompt injection detection
• DLP with PII and credential patterns

Note: Tool names are flat in the sidecar demo (read_file, run_command, call_api) because the sidecar wraps a single upstream server without namespacing.

Step 2: Clone and configure

git clone git@github.com:mitrity-io/iag-demo-mcp-sidecar.git
cd iag-demo-mcp-sidecar
cp .env.example .env

Edit .env with your values:

ANTHROPIC_API_KEY=sk-ant-...              # Anthropic API key for Claude
MITRITY_AGENT_KEY=ak_...                  # Agent key from dashboard
MITRITY_CONTROL_PLANE_URL=https://api.mitrity.com
MITRITY_AGENT_ID=<uuid>                   # Agent UUID from dashboard

Step 3: Run the demo

docker compose up --build

The container builds locally (pulls the Mitrity MCP Sidecar binary from ghcr.io), then runs the scenario. Watch your terminal for the output.

What the demo does

The scenario runs the same six phases as the gateway demo:

Phase 1 — Normal Operations. The agent reads workspace files, writes summaries, lists directories, runs safe shell commands, and calls APIs. All actions pass through the sidecar and are allowed by your policies.

Phase 2 — Policy Violations. The agent attempts to read /etc/passwd, run rm -rf, execute curl, and issue a DROP TABLE query. The sidecar blocks each action and returns the policy reason.

Phase 3 — Prompt Injection. The agent processes "user input" that contains embedded injection payloads. The sidecar's injection detection engine catches and blocks the attacks before any tool executes.

Phase 4 — DLP & Data Protection. The agent tries to write files containing API keys and AWS secrets, send notifications with PII (SSNs, credit card numbers), and include credentials in API calls. The sidecar's DLP engine blocks data exfiltration.

Phase 5 — Escalation & Hold. The agent attempts a production deployment. The sidecar's hold policy pauses the action and creates an approval request visible in your MITRITY dashboard.

Phase 6 — Credential Broker + Hot Rotation. The agent calls connect_database with ${credential:demo_db_password} in the connection string. The sidecar resolves the placeholder via the broker; the upstream tool returns the password hash. Mid-phase you rotate the credential in the dashboard — the next call picks up the new value within 30 seconds with no agent or sidecar restart. A final sub-step exercises the fail-closed path with an unknown credential id. Requires creating a demo_db_password credential definition + grant in your tenant before running (see Credentials docs).

What to look for

While the demo runs, open your MITRITY dashboard to see:

• Audit Log: Every tool call with its governance decision, latency, and policy match
• Agent Detail: The demo agent's activity timeline and drift score
• Approval Requests: The held production deployment waiting for your approval (Phase 5)

At the end, the terminal prints a summary with counts of allowed, blocked, and held actions.

Architecture

The entire demo runs inside a single Docker container:

Docker Container
└── Python scenario runner (Claude Agent SDK)
    └── Mitrity MCP Sidecar (governance wrapper)
        └── demo-tools (single MCP server)
            ├── read_file, write_file, list_directory, delete_file
            ├── run_command
            └── call_api, query_database, send_notification

The sidecar connects to your MITRITY control plane via HTTPS. Filesystem and shell tools execute for real against the container's /workspace directory. API tools return mock responses.

Gateway vs Sidecar

Both demos run the same governance scenario. The difference is in the deployment model — not in governance fidelity. Both binaries share the same interceptor (TI, delegation, DLP, injection, holds, credential broker); the choice is about where each sits in the MCP request path:

	MCP Sidecar (this demo)	Mitrity Gateway
Role	Transparent proxy in front of one existing MCP server	Is the MCP server, aggregating many sources
Tool sources	1 upstream server	Multiple upstreams + native HTTP tools
Tool names	Flat (read_file) — passes through unchanged	Namespaced (fs:read_file) — applied per upstream
Credential broker injection	Yes (arg-rewrite + file mounts)	Yes (arg-rewrite + file mounts + native HTTP headers)
Best for	Retrofit onto an existing MCP server without changing the agent	Aggregating many tool sources behind one governed endpoint

For a deeper comparison, see Integration modes.

Environment variables

Variable	Required	Description
ANTHROPIC_API_KEY	Yes	Anthropic API key for Claude
MITRITY_AGENT_KEY	Yes	Agent key from dashboard
MITRITY_CONTROL_PLANE_URL	Yes	Control plane URL
MITRITY_AGENT_ID	Yes	Agent UUID from dashboard
MITRITY_DEMO_SPEED	No	normal (default) or fast (skip pauses)
ANTHROPIC_MODEL	No	Claude model (default: claude-sonnet-4-20250514)

Customization

• Policies: Modify policies in the MITRITY dashboard and re-run the demo to see different behaviors
• Workspace: Mount your own files via volumes in docker-compose.yml
• Scenarios: Edit files in scenario/phases/ to add custom test prompts

Next steps

• Demo: Mitrity Gateway — run the same scenario with multi-upstream tool aggregation
• Demo: Multi-Agent Governance — three-container stack exercising real delegation chains, per-agent threat intel, and privilege boundaries
• Integration modes — understand when to use Gateway vs Sidecar
• Writing policies — create your own governance rules
• Configuration reference — full sidecar YAML reference