Demo: Mitrity Gateway

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 Gateway 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 sidecar version? See Demo: Mitrity MCP Sidecar for the single-upstream variant.

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:

PolicyTypePatternScope
Allow workspace readsallowfs:read_filepath starts with /workspace
Allow workspace writesallowfs:write_filepath starts with /workspace
Allow safe commandsallowshell:run_commandls, pwd, cat, echo, whoami
Block system filesdenyfs:read_file, fs:delete_filepath outside /workspace
Block destructive commandsdenyshell:run_commandrm, curl, wget, nc, chmod
Block dangerous SQLdenyapi:query_databasecontains DROP, DELETE, TRUNCATE
Hold production deploysholdapi:call_apiurl contains "production"

Also enable these global settings:

  • Prompt injection detection
  • DLP with PII and credential patterns

Note: Tool names are namespaced in the gateway demo (fs:read_file, shell:run_command, api:call_api) because Mitrity Gateway aggregates tools from multiple upstream servers with namespace prefixes.

Step 2: Clone and configure

git clone git@github.com:mitrity-io/iag-demo-mcp-gateway.git
cd iag-demo-mcp-gateway
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 Gateway binary from ghcr.io), then runs the scenario. Watch your terminal for the output.

What the demo does

The scenario runs six phases:

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 gateway 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 gateway blocks each action and returns the policy reason.

Phase 3 — Prompt Injection. The agent processes "user input" that contains embedded injection payloads. The gateway'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 gateway's DLP engine blocks data exfiltration.

Phase 5 — Escalation & Hold. The agent attempts a production deployment. The gateway'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 api:connect_database with ${credential:demo_db_password} in the connection string. The gateway 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 gateway 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 Gateway (governed MCP server)
        ├── upstream "fs": filesystem tools (read, write, list, delete)
        ├── upstream "shell": command execution
        └── upstream "api": mock API, database, and notification tools

The gateway 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.

Environment variables

VariableRequiredDescription
ANTHROPIC_API_KEYYesAnthropic API key for Claude
MITRITY_AGENT_KEYYesAgent key from dashboard
MITRITY_CONTROL_PLANE_URLYesControl plane URL
MITRITY_AGENT_IDYesAgent UUID from dashboard
MITRITY_DEMO_SPEEDNonormal (default) or fast (skip pauses)
ANTHROPIC_MODELNoClaude 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 — Documentation | MITRITY