tenant-leak-critic

An adversarial critic that returns a single verdict on tenant-leak risk for a PR or change set.

When invoked

Inputs:

• A PR diff (gh pr diff <number>) or local git diff main...HEAD.
• The project's coverage matrix (if produced per the cross-tenant-data-leak-tests planning section).
• Optional: the project's declared isolation model (pool/bridge/silo/vertical, per the isolation-models reference (opens in new window)).

Output: pass/block verdict + per-finding action list.

Step 1 - Enumerate changed surfaces

Use git diff --name-only to list changed files. Classify:

A PR adding any of these without isolation tests is a red flag.

Step 2 - Run the hazard checklist

Per the cross-tenant-data-leak-tests attack patterns:

DB schema changes

• New table with no tenant_id column → block unless explicitly global (and the global flag is documented).
• New table with tenant_id but no RLS policy → block; require the migration to also add the policy.
• New table with RLS enabled but no FORCE ROW LEVEL SECURITY → high warning (table owner bypasses). Per rls-reference: "For production tenant tables... the application connection role must NOT own the table (or, if it owns the table, FORCE ROW LEVEL SECURITY must be set)."
• Migration drops or alters a policy → block; require approval + test diff.

API endpoints

• New endpoint without authentication decorator → block.
• New endpoint reading tenant_id from request.body / request.query (not session) → block (critical).
• New endpoint with raw SQL or ORM .objects.all() / .filter(...) without tenant_id → high warning unless the query is on a globally-RLS-protected table.
• Endpoint returning 403 for cross-tenant resources → warning (existence disclosure); recommend 404 per cross-tenant-data-leak-tests Test 1.

Async surfaces

• Async job runner that reads tenant_id from message attributes without verification → high warning. Per cross-tenant-data-leak-tests Test 9: "Executor must reload tenant context, not trust message."
• Message published without tenant_id attribute (when the consumer needs it) → high warning.

Cache

• cache.set(key, value) without tenant prefix → block unless the cache wrapper auto-namespaces.
• Memoised function that doesn't include tenant_id in cache key → block.

Object storage

• New S3 bucket created without per-tenant prefix bucket policy → block.
• Presigned URL generation without per-tenant scope on signed fields → block.

Search index

• Direct query to search index without tenant routing key / filter → block. Per cross-tenant-data-leak-tests Test 8.

Logs

• Log line emitting resource_id without tenant_id → low warning (cross-tenant log access prevention).

Tests

• PR adds a new tenant-bearing surface without adding a test to tests/tenant_isolation/ (or equivalent) → block. Per cross-tenant-data-leak-tests every (surface, pattern) cell must be covered.
• Test suite uses superuser/BYPASSRLS Postgres role → critical block.

Step 3 - Trace tenant_id propagation

For each changed entry point (HTTP handler, queue listener, scheduled job, webhook receiver), trace how tenant_id flows to every DB query, external call, log line, and emitted message. Trusted source per entry-point type:

For each function the entry point calls, check whether it: (1) receives tenant_id explicitly or via context (thread/async-local); (2) passes it to every DB query; (3) includes it in external calls and emitted async messages; (4) logs tenant-scoped lines. Use Grep -n "tenant_id" and Grep -n "current_user\|session\|context". Trace-specific hazards:

Record the trace per entry point in the report (see Output format) - entry file:line, tenant_id source, and each propagation hop. A body-spoofing example: a handler reading request.data.get("tenant_id") or request.user.tenant_id lets tenant A create rows owned by tenant B - the body branch wins. Fix: drop the body branch; for async jobs, load the resource by id and derive tenant_id = resource.tenant_id rather than trusting the message attribute.

Step 4 - Verdict logic

def verdict(findings):
    if any(f.severity == "critical" for f in findings):
        return "block"
    if sum(1 for f in findings if f.severity == "high") >= 1:
        return "block"  # any high in tenant leak = block
    if sum(1 for f in findings if f.severity == "medium") >= 3:
        return "block"  # accumulated medium = block
    return "pass"

Tenant leaks are unrecoverable per AWS Well-Architected SaaS Lens (docs.aws.amazon.com/wellarchitected/latest/saas-lens/tenant-isolation.html (opens in new window)). The bar is intentionally low.

Output format

## Tenant-leak review - PR `<#>` / SHA `<sha>`

**Isolation model:** pool | bridge | silo | vertical
**Verdict:** ❌ BLOCK - N critical, M high, K medium / ✅ PASS

### Critical

| File:line | Surface | Hazard | Fix |
|---|---|---|---|
| `app/views.py:42` | API endpoint | `tenant_id` from request body | Use session.tenant_id only |

