One table that sees every company, on purpose

In a system where every table is scoped to a company, the membership table can’t be. That’s not a leak: it’s the feature.

A user can belong to more than one company. To resolve a login and offer the list to choose from, something has to read across companies before there’s a company in context. The table linking users to companies is deliberately outside the isolation rule.

Legitimate exceptions are more dangerous than plain bugs

For two reasons that pull in opposite directions.

If the exception isn’t documented, the next person auditing tenancy finds a query with no company filter and either “fixes” it — breaking multi-company login in a way that shows up at the worst possible moment — or, worse, sees that unfiltered queries exist and are apparently fine, and stops treating the rule as absolute.

Every exception, written next to the code

Why it’s global, what it must never return, and what protects it instead. Because something has to protect it: in this case, the read is scoped by the authenticated user — it returns only that user’s memberships, and nothing about the companies beyond what’s needed to choose.

The other exceptions in our system have the same shape: a numbering sequence with a system-wide unique constraint, a few super-admin views. Each one written down.

A rule is known by its exceptions

A security rule with undocumented exceptions decays into a suggestion. The exceptions are where you find out whether the rule is understood or merely followed.

In YSY Empresa, our multi-tenant ERP, isolation is audited module by module — and the exception register is part of the deliverable, not a mental note.