Architecture and Tenant Isolation
Implemented tenancy model, access boundaries, audit controls, and environment structure.
Tenancy Model
CreditAxis uses institution-specific tenant boundaries enforced at both the application layer and the database layer.
Every customer organization is assigned a unique org_id. All data tables include an org_id column. Queries are scoped to the authenticated organization — there is no mechanism by which an authenticated user from one institution can access data belonging to another institution.
_Last reviewed: February 2026. Evidence: Available under NDA (tenant-isolation-authorization-model)._
Authorization Model
Authorization is enforced at two independent layers:
1. Application layer (RBAC): Role-based access controls check every API request against the authenticated user's role permissions, stored in org_role_permissions. Roles determine which actions and data domains a user can access. Unauthorized requests are rejected before any data operation.
2. Database layer (RLS): Row-level security policies are enabled on all customer data tables. Even if an API-layer check were bypassed, the database layer enforces organizational scoping. Cross-tenant access is structurally prevented.
Permissions are assigned to roles, not individuals. Role assignments are managed by institution administrators.
_Last reviewed: February 2026. Evidence: Available under NDA (rbac-rls-evidence-summary, tenant-isolation-authorization-model)._
Environment Separation
Development, staging, and production environments are logically separated. Production deployments require a controlled promotion path. Database migrations are versioned and applied in sequence. Configuration state is managed outside source code.
_Evidence: Available under NDA (secure-release-change-management)._
Secrets Management
Secrets are stored outside source code using the hosting provider's secrets management infrastructure. Secrets are not committed to version control. Secret rotation follows defined procedures.
Administrative Access
Privileged access to production systems is restricted to named personnel. Administrative actions are attributable to a named actor and timestamp. Access is reviewed on a scheduled cadence. Access removal is documented.
_Evidence: Available under NDA (privileged-access-review-cadence)._
Audit Logging
An immutable, append-only audit log is maintained for all governance events:
- Deal stage transitions
- Policy version applications
- Authority checks and violations
- Approval actions
- Exception requests, justifications, and resolutions
- AI output reviews
- User authentication events
Every record captures: actor identity, organization, timestamp, action type, outcome, and subject entity. The log cannot be modified or deleted by application users.
_Evidence: Available under NDA (audit-log-sample-retention-summary)._
Change Management
All production changes follow a documented change management process. Changes are peer reviewed, tested, and deployed through a controlled release path with approval gates. Rollback capability is maintained for each release.
_Evidence: Available under NDA (secure-release-change-management)._
Data Flow Summary
Customer data enters the platform through the authenticated API layer. All data in transit is encrypted using TLS 1.2 or higher. Data at rest is encrypted using AES-256 via the Supabase infrastructure provider. AI inference inputs (when the Intelligence module is active) consist of deal narrative context — no PII or full borrower records are transmitted to the AI inference provider.
_Evidence: Available under NDA (architecture-diagram, data-flow-diagram)._