Schema-per-tenant PostgreSQL architecture, JWT tenant binding for portal users, agent polling credentials, and dedicated database profiles-with honest limits on application-layer defense for MSP SaaS procurement.
Visual summary before evidence tables below.
Trust evidence
Schema-per-tenant PostgreSQL architecture, JWT tenant binding for portal users, agent polling credentials, and dedicated database profiles-with honest limits on application-layer defense for MSP SaaS procurement.
Trustholm isolates MSP customer data using schema-per-tenant architecture in PostgreSQL rather than relying solely on row-level security in shared tables. Each tenant receives a dedicated schema (for example tenant_{code}) containing that organization's agents, scripts, audit rows, and configuration.
Why schema-per-tenant for MSP SaaS: MSP platforms often commingle thousands of end-customer records. A single missing WHERE tenant_id = ? clause in shared-table designs can leak data across customers. Namespace separation at the database layer reduces blast radius: connection routing targets one schema per tenant for tenant-scoped queries.
API tenant binding: For authenticated portal users, JWT includes TenantId. Middleware resolves tenant from X-Tenant-Code, subdomain, or path and must match the claim-otherwise the API returns 403. Platform principals (Super Admin) follow documented support-access audit rules.
Agent and probe paths: Anonymous agent routes do not use JWT tenant binding. Agents present tenant code headers and per-agent polling key hashes (X-Agent-Key). Registration and heartbeat issue credentials once; runtime stores them in agent.runtime.json with tenant binding that does not restore across tenant installs.
Dedicated database tier: IsolationProfile DedicatedDatabase via connection secret reference supports enterprise buyers who need separate database instances-not just separate schemas in a shared cluster.
Defense in depth: Schema separation does not eliminate application bugs. Tests, code review, least-privilege database roles, and operational access controls remain necessary. We document this limitation plainly rather than implying architectural perfection.
Scale implications: Schema-per-tenant supports large MSP fleets without commingling customer script libraries in one shared table namespace. Migration and backup planning should account for per-schema growth-your DBA documents capacity planning.
Comparison to dedicated silos: Some buyers ask for per-customer clusters. DedicatedDatabase addresses separate instances; cluster-level dedicated profiles remain roadmap. Match procurement language to actual connection profiles in contract-not aspirational diagrams.
Execute during trial week one: provision two tenants; create non-admin user in each; attempt cross-tenant API call with mismatched JWT header; export audit from each tenant and diff for foreign identifiers; reinstall agent with --force and inspect runtime tenant code; request DedicatedDatabase documentation if procurement requires separate instance; configure Event Hub sink or document JSON/CSV forwarding; file gap memo for WORM and vendor SOC 2 status.
Document results in customer SharePoint or GRC-auditors prefer timestamped evidence over verbal assurance. Include DB operator access policy from your hosting provider since schema isolation does not remove infrastructure privilege risk.
MSPs migrating from single-schema tools should plan data migration validation-not just cutover weekend success criteria. Compare audit export row counts pre- and post-migration for representative clients.
Avoid claiming dedicated cluster isolation unless DedicatedDatabase or future DedicatedCluster is contracted. Use schema-per-tenant phrasing in RFP responses and cite trial reproduction steps as proof.
Customer and group scoping inside a tenant is catalog-driven-assessors evaluating end-customer separation should review how your MSP maps clients to groups and exports evidence per client, not assume separate Trustholm tenants per end customer unless your commercial model does. Document group-to-client mapping in data flow diagrams submitted to enterprise buyers.
When assessors ask about blast radius, walk through schema name, JWT claim, and export slice-not generic multi-tenant marketing language.
Connection pool and ORM discipline: Application code routes tenant-scoped queries through schema resolution middleware. Security reviews should include code-path verification during major upgrades-not only black-box API tests. Least-privilege database roles for application service accounts reduce operator-adjacent risk when combined with schema separation.
Disaster recovery testing: Include tenant schema restore drills in your DBA calendar. Verify restored schema names match production tenant codes and that JWT binding still aligns post-restore.
DR exercises surface residency and isolation assumptions that slide decks omit. Include Super Admin elevation path in vendor risk appendix when platform support access is in system boundary.
For hybrid deployments, document which data classes remain in incumbent tools versus Trustholm schema to prevent assessor scope confusion. Add schema-per-tenant callout to data processing agreement technical schedules where legal teams accept architecture annexes.
This page describes product capabilities for your control matrix. Trustholm does not hold SOC 2, ISO 27001, IRAP, Essential Eight, CMMC, Cyber Essentials, NIS2, or framework certification badges.
| Topic | Evidence | Status | Notes |
|---|---|---|---|
| Schema-per-tenant data | Dedicated PostgreSQL schema per tenant (tenant_{code}) | Shipped | - |
| JWT tenant binding | Resolved tenant must match JWT TenantId claim for portal users | Shipped | - |
| Agent polling credentials | Per-agent polling key hash; X-Agent-Key header enforcement | Shipped | - |
| Dedicated database tier | IsolationProfile DedicatedDatabase via connection secret ref | Shipped | - |
DedicatedCluster is a future profile. DedicatedDatabase via connection secret ref is available for separate database instances. Default deployments use schema-per-tenant within shared infrastructure. Match sales diagrams to contracted connection profile-assessors compare contracts to architecture, not slide decks alone.
RLS can work when rigorously enforced on every query. Schema-per-tenant adds structural separation so ORM or raw SQL mistakes are less likely to cross tenant boundaries. Many buyers prefer both where feasible. Document which model Trustholm uses in SSP data flow diagrams.
Platform Super Admins can select tenants under audited support-access rules. Normal tenant users are bound to their JWT tenant. Cross-tenant portal access without elevation is blocked. Test with trial accounts during diligence.
Agent runtime credentials are tenant-bound. Install with --force does not restore runtime across tenants. This prevents accidental cross-tenant polling after imaging or redeployment. Add runtime verification to golden-image QA checklists.
Backup and restore procedures are operator responsibilities. Trustholm does not run customer DR restore as a product feature. Schema layout supports logical per-tenant restore patterns; your DBA documents RPO/RTO and encryption for the hosting environment. Include backup geography in residency reviews.
No product checkbox satisfies IRAP. Isolation architecture is one input to your system security plan. Pair with network controls, IAM, logging, and agency-specific consumer responsibilities documented in procurement packets.