Standard linters only check if RLS is enabled. TenantShield inspects catalog grants, table ownership, and JWT claim usage, then runs access checks against configured tenant fixtures on disposable databases. Commercial contracts let you compare observed access with the behavior your app intends.
-- Current session execution credentials
SET LOCAL ROLE postgres; /* Table Owner */
-- FORCE ROW LEVEL SECURITY not set: owner bypasses pg_policy
SELECT id, tenant_id, customer_email, amount, status
FROM public.invoices ORDER BY id ASC;ALTER TABLE invoices FORCE RLS;
Most teams assume running
ALTER TABLE ... ENABLE ROW LEVEL SECURITY;
guarantees tenant isolation. In reality, standard static linters only check if that
single binary flag is on. They completely miss role inheritance traps, table owner
privileges, and unverified client tokens:
By default in PostgreSQL, the table owner role bypasses all RLS policies entirely.
If your API backend connects under an owner or migration role without
FORCE ROW LEVEL SECURITY, all tenant
filters are silently ignored in production.
Many online tutorials advise checking
user_metadata in Supabase JWTs.
However, users can modify their own
user_metadata via the public client
API, granting themselves administrative tenant rights without backend
authorization.
A policy might forbid Tenant B from reading Tenant A's row, but fail to enforce a
WITH CHECK constraint on writes.
Tenant B reassigns
tenant_id = 'tenant_b', seizing the
record permanently without generating a read warning.
TenantShield connects to a local or disposable database, audits internal system
catalogs (pg_catalog), and runs
transaction-isolated access attacks. Row mutations roll back automatically; sequences
and external triggers do not.
Queries internal catalogs (pg_class, pg_policy,
pg_roles) to map effective
permissions across anon and
authenticated roles, including
inherited role grants.
Dynamic tests default strictly to local instances (localhost
/ 127.0.0.1). Remote targets
require explicit configuration allow-lists to protect live production
environments.
Forks transactions with isolated savepoints and
SET CONSTRAINTS ALL IMMEDIATE.
Uses configured tenant fixtures to exercise cross-tenant SELECT, INSERT, UPDATE,
and DELETE behavior in both directions. Missing fixtures and setup failures
remain inconclusive instead of counting as authorization denials.
Exports findings as SARIF 2.1.0 and standalone HTML for technical review. Reports describe the configured and tested scope; they do not certify compliance.
TenantShield checks PostgreSQL internal privileges, RLS policies, functions, storage buckets, query execution performance, and bidirectional row operations.
The local stdio MCP server exposes PostgreSQL catalog inspection, migration safety checks, and tenant access simulation directly to AI coding assistants. Keep dynamic tests on disposable databases.
{
"mcpServers": {
"tenantshield": {
"command": "npx",
"args": ["--yes", "tenantshield-mcp"],
"env": { "TENANTSHIELD_DATABASE_URL": "postgresql://user:pass@127.0.0.1:54322/db" }
}
}
}claude mcp add tenantshield -- npx --yes tenantshield-mcpPaddle confirms each purchase through the TenantShield webhook, which emails the signed license key. Live checkout is controlled by a server-side release flag.
Community
Open-source PostgreSQL and Supabase isolation checks for local development and CI.
Single Developer
Define the tenant access your app intends, compare it across two disposable database revisions, and trace an unexpected result to a replayable case.
Agencies & Small Teams
Review saved test results across client projects and prepare a clear record of which access cases were tested.
$ tenantshield-commercial rehearse --contract tenantshield.contract.yaml \
--base-config base.yaml --head-config head.yaml
PERMISSION_REGRESSION invoices:viewer:delete:same_tenant (DENY -> ALLOWED)
INTENDED_ACCESS_BROKEN invoices:owner:insert:same_tenant (ALLOW -> DENIED)
UNREVIEWED_WEAKENING none | Can Merge Pull Request: NO (BLOCKED)
$ tenantshield-commercial replay invoices:viewer:delete:same_tenant
-> Rollback probe + AI fix prompt + MCP simulate_tenant_access payload$ tenantshield-commercial portfolio --registry portfolio.yaml
[HIGH] core-billing (client-a): default HEAD abc1234 != tested 9f01e2b (STALE)
[HIGH] portal-api (client-b): 1 expiring exception & missing viewer rules
$ tenantshield-commercial evidence --client client-a --strict --output report.html
-> White-label HTML + JSON bundle with config/contract SHA-256 & CC6.1 scopetenantshield and
tenantshield-mcp are published on npm. Their 0.1.0
releases use MIT; releases from 0.2.0 onward use Apache-2.0. Paddle's signed
transaction.completed webhook delivers the license key. The commercial CLI
will ship as a private GHCR image; registry access is granted separately from the
license. Live checkout remains gated until image delivery and runner acceptance are
ready. The free core remains available without a commercial license.
Review our Terms, Privacy Notice, and Refund Policy for the policies that will apply when commercial access opens.
TenantShield rolls back row mutations within test savepoints, but sequence counters advance and external triggers may execute side effects. Always test against ephemeral or local databases, never live production instances.