The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the MCP Tenant Isolation listing page.
Static analysis scanner for multi-tenant SaaS and MCP server code. 57 deterministic rules that catch cross-tenant data leakage before it reaches production.
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.
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.
Requires Node.js 22 or later.
| Prefix | Category | Count | Severity | What it checks |
|---|---|---|---|---|
| TCM | Tenant Context Management | 6 | Critical | Tenant ID comes from session, not client input. Context propagation across async boundaries. |
| DBQ | Database Query Isolation | 10 | Critical | Every query touching tenant-scoped data includes a tenant filter. Prisma, Drizzle, raw SQL. |
| IDOR | IDOR Prevention | 5 | Critical | ID-based lookups verify tenant ownership before returning data. |
| CSI | Cache and Session Isolation | 4 | High | Cache keys and session data are tenant-scoped. |
| API | API Security | 3 | High | Tenant-aware rate limiting and response scoping. |
| FSI | File Storage Isolation | 4 | High | S3, Blob, and filesystem access is tenant-scoped. |
| LOG | Logging and Audit | 4 | Medium | Audit logs include tenant context. |
| SCH | Schema and Migration | 6 | High | Prisma models and SQL migrations include tenant columns and indexes. |
| ID | Title | Severity | What it checks |
|---|---|---|---|
| MCP-001 | Tool Visibility Scoping | Critical | Tool handler has no tenant-based allow/deny filter. |
| MCP-002 | Cache Key Tenant Prefix | Critical | Tool results cached without tenant prefix. |
| MCP-003 | Session Binding to User+Tenant | Critical | Session ID used as sole authorization. |
| MCP-004 | Token Exchange (RFC 8693) | High | Original token forwarded instead of token exchange. |
| MCP-005 | Per-Tenant Rate Limiting | Medium | No per-tenant rate limiting on tool calls. |
| MCP-006 | Vector Store Tenant Namespace | High | Shared vector store without tenant namespaces. |
| MCP-007 | Tool Description Injection | Medium | Tool description could bypass isolation. |
| MCP-008 | Credential Vault Tenant Scoping | Critical | Credential vault stores tokens without tenant scoping. |
| MCP-009 | Shared Service Account | High | Single shared API key for all tenant API calls. |
| MCP-010 | Session Cleanup on Disconnect | Medium | No deterministic session cleanup. |
| MCP-011 | Telemetry Tenant Identifier | Low | Telemetry strips tenant identifier. |
| MCP-012 | Local Bind (127.0.0.1) | High | MCP server binds to 0.0.0.0 instead of 127.0.0.1. |
| MCP-013 | Filesystem Tenant Root | High | Tool handler accesses filesystem without tenant root. |
| MCP-014 | Cross-Tenant Artifact Leakage | High | Artifact storage without tenant prefix. |
| MCP-015 | Dynamic Tool Namespace | Medium | Tools registered without tenant namespace. |
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.
The scanner pipeline runs in six stages:
mti CLI with scan/init/rules/suppress/baseline/mcp commands. MCP server exposes 4 toolsScan results include structured metadata beyond just findings:
mti baseline to establish a baseline.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.
The package includes an MCP server for AI agent integration. It runs locally via stdio transport. No hosting, no network exposure.
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.
| Tool | Description | Write? |
|---|---|---|
scan_tenant_isolation | Scan a project path. Returns structured findings with completeness, coverage, concern families, and receipt. | No |
list_tenant_isolation_rules | Returns all 57 rules with metadata. Filterable by category. | No |
explain_tenant_isolation_rule | Returns rule details, OWASP mapping, CWE IDs, fix suggestions. | No |
suppress_tenant_isolation_finding | Add a suppression with reason, approver, controls, and expiry. | Yes (opt-in) |
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.
Add this to .github/workflows/tenant-isolation.yml:
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.
| Code | Meaning |
|---|---|
| 0 | No findings |
| 1 | Findings found |
| 2 | Error (config invalid, parse failure, etc.) |
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:
mti scan --format sarif --output results.sarif generates a SARIF 2.1.0 fileupload-sarif action sends it to GitHub's code scanning APIRequirements:
permissions: security-events: write in your workflowCreate .mtirc.json in your project root:
| Field | Description |
|---|---|
output | Default output format: terminal, json, sarif, ai, markdown |
framework | Framework hint: nextjs-app-router, nextjs-pages, express, fastify, auto |
authHelpers | Custom auth function names to detect (reduces false positives) |
tenantGuards | Custom tenant guard variable names beyond the defaults |
modelScopes | Override model scope classification (userScoped, global, tenantScoped) |
rulePacks | Paths to custom rule pack JSON files |
You can extend the scanner with custom rules via JSON rule packs. Custom rules are validated at load time:
PREFIX-NNN format (e.g., CUST-001)Invalid custom rules are rejected with warnings. The scan continues with built-in rules.
Suppressions require a concrete finding fingerprint, a rule ID, a documented approver identifier, a reason, compensating controls, and an expiry date. Rule-wide suppressions (no fingerprint) are only permitted as documented permanent exceptions.
The documentedApprover field records who approved the suppression. It does not represent independent human verification. It is a recorded attribution string, not a claim of external review.
Run mti baseline to snapshot current findings. Future scans compare against the baseline and tag each finding as STILL_PRESENT, NEW, or NOT_VERIFIABLE (if no baseline exists). This gives you proof-of-fix tracking over time.
| Format | Flag | Use case |
|---|---|---|
| Terminal | --format terminal (default) | Developer console with pass/fail verdict |
| JSON | --format json | Programmatic consumption, piping to other tools |
| SARIF | --format sarif | GitHub Code Scanning, Azure DevOps |
| AI JSON | --format ai | AI agent consumption with remediation hints and context |
| Markdown | --format markdown | Shareable report for PRs, team review, documentation |
npm ci for reproducible installs.Static analysis has inherent limits. Being upfront about them:
.mtirc.json to reduce false positives.See docs/FLOW-ANALYSIS-QUALIFICATION.md for detailed flow analysis scope.
MIT. Free and open source.