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.

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 five 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.

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:

	MCP Sidecar (this demo)	Mitrity Gateway
Role	Wraps an existing MCP server	Is the MCP server
Credential isolation	No -- agent has direct access to upstream	Yes -- agents never see upstream secrets
Tool sources	1 upstream server	Multiple upstreams + native HTTP
Tool names	Flat (read_file)	Namespaced (fs:read_file)
Best for	Quick retrofit onto existing setups	Production with credential isolation

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
• Integration modes — understand when to use Gateway vs Sidecar
• Writing policies — create your own governance rules
• Configuration reference — full sidecar YAML reference