[2c] Org isolation enforcement

[andrmaz]

What changed

Org-scoped filtering is now enforced at the Prisma query layer for every request, not just opted into per controller.

• db's new org-scope module: an AsyncLocalStorage-backed org context plus a Prisma Client Extension (createOrgScopedClient) that automatically injects/forces organizationId filters (or the equivalent relation filter for join/child models) on every model operation — reads, creates, updates, deletes. Any query made with no active org context throws MissingOrgContextError (fail closed). A deliberate runWithoutOrgScope escape hatch exists for the one legitimate pre-auth path (resolving a user's org during login).
• PrismaService no longer extends PrismaClient; every model delegate it exposes is routed through the org-scoped client, and the raw client has no external accessor — there is no way to bypass scoping from application code.
• OrgContextInterceptor (global, via APP_INTERCEPTOR) binds the authenticated caller's organizationId as the active context for the whole request, so controllers/services don't need to remember to filter by org themselves.
• OrgScopeExceptionFilter maps a query-layer OrgScopeViolationError (a write referencing a foreign-org record) to 403.
• Fixed a real cross-org leak: OrganizationsController had zero org scoping — any admin could list every organization, fetch any organization by id, and rename any organization. It now behaves like the existing DepartmentsController/AdminUsersController convention (403 on a mismatched id; list returns only the caller's own org).
• Wired @prisma/adapter-pg into PrismaService (Prisma 7 requires a driver adapter), incidentally fixing a previously-documented boot gap.

Why this design

Building this as an opt-in per-controller check (the existing pattern) is exactly what let OrganizationsController slip through with no scoping at all. The Prisma extension makes scoping mandatory at the query layer regardless of whether a given service author remembers to filter — new models must be registered in ORG_SCOPE_CONFIG or all queries against them fail closed.

Testing

• 61 new unit tests in packages/db covering the pure scoping logic and the extension itself (via a lightweight fake client that faithfully reproduces Prisma's $extends contract) — no live DB required.
• New/updated integration tests in apps/api (interceptor wiring, exception filter, organizations cross-org 403s, MCP cross-org isolation and concurrency).
• Manual end-to-end verification against a real local Postgres (seeded two orgs, confirmed cross-org reads never leak, cross-org writes are rejected with OrgScopeViolationError, $transaction batches stay correctly scoped, and no-context queries fail closed). This caught two real bugs the unit tests alone would have missed:
  • Prisma's client methods return a lazy promise that only registers its .then() reaction when awaited — a runWithOrgContext/runWithoutOrgScope callback that just returns that lazy promise (instead of being async and consuming it) silently loses the bound context. Documented on runWithOrgContext and fixed the one real call site that had this bug (UserService.findByGoogleSub).
  • Prisma's WhereUniqueInput (used by findUnique/update/delete/upsert) requires the unique identifier to stay a direct top-level field — wrapping it in AND fails validation. Added a separate flat-merge strategy (mergeUniqueWhere) for these operations.
• Full monorepo pnpm test / pnpm check-types / pnpm lint all pass.

Acceptance criteria

• A middleware/helper enforces org-scoped filtering on all DB queries.
• Attempting to read another org's data via API returns 403/404.
• MCP calls are also org-scoped — no cross-org leakage through the MCP path.
• Integration tests verify isolation for both API and MCP paths.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
auto_review:
drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[andrmaz]

What changed

Org-scoped filtering is now enforced at the Prisma query layer for every request, not just opted into per controller.

• db's new org-scope module: an AsyncLocalStorage-backed org context plus a Prisma Client Extension (createOrgScopedClient) that automatically injects/forces organizationId filters (or the equivalent relation filter for join/child models) on every model operation — reads, creates, updates, deletes. Any query made with no active org context throws MissingOrgContextError (fail closed). A deliberate runWithoutOrgScope escape hatch exists for the one legitimate pre-auth path (resolving a user's org during login).
• PrismaService no longer extends PrismaClient; every model delegate it exposes is routed through the org-scoped client, and the raw client has no external accessor — there is no way to bypass scoping from application code.
• OrgContextInterceptor (global, via APP_INTERCEPTOR) binds the authenticated caller's organizationId as the active context for the whole request, so controllers/services don't need to remember to filter by org themselves.
• OrgScopeExceptionFilter maps a query-layer OrgScopeViolationError (a write referencing a foreign-org record) to 403.
• Fixed a real cross-org leak: OrganizationsController had zero org scoping — any admin could list every organization, fetch any organization by id, and rename any organization. It now behaves like the existing DepartmentsController/AdminUsersController convention (403 on a mismatched id; list returns only the caller's own org).
• Wired @prisma/adapter-pg into PrismaService (Prisma 7 requires a driver adapter), incidentally fixing a previously-documented boot gap.

Why this design

Building this as an opt-in per-controller check (the existing pattern) is exactly what let OrganizationsController slip through with no scoping at all. The Prisma extension makes scoping mandatory at the query layer regardless of whether a given service author remembers to filter — new models must be registered in ORG_SCOPE_CONFIG or all queries against them fail closed.

Testing

• 61 new unit tests in packages/db covering the pure scoping logic and the extension itself (via a lightweight fake client that faithfully reproduces Prisma's $extends contract) — no live DB required.
• New/updated integration tests in apps/api (interceptor wiring, exception filter, organizations cross-org 403s, MCP cross-org isolation and concurrency).
• Manual end-to-end verification against a real local Postgres (seeded two orgs, confirmed cross-org reads never leak, cross-org writes are rejected with OrgScopeViolationError, $transaction batches stay correctly scoped, and no-context queries fail closed). This caught two real bugs the unit tests alone would have missed:
  • Prisma's client methods return a lazy promise that only registers its .then() reaction when awaited — a runWithOrgContext/runWithoutOrgScope callback that just returns that lazy promise (instead of being async and consuming it) silently loses the bound context. Documented on runWithOrgContext and fixed the one real call site that had this bug (UserService.findByGoogleSub).
  • Prisma's WhereUniqueInput (used by findUnique/update/delete/upsert) requires the unique identifier to stay a direct top-level field — wrapping it in AND fails validation. Added a separate flat-merge strategy (mergeUniqueWhere) for these operations.
• Full monorepo pnpm test / pnpm check-types / pnpm lint all pass.

Acceptance criteria

• A middleware/helper enforces org-scoped filtering on all DB queries.
• Attempting to read another org's data via API returns 403/404.
• MCP calls are also org-scoped — no cross-org leakage through the MCP path.
• Integration tests verify isolation for both API and MCP paths.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
auto_review:
drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[andrmaz]

What changed

Org-scoped filtering is now enforced at the Prisma query layer for every request, not just opted into per controller.

• db's new org-scope module: an AsyncLocalStorage-backed org context plus a Prisma Client Extension (createOrgScopedClient) that automatically injects/forces organizationId filters (or the equivalent relation filter for join/child models) on every model operation — reads, creates, updates, deletes. Any query made with no active org context throws MissingOrgContextError (fail closed). A deliberate runWithoutOrgScope escape hatch exists for the one legitimate pre-auth path (resolving a user's org during login).
• PrismaService no longer extends PrismaClient; every model delegate it exposes is routed through the org-scoped client, and the raw client has no external accessor — there is no way to bypass scoping from application code.
• OrgContextInterceptor (global, via APP_INTERCEPTOR) binds the authenticated caller's organizationId as the active context for the whole request, so controllers/services don't need to remember to filter by org themselves.
• OrgScopeExceptionFilter maps a query-layer OrgScopeViolationError (a write referencing a foreign-org record) to 403.
• Fixed a real cross-org leak: OrganizationsController had zero org scoping — any admin could list every organization, fetch any organization by id, and rename any organization. It now behaves like the existing DepartmentsController/AdminUsersController convention (403 on a mismatched id; list returns only the caller's own org).
• Wired @prisma/adapter-pg into PrismaService (Prisma 7 requires a driver adapter), incidentally fixing a previously-documented boot gap.

Why this design

Building this as an opt-in per-controller check (the existing pattern) is exactly what let OrganizationsController slip through with no scoping at all. The Prisma extension makes scoping mandatory at the query layer regardless of whether a given service author remembers to filter — new models must be registered in ORG_SCOPE_CONFIG or all queries against them fail closed.

Testing

• 61 new unit tests in packages/db covering the pure scoping logic and the extension itself (via a lightweight fake client that faithfully reproduces Prisma's $extends contract) — no live DB required.
• New/updated integration tests in apps/api (interceptor wiring, exception filter, organizations cross-org 403s, MCP cross-org isolation and concurrency).
• Manual end-to-end verification against a real local Postgres (seeded two orgs, confirmed cross-org reads never leak, cross-org writes are rejected with OrgScopeViolationError, $transaction batches stay correctly scoped, and no-context queries fail closed). This caught two real bugs the unit tests alone would have missed:
  • Prisma's client methods return a lazy promise that only registers its .then() reaction when awaited — a runWithOrgContext/runWithoutOrgScope callback that just returns that lazy promise (instead of being async and consuming it) silently loses the bound context. Documented on runWithOrgContext and fixed the one real call site that had this bug (UserService.findByGoogleSub).
  • Prisma's WhereUniqueInput (used by findUnique/update/delete/upsert) requires the unique identifier to stay a direct top-level field — wrapping it in AND fails validation. Added a separate flat-merge strategy (mergeUniqueWhere) for these operations.
• Full monorepo pnpm test / pnpm check-types / pnpm lint all pass.

Acceptance criteria

• A middleware/helper enforces org-scoped filtering on all DB queries.
• Attempting to read another org's data via API returns 403/404.
• MCP calls are also org-scoped — no cross-org leakage through the MCP path.
• Integration tests verify isolation for both API and MCP paths.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
auto_review:
drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[andrmaz]

What changed

Org-scoped filtering is now enforced at the Prisma query layer for every request, not just opted into per controller.

• db's new org-scope module: an AsyncLocalStorage-backed org context plus a Prisma Client Extension (createOrgScopedClient) that automatically injects/forces organizationId filters (or the equivalent relation filter for join/child models) on every model operation — reads, creates, updates, deletes. Any query made with no active org context throws MissingOrgContextError (fail closed). A deliberate runWithoutOrgScope escape hatch exists for the one legitimate pre-auth path (resolving a user's org during login).
• PrismaService no longer extends PrismaClient; every model delegate it exposes is routed through the org-scoped client, and the raw client has no external accessor — there is no way to bypass scoping from application code.
• OrgContextInterceptor (global, via APP_INTERCEPTOR) binds the authenticated caller's organizationId as the active context for the whole request, so controllers/services don't need to remember to filter by org themselves.
• OrgScopeExceptionFilter maps a query-layer OrgScopeViolationError (a write referencing a foreign-org record) to 403.
• Fixed a real cross-org leak: OrganizationsController had zero org scoping — any admin could list every organization, fetch any organization by id, and rename any organization. It now behaves like the existing DepartmentsController/AdminUsersController convention (403 on a mismatched id; list returns only the caller's own org).
• Wired @prisma/adapter-pg into PrismaService (Prisma 7 requires a driver adapter), incidentally fixing a previously-documented boot gap.

Why this design

Building this as an opt-in per-controller check (the existing pattern) is exactly what let OrganizationsController slip through with no scoping at all. The Prisma extension makes scoping mandatory at the query layer regardless of whether a given service author remembers to filter — new models must be registered in ORG_SCOPE_CONFIG or all queries against them fail closed.

Testing

• 61 new unit tests in packages/db covering the pure scoping logic and the extension itself (via a lightweight fake client that faithfully reproduces Prisma's $extends contract) — no live DB required.
• New/updated integration tests in apps/api (interceptor wiring, exception filter, organizations cross-org 403s, MCP cross-org isolation and concurrency).
• Manual end-to-end verification against a real local Postgres (seeded two orgs, confirmed cross-org reads never leak, cross-org writes are rejected with OrgScopeViolationError, $transaction batches stay correctly scoped, and no-context queries fail closed). This caught two real bugs the unit tests alone would have missed:
  • Prisma's client methods return a lazy promise that only registers its .then() reaction when awaited — a runWithOrgContext/runWithoutOrgScope callback that just returns that lazy promise (instead of being async and consuming it) silently loses the bound context. Documented on runWithOrgContext and fixed the one real call site that had this bug (UserService.findByGoogleSub).
  • Prisma's WhereUniqueInput (used by findUnique/update/delete/upsert) requires the unique identifier to stay a direct top-level field — wrapping it in AND fails validation. Added a separate flat-merge strategy (mergeUniqueWhere) for these operations.
• Full monorepo pnpm test / pnpm check-types / pnpm lint all pass.

Acceptance criteria

• A middleware/helper enforces org-scoped filtering on all DB queries.
• Attempting to read another org's data via API returns 403/404.
• MCP calls are also org-scoped — no cross-org leakage through the MCP path.
• Integration tests verify isolation for both API and MCP paths.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
auto_review:
drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[andrmaz]

What changed

Org-scoped filtering is now enforced at the Prisma query layer for every request, not just opted into per controller.

• db's new org-scope module: an AsyncLocalStorage-backed org context plus a Prisma Client Extension (createOrgScopedClient) that automatically injects/forces organizationId filters (or the equivalent relation filter for join/child models) on every model operation — reads, creates, updates, deletes. Any query made with no active org context throws MissingOrgContextError (fail closed). A deliberate runWithoutOrgScope escape hatch exists for the one legitimate pre-auth path (resolving a user's org during login).
• PrismaService no longer extends PrismaClient; every model delegate it exposes is routed through the org-scoped client, and the raw client has no external accessor — there is no way to bypass scoping from application code.
• OrgContextInterceptor (global, via APP_INTERCEPTOR) binds the authenticated caller's organizationId as the active context for the whole request, so controllers/services don't need to remember to filter by org themselves.
• OrgScopeExceptionFilter maps a query-layer OrgScopeViolationError (a write referencing a foreign-org record) to 403.
• Fixed a real cross-org leak: OrganizationsController had zero org scoping — any admin could list every organization, fetch any organization by id, and rename any organization. It now behaves like the existing DepartmentsController/AdminUsersController convention (403 on a mismatched id; list returns only the caller's own org).
• Wired @prisma/adapter-pg into PrismaService (Prisma 7 requires a driver adapter), incidentally fixing a previously-documented boot gap.

Why this design

Building this as an opt-in per-controller check (the existing pattern) is exactly what let OrganizationsController slip through with no scoping at all. The Prisma extension makes scoping mandatory at the query layer regardless of whether a given service author remembers to filter — new models must be registered in ORG_SCOPE_CONFIG or all queries against them fail closed.

Testing

• 61 new unit tests in packages/db covering the pure scoping logic and the extension itself (via a lightweight fake client that faithfully reproduces Prisma's $extends contract) — no live DB required.
• New/updated integration tests in apps/api (interceptor wiring, exception filter, organizations cross-org 403s, MCP cross-org isolation and concurrency).
• Manual end-to-end verification against a real local Postgres (seeded two orgs, confirmed cross-org reads never leak, cross-org writes are rejected with OrgScopeViolationError, $transaction batches stay correctly scoped, and no-context queries fail closed). This caught two real bugs the unit tests alone would have missed:
  • Prisma's client methods return a lazy promise that only registers its .then() reaction when awaited — a runWithOrgContext/runWithoutOrgScope callback that just returns that lazy promise (instead of being async and consuming it) silently loses the bound context. Documented on runWithOrgContext and fixed the one real call site that had this bug (UserService.findByGoogleSub).
  • Prisma's WhereUniqueInput (used by findUnique/update/delete/upsert) requires the unique identifier to stay a direct top-level field — wrapping it in AND fails validation. Added a separate flat-merge strategy (mergeUniqueWhere) for these operations.
• Full monorepo pnpm test / pnpm check-types / pnpm lint all pass.

Acceptance criteria

• A middleware/helper enforces org-scoped filtering on all DB queries.
• Attempting to read another org's data via API returns 403/404.
• MCP calls are also org-scoped — no cross-org leakage through the MCP path.
• Integration tests verify isolation for both API and MCP paths.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
auto_review:
drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[andrmaz]

What changed

Org-scoped filtering is now enforced at the Prisma query layer for every request, not just opted into per controller.

• db's new org-scope module: an AsyncLocalStorage-backed org context plus a Prisma Client Extension (createOrgScopedClient) that automatically injects/forces organizationId filters (or the equivalent relation filter for join/child models) on every model operation — reads, creates, updates, deletes. Any query made with no active org context throws MissingOrgContextError (fail closed). A deliberate runWithoutOrgScope escape hatch exists for the one legitimate pre-auth path (resolving a user's org during login).
• PrismaService no longer extends PrismaClient; every model delegate it exposes is routed through the org-scoped client, and the raw client has no external accessor — there is no way to bypass scoping from application code.
• OrgContextInterceptor (global, via APP_INTERCEPTOR) binds the authenticated caller's organizationId as the active context for the whole request, so controllers/services don't need to remember to filter by org themselves.
• OrgScopeExceptionFilter maps a query-layer OrgScopeViolationError (a write referencing a foreign-org record) to 403.
• Fixed a real cross-org leak: OrganizationsController had zero org scoping — any admin could list every organization, fetch any organization by id, and rename any organization. It now behaves like the existing DepartmentsController/AdminUsersController convention (403 on a mismatched id; list returns only the caller's own org).
• Wired @prisma/adapter-pg into PrismaService (Prisma 7 requires a driver adapter), incidentally fixing a previously-documented boot gap.

Why this design

Building this as an opt-in per-controller check (the existing pattern) is exactly what let OrganizationsController slip through with no scoping at all. The Prisma extension makes scoping mandatory at the query layer regardless of whether a given service author remembers to filter — new models must be registered in ORG_SCOPE_CONFIG or all queries against them fail closed.

Testing

• 61 new unit tests in packages/db covering the pure scoping logic and the extension itself (via a lightweight fake client that faithfully reproduces Prisma's $extends contract) — no live DB required.
• New/updated integration tests in apps/api (interceptor wiring, exception filter, organizations cross-org 403s, MCP cross-org isolation and concurrency).
• Manual end-to-end verification against a real local Postgres (seeded two orgs, confirmed cross-org reads never leak, cross-org writes are rejected with OrgScopeViolationError, $transaction batches stay correctly scoped, and no-context queries fail closed). This caught two real bugs the unit tests alone would have missed:
  • Prisma's client methods return a lazy promise that only registers its .then() reaction when awaited — a runWithOrgContext/runWithoutOrgScope callback that just returns that lazy promise (instead of being async and consuming it) silently loses the bound context. Documented on runWithOrgContext and fixed the one real call site that had this bug (UserService.findByGoogleSub).
  • Prisma's WhereUniqueInput (used by findUnique/update/delete/upsert) requires the unique identifier to stay a direct top-level field — wrapping it in AND fails validation. Added a separate flat-merge strategy (mergeUniqueWhere) for these operations.
• Full monorepo pnpm test / pnpm check-types / pnpm lint all pass.

Acceptance criteria

• A middleware/helper enforces org-scoped filtering on all DB queries.
• Attempting to read another org's data via API returns 403/404.
• MCP calls are also org-scoped — no cross-org leakage through the MCP path.
• Integration tests verify isolation for both API and MCP paths.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
auto_review:
drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[andrmaz]

What changed

Org-scoped filtering is now enforced at the Prisma query layer for every request, not just opted into per controller.

• db's new org-scope module: an AsyncLocalStorage-backed org context plus a Prisma Client Extension (createOrgScopedClient) that automatically injects/forces organizationId filters (or the equivalent relation filter for join/child models) on every model operation — reads, creates, updates, deletes. Any query made with no active org context throws MissingOrgContextError (fail closed). A deliberate runWithoutOrgScope escape hatch exists for the one legitimate pre-auth path (resolving a user's org during login).
• PrismaService no longer extends PrismaClient; every model delegate it exposes is routed through the org-scoped client, and the raw client has no external accessor — there is no way to bypass scoping from application code.
• OrgContextInterceptor (global, via APP_INTERCEPTOR) binds the authenticated caller's organizationId as the active context for the whole request, so controllers/services don't need to remember to filter by org themselves.
• OrgScopeExceptionFilter maps a query-layer OrgScopeViolationError (a write referencing a foreign-org record) to 403.
• Fixed a real cross-org leak: OrganizationsController had zero org scoping — any admin could list every organization, fetch any organization by id, and rename any organization. It now behaves like the existing DepartmentsController/AdminUsersController convention (403 on a mismatched id; list returns only the caller's own org).
• Wired @prisma/adapter-pg into PrismaService (Prisma 7 requires a driver adapter), incidentally fixing a previously-documented boot gap.

Why this design

Building this as an opt-in per-controller check (the existing pattern) is exactly what let OrganizationsController slip through with no scoping at all. The Prisma extension makes scoping mandatory at the query layer regardless of whether a given service author remembers to filter — new models must be registered in ORG_SCOPE_CONFIG or all queries against them fail closed.

Testing

• 61 new unit tests in packages/db covering the pure scoping logic and the extension itself (via a lightweight fake client that faithfully reproduces Prisma's $extends contract) — no live DB required.
• New/updated integration tests in apps/api (interceptor wiring, exception filter, organizations cross-org 403s, MCP cross-org isolation and concurrency).
• Manual end-to-end verification against a real local Postgres (seeded two orgs, confirmed cross-org reads never leak, cross-org writes are rejected with OrgScopeViolationError, $transaction batches stay correctly scoped, and no-context queries fail closed). This caught two real bugs the unit tests alone would have missed:
  • Prisma's client methods return a lazy promise that only registers its .then() reaction when awaited — a runWithOrgContext/runWithoutOrgScope callback that just returns that lazy promise (instead of being async and consuming it) silently loses the bound context. Documented on runWithOrgContext and fixed the one real call site that had this bug (UserService.findByGoogleSub).
  • Prisma's WhereUniqueInput (used by findUnique/update/delete/upsert) requires the unique identifier to stay a direct top-level field — wrapping it in AND fails validation. Added a separate flat-merge strategy (mergeUniqueWhere) for these operations.
• Full monorepo pnpm test / pnpm check-types / pnpm lint all pass.

Acceptance criteria

• A middleware/helper enforces org-scoped filtering on all DB queries.
• Attempting to read another org's data via API returns 403/404.
• MCP calls are also org-scoped — no cross-org leakage through the MCP path.
• Integration tests verify isolation for both API and MCP paths.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
auto_review:
drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[andrmaz]

What changed

Org-scoped filtering is now enforced at the Prisma query layer for every request, not just opted into per controller.

• db's new org-scope module: an AsyncLocalStorage-backed org context plus a Prisma Client Extension (createOrgScopedClient) that automatically injects/forces organizationId filters (or the equivalent relation filter for join/child models) on every model operation — reads, creates, updates, deletes. Any query made with no active org context throws MissingOrgContextError (fail closed). A deliberate runWithoutOrgScope escape hatch exists for the one legitimate pre-auth path (resolving a user's org during login).
• PrismaService no longer extends PrismaClient; every model delegate it exposes is routed through the org-scoped client, and the raw client has no external accessor — there is no way to bypass scoping from application code.
• OrgContextInterceptor (global, via APP_INTERCEPTOR) binds the authenticated caller's organizationId as the active context for the whole request, so controllers/services don't need to remember to filter by org themselves.
• OrgScopeExceptionFilter maps a query-layer OrgScopeViolationError (a write referencing a foreign-org record) to 403.
• Fixed a real cross-org leak: OrganizationsController had zero org scoping — any admin could list every organization, fetch any organization by id, and rename any organization. It now behaves like the existing DepartmentsController/AdminUsersController convention (403 on a mismatched id; list returns only the caller's own org).
• Wired @prisma/adapter-pg into PrismaService (Prisma 7 requires a driver adapter), incidentally fixing a previously-documented boot gap.

Why this design

Building this as an opt-in per-controller check (the existing pattern) is exactly what let OrganizationsController slip through with no scoping at all. The Prisma extension makes scoping mandatory at the query layer regardless of whether a given service author remembers to filter — new models must be registered in ORG_SCOPE_CONFIG or all queries against them fail closed.

Testing

• 61 new unit tests in packages/db covering the pure scoping logic and the extension itself (via a lightweight fake client that faithfully reproduces Prisma's $extends contract) — no live DB required.
• New/updated integration tests in apps/api (interceptor wiring, exception filter, organizations cross-org 403s, MCP cross-org isolation and concurrency).
• Manual end-to-end verification against a real local Postgres (seeded two orgs, confirmed cross-org reads never leak, cross-org writes are rejected with OrgScopeViolationError, $transaction batches stay correctly scoped, and no-context queries fail closed). This caught two real bugs the unit tests alone would have missed:
  • Prisma's client methods return a lazy promise that only registers its .then() reaction when awaited — a runWithOrgContext/runWithoutOrgScope callback that just returns that lazy promise (instead of being async and consuming it) silently loses the bound context. Documented on runWithOrgContext and fixed the one real call site that had this bug (UserService.findByGoogleSub).
  • Prisma's WhereUniqueInput (used by findUnique/update/delete/upsert) requires the unique identifier to stay a direct top-level field — wrapping it in AND fails validation. Added a separate flat-merge strategy (mergeUniqueWhere) for these operations.
• Full monorepo pnpm test / pnpm check-types / pnpm lint all pass.

Acceptance criteria

• A middleware/helper enforces org-scoped filtering on all DB queries.
• Attempting to read another org's data via API returns 403/404.
• MCP calls are also org-scoped — no cross-org leakage through the MCP path.
• Integration tests verify isolation for both API and MCP paths.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
auto_review:
drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}