Tenant isolation: keeping your RTL separate

RTL is among the most sensitive assets a hardware team owns, so a multi-tenant verification platform has to keep each tenant’s designs and results strictly separate. ChipVerify AI does this at two layers: a request-scoped tenant context in the application that every tenant-scoped query filters by, and a defense-in-depth PostgreSQL row-level security layer that enforces the same rule inside the database itself. This page explains how both work and where the guarantee comes from.

Layer one: request-scoped tenant context

Every tenant-scoped record carries a tenant id. At the start of a request, the platform resolves the tenant from the authenticated token and binds it into a request-scoped context. That context is built on a primitive (contextvars.ContextVar) that scopes correctly across async boundaries, so two requests handled concurrently in the same process never see each other’s tenant. Every database read and write that touches tenant data resolves its tenant through that single context and filters by it. The on-prem single-tenant deploy uses the same code path against one default tenant, so cloud and self-host share one mechanism.

Layer two: PostgreSQL row-level security

Application-level filtering is correct only as long as every query remembers to apply it. Row-level security (RLS) moves the guarantee below the application, into PostgreSQL. At the start of each transaction, the platform binds the request’s tenant id onto the connection as a transaction-local setting; a row-level-security policy on each tenant-scoped table then returns only the rows whose tenant id matches that setting. A query that forgot to filter still cannot read another tenant’s rows, because the database refuses to return them.

-- Defense-in-depth: PostgreSQL row-level security enforces tenant
-- isolation in the database itself, below the application layer.
-- At the start of every transaction the app binds the request's tenant:
--   SELECT set_config('app.current_tenant', '<tenant-uuid>', true);  -- LOCAL
--   SELECT set_config('app.cross_tenant',   'off',           true);  -- admin only

-- The policy then returns ONLY rows for the active tenant, unless an
-- explicit, audited cross-tenant (admin/ops) mode is on:
CREATE POLICY tenant_isolation ON jobs
  USING (
    current_setting('app.cross_tenant', true) = 'on'
    OR tenant_id = current_setting('app.current_tenant', true)
  );

-- set_config(..., is_local := true) is the injection-safe, transaction-
-- scoped equivalent of SET LOCAL: it cannot leak across requests.

The tenant id is bound with set_config(…, is_local := true), the injection-safe, transaction-scoped equivalent of SET LOCAL — it cannot leak across requests. Cross-tenant access for admin and operations is a separate, explicit, audited mode, not the default path.

Why two layers

The two layers are defense-in-depth: the application filter is the fast, common path, and RLS is the backstop that holds even if an application query is written wrong. A single layer is a single point of failure — one missing WHERE tenant_id = … would be enough to leak data. With RLS underneath, the database itself is the final arbiter of which rows a tenant can see, which is the right place for a confidentiality guarantee about customer RTL to live.

What about the RTL itself

ChipVerify AI’s analysis is deterministic and runs on open EDA engines — the structural analyzers do not hand your RTL to a third-party model. The product surface ships with AI features off, so those analyzers do not transmit RTL snippets anywhere. Tenant isolation then governs how your uploaded RTL and the evidence ChipVerify produces from it are stored and queried inside the platform. The combination — deterministic engines plus two-layer tenant isolation — is what keeps one team’s design out of another team’s view.

How ChipVerify AI helps

ChipVerify AI (a pre-signoff RTL evidence tool, currently in closed beta) runs its analyzers on RTL that stays isolated to your tenant at both the application and database layers. The same architecture serves the multi-tenant cloud and the single-tenant on-prem deploy, so you can adopt the cloud and move to self-host without changing how isolation works.

Related reading

• RTL verification guide — what the platform actually runs on your isolated RTL.
• Verification waivers — the same audit-trail discipline applied to findings.
• Tapeout readiness — the closure dashboard your isolated results roll up into.

Try the public scanner at /tinytapeout or request access.

FAQ