TenantLint.Analyzers 0.1.2

TenantLint

Roslyn analyzers that catch cross-tenant data leaks in multi-tenant .NET applications at build time.

The problem

In multi-tenant SaaS, the most dangerous bugs are silent: a LINQ query without a tenant filter returns data from every tenant, an IgnoreQueryFilters() call strips tenant isolation, and raw SQL bypasses global filters entirely. These bugs ship to production without a single test failure.

// This returns ALL customers across ALL tenants:
var customers = db.Customers.IgnoreQueryFilters().ToList();
//                          ^^^^^^^^^^^^^^^^^^^^ TL001

AI coding agents (Claude Code, Cursor, Copilot) write a growing share of production code. They run dotnet build constantly but have no awareness of multi-tenant invariants unless the build output tells them. TenantLint plugs into every build — in the IDE, in CI, or inside an agent's loop — and flags code that can leak one tenant's data to another.

Install

dotnet add package TenantLint.Analyzers

No configuration required. Works with plain EF Core HasQueryFilter, Finbuckle, ABP, or any hand-rolled multi-tenant setup. No base classes, no interfaces, no runtime dependency.

After updating, if your IDE still shows old diagnostics, reload the project or restart the IDE.

Quick example

Build output when TL001 fires:

SessionRepository.cs(69,28): warning TL001: 'Session' query removes the tenant
  filter via IgnoreQueryFilters(). Use IgnoreQueryFilters(["SoftDelete"]) to lift
  only the filter you need, or mark the method [CrossTenant("reason")].

The fix — lift only the non-tenant filter (EF Core 10+):

// Before (removes ALL filters, including the tenant filter):
var sessions = db.Sessions.IgnoreQueryFilters().Where(...);

// After (removes only the SoftDelete filter, tenant filter stays):
var sessions = db.Sessions.IgnoreQueryFilters(["SoftDelete"]).Where(...);

On EF Core 8/9 (no selective overload), mark the method instead:

[CrossTenant("Pre-auth: validates security stamp before tenant is known")]
public async Task<string?> GetStampAsync(Guid userId) { ... }

Rules

Query filters

Raw SQL

Request input

Lifetime and state

Framework-specific

Anti-tamper

These rules detect attempts to silently disable tenant isolation checks.

Helpers

Supported

Out of scope

• EF6 and .NET Framework — Roslyn analyzer infrastructure requires the .NET SDK.
• Database-per-tenant and schema-per-tenant — TenantLint targets shared-database (row-level) multi-tenancy where isolation comes from query filters or WHERE clauses.
• Runtime behavior — TenantLint is static analysis. It catches patterns that are likely to leak, but it cannot prove the absence of leaks. Runtime testing and code review remain necessary.

Configuration

Zero configuration required by default. Customize via .editorconfig:

[*.cs]
# Property names that identify the tenant (default: TenantId)
tenantlint.tenant_property_names = TenantId, OrganizationId, WorkspaceId

# Column names for raw SQL analysis (default: derived from property names)
tenantlint.tenant_column_names   = tenant_id, organization_id

# Entities that are never tenant-scoped (shared/global data)
tenantlint.global_entities       = Tenant, AuditLog, Country

# EF Core 10 named filter that carries tenant isolation
tenantlint.tenant_filter_name    = Tenant

# Attribute that marks intentional cross-tenant access
tenantlint.cross_tenant_attribute = CrossTenant

# DbContext bases (external) known to apply tenant filters
tenantlint.filtered_base_types   = MyCompany.Data.TenantDbContextBase

# Interfaces marking entities as tenant-scoped
tenantlint.tenant_marker_interfaces = ITenantEntity, IMustHaveTenant

Change severity per rule:

[*.cs]
dotnet_diagnostic.TL001.severity = error    # treat as build error
dotnet_diagnostic.TL005.severity = none     # disable
dotnet_diagnostic.TL111.severity = warning  # opt in to pooling warning

Intentional cross-tenant access

Mark methods that intentionally bypass tenant isolation with a [CrossTenant("reason")] attribute. TenantLint recognizes any attribute with the simple name CrossTenant in any namespace — no runtime dependency needed. Copy this into your codebase:

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, Inherited = false)]
internal sealed class CrossTenantAttribute(string reason = "") : Attribute
{
    public string Reason { get; } = reason;
}

Using TenantLint with AI coding agents

AI coding agents run dotnet build on every iteration. TenantLint warnings appear in build output, giving the agent immediate feedback when it writes code that can leak tenant data. No MCP server setup is required.

Add this to your project's agent instructions file (CLAUDE.md, AGENTS.md, .cursorrules, .github/copilot-instructions.md):

Treat TLxxx diagnostics as errors; never suppress them without a
[CrossTenant("reason")] attribute. When TenantLint reports a warning,
fix the root cause — do not disable the rule.

The anti-tamper rules (TL201, TL202, TL203) catch attempts to silently suppress tenant checks — whether by a human or by an agent that decides #pragma warning disable is easier than fixing the issue.

Code fixes

Caution — Fix All: "Fix All in Project/Solution" changes runtime behavior. Review each site first. Mark intentional cross-tenant methods with [CrossTenant("reason")] before applying the fix to the rest.

Validation

Tested against 6 open-source multi-tenant .NET projects across three rounds of validation.

Round 1 (3 projects, initial implementation): 18 diagnostics, 8 TP, 10 FP — 56% false positive rate. All FPs were from framework-managed filters invisible to static analysis (ABP, Finbuckle).

Round 2 (same 3 projects, after adding Finbuckle/ABP recognition and expanded entity discovery): 11 diagnostics, 11 TP, 0 FP — 0% false positive rate.

Round 3 (all 6 projects, all rules): 15 diagnostics, 14 TP, 1 FP — 6.7% false positive rate.

The single false positive is a TL007 heuristic match on an immutable static DTO default field in a class named TenantThemeDto.

Three of the six projects were used to guide development (Rounds 1-2). The other three were held out until all rules were implemented, then re-run after fixing two detection gaps they revealed (dynamic filter recognition and Request.Query.TryGetValue() coverage). Two of the three held-out projects are small single-DbContext demos.

Full results: docs/validation/.

How is this different from...

Vision

TenantLint is the start of a compile-time safety layer for multi-tenant .NET applications. As AI agents write more production code, analyzers that run on every build are the most natural feedback loop — they require no setup from the agent and integrate with every .NET tool from Visual Studio to CI pipelines. Tenant isolation is the starting point because a single missing filter can expose every customer's data.

Contributing

See CONTRIBUTING.md.

Security

See SECURITY.md. No third-party vulnerabilities were found during validation.

Sample app

The samples/SampleSaaS project demonstrates one violation per rule. Build it to see TenantLint in action:

dotnet build samples/SampleSaaS/SampleSaaS.csproj

License

MIT — Ibrahim Kılıç