M2-12 Zero-Trust / Multi-Tenant Platform Foundations

Milestone: M2 — Platform and Client Admin SOW Reference: NFR1, NFR3 Requirement Clarity: ✅ Clear Dev Status: 🟡 Partially prototyped — multi-tenant data segregation (orgId scoping) is solid; formal zero-trust architecture is not

Overview

Platform-wide foundations that every other M2/M3 feature builds on top of: strict multi-tenant data segregation, and a zero-trust security posture (never implicitly trust a request based on network origin — always verify).

Backend Tasks

• Confirm every entity/query that should be org-scoped actually enforces orgId/organizationId filtering (earlier review found this consistently applied — worth a systematic re-check as the codebase grows)
• Define what "zero trust" means concretely for this platform beyond JWT + RBAC (e.g. service-to-service auth, mutual TLS where relevant, least-privilege IAM) and document it
• Wire up the provisioned-but-unused Redis instance if it's meant to serve a session-store/caching role in the security model, or remove it if not needed

Frontend Tasks

• N/A — this is a backend/infrastructure task.

Dependencies

• Everything else in M2/M3 depends on this being solid — treat as an early task, not a late one.

Acceptance Criteria

• Multi-tenanted environment supports logical data separation between organisations
• Zero-trust architecture documented and implemented (per SOW NFR1, NFR3)

Existing Reference Material

• ../../requirements/user_stories/security-compliance/zero-trust-architecture.md
• ../../requirements/user_stories/platform-infrastructure/cloud-based-hosting.md

Blockers & Risks

• Risk: "zero trust" is currently more of a stated goal than an implemented architecture — worth clarifying with Curo how rigorously this will be assessed at acceptance (Appendix 3 just says "system should be built using a Zero-trust architecture" with no detailed test plan for it).