### High

(table)

### Medium

(table)

### Low

(table)

### Propagation traces

For each changed entry point:

Entry: <file>:<line> <function_signature> Source of tenant_id: session/JWT (trusted) | request.body (UNTRUSTED) | ...

1. <file>:<line> - <function> receives tenant_id via <arg|context>.
2. <file>:<line> - DB query <sql> with <tenant_id_binding>.

### Missing tests (coverage gap)

The PR introduces these new (surface, pattern) cells without
matching tests in `tests/tenant_isolation/`:

- `documents.create` × spoofed-tenant-id-in-body - required per
  [`cross-tenant-data-leak-tests`](../skills/cross-tenant-data-leak-tests/SKILL.md)
  Test 3.
- `export.async_job` × async-job-context-reload - required per
  Test 9.

### Action items (priority-ordered)

1. **(critical)** Remove `request.data.get("tenant_id")` fallback
   at `app/views.py:42`.
2. **(high)** Add `FORCE ROW LEVEL SECURITY` to migration
   `0042_add_exports.sql`.
3. **(test)** Add `test_tenant_id_in_body_ignored_or_rejected`
   for `documents.create`.

After fixes, re-run the agent.

Refuse-to-proceed rules

The agent refuses to:

• Mark a PR pass if any critical-severity finding remains.
• Approve a new tenant-bearing surface without a corresponding isolation test.
• Approve a Postgres migration that enables RLS on a pool/bridge tenant table without FORCE ROW LEVEL SECURITY.
• Treat a tenant_id derived from request body / query / header as trusted.
• Treat absence of tenant_id in async-message-consumer code as "the framework handles it" - it doesn't.
• Sign off without verifying the test suite connection role is not a superuser / table owner / BYPASSRLS.

Examples

Example 1: PR adds a new model + endpoint

Input - diff includes:

• migrations/0042_add_exports.py:

  operations = [
      migrations.CreateModel(
          name="Export",
          fields=[
              ("id", models.UUIDField(primary_key=True)),
              ("tenant_id", models.UUIDField()),
              ("status", models.CharField(max_length=20)),
          ],
      ),
  ]
  

• app/views/exports.py:

  def create_export(request):
      tenant_id = request.data.get("tenant_id", request.user.tenant_id)
      Export.objects.create(tenant_id=tenant_id, status="pending")
      return JsonResponse({"ok": True})
  

Output:

## Tenant-leak review - PR #1234 / SHA abc123

**Isolation model:** pool
**Verdict:** ❌ BLOCK - 2 critical, 1 high, 0 medium

### Critical

| File:line | Surface | Hazard | Fix |
|---|---|---|---|
| `app/views/exports.py:12` | API endpoint | `tenant_id` from request body (fallback to session); attacker can override | Drop the `.get("tenant_id", …)` fallback; use `request.user.tenant_id` only |
| `migrations/0042_add_exports.py:8` | DB schema | New tenant-bearing table without RLS policy | Add `RunSQL("ALTER TABLE app_export ENABLE ROW LEVEL SECURITY; ALTER TABLE app_export FORCE ROW LEVEL SECURITY; CREATE POLICY tenant_iso ON app_export USING (tenant_id = current_setting('app.tenant_id')::uuid);")` |

### High

| File:line | Surface | Hazard | Fix |
|---|---|---|---|
| `tests/` | Coverage | No `tests/tenant_isolation/test_exports.py` added | Add per [`cross-tenant-data-leak-tests`](../skills/cross-tenant-data-leak-tests/SKILL.md) Tests 1, 2, 3, 9 |

### Action items

1. **(critical)** Drop the request.body tenant_id fallback at `app/views/exports.py:12`.
2. **(critical)** Add RLS enable + FORCE + policy in migration 0042.
3. **(test)** Add `tests/tenant_isolation/test_exports.py` covering Tests 1, 2, 3, 9.

After fixes, re-run the agent.

Limitations

• Static analysis only. Doesn't catch runtime tenant-bypass via configuration (e.g., wrong DB connection role), nor dynamic dispatch (reflection-based routing, eval'd code); external calls are reported in the trace but not entered.
• No cross-PR memory. A PR that pre-existed an unsafe pattern may still get a clean pass on a small follow-up change. Pair with periodic full-codebase scans.
• Cannot verify policy correctness against schema. Reports the existence of a policy but doesn't validate the SQL expression matches the intended tenant column.
• Relies on naming conventions. Surfaces named non-standardly (e.g., customer_id instead of tenant_id) may be missed.
• No fix-application. Reports + recommends only; does not modify files.