Multi-Tenant Data and Policy Isolation
Strict logical isolation of data, policies, audit records, and execution contexts between tenants.
What It Means
Multi-Tenant Isolation means that every tenant operating within the iAgentic platform is completely and logically separated from every other tenant. Data, policies, audit records, decision contexts, and execution paths are partitioned at the architectural level. Tenant A cannot see, query, affect, or be affected by Tenant B — not through policy evaluation, not through audit queries, not through any system operation.
This is not application-level access control layered on top of a shared database. Isolation is enforced at the data model level, the policy compilation level, and the audit storage level. Every request carries a mandatory tenant_id as part of the Decision Schema, and every system operation is scoped to that tenant boundary.
Why It Is Needed
Multi-tenant AI platforms face unique isolation challenges that traditional SaaS platforms did not encounter:
- Policy cross-contamination— if governance policies are not strictly partitioned, a misconfigured rule in one tenant can affect another tenant's AI execution
- Model context leakage — shared model contexts or prompt histories can leak information between tenants if isolation boundaries are not enforced at the infrastructure level
- Audit commingling— if audit records are not strictly partitioned, one tenant's compliance investigation could inadvertently expose another tenant's decision data
- Compliance requirements— regulated industries (healthcare, finance, government) require provable data isolation. "Trust us, we have access controls" is not sufficient — isolation must be architecturally enforced and auditable.
Without strict tenant isolation, multi-tenant AI governance platforms become a compliance liability rather than a compliance asset.
How It Works in iAgentic
- Mandatory tenant_id on every request as part of the Decision Schema — requests without a valid tenant_id are rejected
- Policy bundles are compiled, versioned, and deployed independently per tenant — no shared policy state
- Audit records are partitioned by tenant at the storage level — no cross-tenant queries are possible
- Decision evaluation occurs within the tenant boundary — no policy from Tenant A can influence decisions for Tenant B
- Isolation boundaries are enforced at the data model level, not just the application level
- Tenant isolation status is included in operational assurance monitoring
What Gets Captured
tenant_id: Verified tenant identifier for the request
isolation_boundary_enforced: Confirmation that tenant isolation was maintained
policy_bundle_version: The specific policy bundle version deployed for this tenant
audit_partition: The isolated audit partition where the decision record is stored
Regulatory Alignment
SOC 2 CC6.1requires logical access controls that restrict information to authorized users. Tenant isolation ensures that each tenant's data and policies are accessible only within their boundary.
ISO 27001 A.8(Asset Management) requires identification and protection of information assets. Per-tenant isolation ensures that each tenant's governance assets (policies, audit records, decisions) are independently managed and protected.
EU AI Act Article 15 requires robustness in high-risk AI systems. Tenant isolation prevents cross-tenant interference, ensuring that governance operates reliably for each tenant independently.