Explore our comprehensive resources on behavioral AI monitoring, compliance frameworks, and policy templates.
Start your compliance journey with HAIEC. Free assessment, automated evidence, audit-ready documentation.
Explore compliance frameworks:
Developer tools & integrations:
Learn what AI vendor public security disclosures entail and how they impact AI security and compliance professionals.
Discover the essential questions to include in an AI vendor security questionnaire to ensure robust security and compliance in AI procurement.
Every organization has a different regulatory mix. A healthcare AI company in New York needs different compliance rules than a fintech in Colorado. Here is why modular audit engine composition changes the game.
General-purpose security scanners catch SQL injection and XSS. They do not check whether your Prisma findMany includes an organizationId filter. They do not check whether your MCP tool handler scopes tool visibility by tenant.
If you build multi-tenant software, every query, every cache key, every file access needs to be scoped to the right tenant. Miss one, and Tenant A sees Tenant B's data.
This is not a hypothetical. Cross-tenant data leakage is one of the most common and most damaging vulnerabilities in multi-tenant SaaS. It happens because tenant context is easy to forget in one code path, one async boundary, one error handler.
The gap between "we have tenant isolation" and "we can prove every code path enforces it" is where the problem lives.
mcp-tenant-isolation 2.0.0 is a major version. It upgrades to the MCP v2 SDK, adds security boundary enforcement, structured scan output, evidence receipts, and npm Trusted Publishing with provenance attestations.
Here is what is new:
--allow-write-tools for suppression)Provenance does not mean "trust us." It means "verify us."
When you install mcp-tenant-isolation@2.0.0, npm includes a signed provenance statement in the sigstore transparency log. This statement cryptographically links the published package to the exact GitHub Actions workflow, commit hash, and build environment that produced it.
You can verify that the package was built from the source code in the repository. No long-lived tokens. No manual trust. Cryptographic proof.
npm view mcp-tenant-isolation@2.0.0 dist.attestations
This is the OpenSSF trusted publishing standard. PyPI uses it. RubyGems uses it. Now npm uses it. And mcp-tenant-isolation uses it.
The old way: store an npm token in GitHub secrets. Rotate it. Hope it doesn't leak. Hope it doesn't get exfiltrated. Hope the 2FA bypass token doesn't trigger an OTP error in CI.
The new way: npm trusts a specific GitHub Actions workflow via OIDC. Each publish uses a short-lived, workflow-specific credential. It cannot be exfiltrated. It cannot be reused. It expires in minutes.
This is not a feature. This is supply chain hygiene.
The MCP server now enforces path boundaries on all filesystem operations. This is the architecture, not a feature.
The PathBoundary class enforces:
../ sequences that escape the project root are rejectedrealpath\\server\share paths are rejected on WindowsWhen an AI agent calls scan_tenant_isolation, it cannot access files outside the configured project root. The boundary is enforced at the path resolution layer, not at the application layer.
The MCP server is read-only by default. Three tools are always available:
scan_tenant_isolation — read-only scanlist_tenant_isolation_rules — read-only rule listingexplain_tenant_isolation_rule — read-only rule detailsThe suppression tool (suppress_tenant_isolation_finding) is only registered when the server is started with --allow-write-tools. Without that flag, the write tool does not exist in the MCP tool list.
This means: an AI agent connected to a default MCP server cannot suppress findings, modify baselines, or write any files through the MCP interface.
57 deterministic rules across 8 categories:
| Category | Rules | Severity | |----------|-------|----------| | Tenant Context Management | 6 | Critical | | Database Query Isolation | 10 | Critical | | IDOR Prevention | 5 | Critical | | Cache and Session Isolation | 4 | High | | API Security | 3 | High | | File Storage Isolation | 4 | High | | Logging and Audit | 4 | Medium | | Schema and Migration | 6 | High |
Plus 15 MCP-specific rules covering tool visibility, cache key tenant prefixes, session binding, token exchange, vector store namespaces, credential vault scoping, and more.
Same code + same rules = same findings. No machine learning. No probabilistic scoring. No hallucination.
mcp-tenant-isolation and ai-appsec are complementary, not competing.
mcp-tenant-isolation checks tenant boundaries. It answers: "Does every database query, cache key, file access, and MCP tool handler scope to the correct tenant?"
ai-appsec checks AI application source code security. It answers: "Does this code have prompt injection, tool abuse, SSRF, or dangerous eval patterns?"
Use both. They check different things. They are independent engines. A tenant-isolation request calls the tenant-isolation engine only. A source-security request calls the AI AppSec engine only.
This is the architecture, not a feature.
# npm
npm install -g mcp-tenant-isolation
npx mcp-tenant-isolation scan ./src
# Docker
docker run --rm -v $(pwd):/code subodhkc/mcp-tenant-isolation scan /code/src
Add to your Claude Desktop, Cursor, or Windsurf config:
{
"mcpServers": {
"tenant-isolation": {
"command": "npx",
"args": ["-y", "mcp-tenant-isolation", "mcp"]
}
}
}
Static analysis has limits. Being upfront about them:
.mtirc.json and suppression files.Last reviewed: 2026-08-21