MCP Tenant Isolation

mcp-tenant-isolation

Static analysis scanner for multi-tenant SaaS and MCP server code. 57 deterministic rules that catch cross-tenant data leakage before it reaches production.

What it does

If you build multi-tenant software, every query, every cache key, every file access, every API response needs to be scoped to the right tenant. Miss one, and Tenant A sees Tenant B's data. That's not a bug you want to find in production.

This scanner reads your source code and checks whether tenant isolation guards are present where they need to be. It covers 57 patterns across database queries, API routes, cache keys, file storage, schema design, logging, and MCP server architecture. It works with TypeScript, JavaScript, Prisma, Drizzle, raw SQL, Next.js, Express, and Fastify.

The scanner also runs as an MCP server, so you can plug it into Claude Desktop, Cursor, or any MCP-compatible agent and have your AI assistant scan code on demand.

Who uses this

• SaaS engineering teams who need to catch tenant isolation gaps before code ships
• MCP server developers building tools that handle tenant-scoped data
• Security teams who want tenant isolation checks in CI/CD
• AI agent developers who want their agents to scan code for cross-tenant risks

Why this exists

General-purpose security scanners are not purpose-built for tenant isolation patterns. They catch SQL injection and XSS. They do not check whether your findMany query includes an organizationId filter. They do not check whether your MCP tool handler scopes tool visibility by tenant. They do not check whether your cache key includes a tenant prefix.

This scanner does exactly that. 57 rules, each checking for a specific tenant isolation pattern, each producing a finding with the rule ID, file, line, missing guard, and a remediation hint.

Every rule is deterministic. Given the same source code, the scanner produces the same findings. No machine learning, no probabilistic scoring. Static analysis has inherent limitations though. It cannot verify runtime behavior, database-level enforcement, or dynamic tenant isolation. The scan output includes a limitations field that lists what was and was not checked for each run.

Install

npm install -g mcp-tenant-isolation

or use npx (no install needed)

npx mcp-tenant-isolation scan ./src

or use Docker (no Node.js needed)

docker run --rm -v $(pwd):/code subodhkc/mcp-tenant-isolation scan /code/src

Requires Node.js 22 or later.

Quick start

mti scan ./src

mti scan ./src --format sarif --output results.sarif mti scan ./src --format markdown --output TENANT-ISOLATION-REPORT.md mti scan ./src --format ai --output findings.json mti scan ./src --severity HIGH mti rules # list all 57 rules mti baseline # snapshot current findings for proof-of-fix tracking mti init # create .mtirc.json with defaults

Demo

Rules

42 general multi-tenant rules

15 MCP-specific rules

MCP rules are mapped to the OWASP MCP Top 10 (2025). See docs/OWASP-MAPPING.md for the full mapping. The mappings are advisory, for triage and reporting. This scanner does not certify OWASP compliance.

Architecture

The scanner pipeline runs in six stages:

1. Parsers — Babel AST for TypeScript/JavaScript, Prisma schema parser, SQL migration parser, MCP SDK import detection
2. IR and Flow Graph — Intermediate representation capturing sources, sinks, guards, routes, MCP tool definitions
3. Rule Engine — 57 deterministic rules evaluated against the IR. Each rule defines sources, sinks, and required guards
4. False Positive Filter — Test file detection, confidence scoring, pattern refinement
5. Reporters — Terminal, JSON, SARIF 2.1.0, AI-friendly JSON with remediation hints, Markdown
6. CLI and MCP Server — mti CLI with scan/init/rules/suppress/baseline/mcp commands. MCP server exposes 4 tools

Structured output

Scan results include structured metadata beyond just findings:

• Completeness — COMPLETE, PARTIAL, or ERROR. If files fail to parse or rules fail to evaluate, completeness drops to PARTIAL and the reasons are listed.
• Coverage — Files discovered, parsed, failed to parse. Rules available, selected, evaluated, failed, triggered. Unsupported file types counted.
• Concern families — Findings grouped into 8 concern families (Tenant Context, Data Isolation, Cache and Session, MCP Security, Secrets and Credentials, Vector and Storage, API and Access, Audit and Logging) for triage.
• Limitations — What the scan could and could not verify. Always includes static analysis limitation. Includes flow analysis scope and proof-of-fix status.
• Scan receipt — Provenance metadata with engine version, rulepack digest, timestamp, and a SHA-256 receipt hash for tamper detection.
• Proof-of-fix — Each finding is tagged as STILL_PRESENT, NEW, or NOT_VERIFIABLE relative to a baseline file. Run mti baseline to establish a baseline.

Fingerprints

Findings use v2 semantic fingerprints that are stable under line movement and formatting changes. The fingerprint is derived from the rule ID, file path, normalized code snippet, and sorted missing guards. It does not include the line number. This means if you move code around without changing its semantics, the fingerprint stays the same and baseline tracking remains accurate.

MCP server

The package includes an MCP server for AI agent integration. It runs locally via stdio transport. No hosting, no network exposure.

{

"mcpServers": { "tenant-isolation": { "command": "npx", "args": ["-y", "mcp-tenant-isolation", "mcp"] } } }

Add this to your Claude Desktop, Cursor, Windsurf, or other MCP client config to let your AI agent scan code for tenant isolation issues on demand.

MCP tools

The suppression tool is hidden by default. It only appears when the server is started with --allow-write-tools. This is a security boundary: read-only by default, write operations require explicit opt-in.

All filesystem operations during MCP scans are constrained to the project root configured at server startup. Traversal attacks (../), absolute paths outside root, UNC paths, and symlink escapes are rejected. See SECURITY.md for details.

CI/CD integration

Option 1: Pre-built GitHub Action (easiest)

Add this to .github/workflows/tenant-isolation.yml:

name: Tenant Isolation Scan

on: [push, pull_request] jobs: scan: runs-on: ubuntu-latest permissions: contents: read security-events: write steps:

• uses: actions/checkout@v4
• uses: subodhkc/mcp-tenant-isolation@v2 with: path: ./src severity: HIGH fail-on: HIGH

Runs the scan, uploads SARIF to GitHub Code Scanning, generates a Markdown report artifact, and fails the workflow if HIGH or CRITICAL findings are detected.

Option 2: Manual npx

name: Tenant Isolation Scan

on: [push, pull_request] jobs: scan: runs-on: ubuntu-latest permissions: contents: read security-events: write steps:

• uses: actions/checkout@v4
• uses: actions/setup-node@v4 with: node-version: 22
• run: npx mcp-tenant-isolation scan ./src --format sarif --output results.sarif
• uses: github/codeql-action/upload-sarif@v3 with: sarif_file: results.sarif

Exit codes

GitHub Code Scanning integration

When you upload SARIF output using github/codeql-action/upload-sarif@v3, findings appear in your repository's Security > Code scanning alerts tab. This works with both free and Advanced Security-enabled repos.

What happens:

1. mti scan --format sarif --output results.sarif generates a SARIF 2.1.0 file
2. upload-sarif action sends it to GitHub's code scanning API
3. Each finding becomes a code scanning alert with file, line, severit