Organisational Namespace Isolation governs the strict separation between distinct client or tenant namespaces within a shared governance platform. Every organisation deploying agents on shared infrastructure — whether a managed platform, a cloud-hosted governance service, or a shared on-premises environment — depends on namespace isolation to ensure that its governance data, mandate configurations, audit trails, and agent credentials remain invisible and inaccessible to every other tenant. AG-015 requires that namespace boundaries are enforced at the infrastructure layer, not solely at the application layer. The critical distinction is between logical isolation through structural enforcement and mere access control through application-layer checks. Leakage of governance data to another tenant constitutes a data breach; corruption of governance data by another tenant constitutes a governance failure. AG-015 exists to make both structurally impossible.
Scenario A — Cache Poisoning Across Tenant Boundaries: A multi-tenant governance platform uses a shared Redis cache to accelerate mandate lookups. Cache keys are constructed as mandate:{mandate_id} without a tenant prefix. Tenant A's agent queries its mandate and the result is cached. Tenant B's agent, through a manipulated mandate_id parameter, constructs a request that resolves to the same cache key. The cache returns Tenant A's mandate configuration — including maximum transaction limits, permitted counterparties, and time window restrictions — to Tenant B's agent.
What went wrong: The cache layer did not enforce tenant namespace isolation. While the database enforced row-level security, the cache was a shared flat namespace. The application code assumed the database would filter results, but the cache bypassed the database on cache hits. The cache key structure did not include tenant context. Consequence: Full disclosure of Tenant A's mandate configuration to Tenant B. GDPR data breach notification required. If both tenants are financial services firms, potential market abuse investigation. Platform's SOC 2 certification revoked pending remediation.
Scenario B — Incomplete Tenant Teardown Exposes Historical Data: A tenant offboards from the governance platform. The teardown procedure deletes the tenant's records from the primary database. However, the procedure does not purge backup snapshots, search index entries that cached the tenant's mandate and audit data, or analytics pipeline outputs that included the tenant's data in aggregate calculations. Three months later, a new tenant is onboarded and assigned infrastructure that includes a restored backup from before the teardown. The new tenant's administrator discovers the previous tenant's governance data in the restored environment.
What went wrong: The teardown procedure was incomplete. It addressed the primary data store but not secondary stores, backups, or derived data. There was no post-teardown verification to confirm that all data had been purged. Consequence: Data breach for the departed tenant, discovered after they are no longer a customer. Regulatory investigation into data retention and deletion practices. Potential legal claims under GDPR Article 17 (right to erasure).
Scenario C — Aggregate Reporting Leaks Individual Tenant Positions: A governance platform provides a benchmarking feature that shows tenants how their governance metrics compare to the platform average. The platform has only three tenants in a specific industry segment. When the benchmarking report shows "average daily exposure across financial services tenants: GBP 2.4 million," each tenant can calculate the other two tenants' combined exposure by subtracting their own. With only two other tenants, the exposed aggregate is highly identifying.
What went wrong: The aggregate reporting did not account for small population sizes. With fewer than a minimum threshold of tenants in a segment, aggregate statistics become individually identifying. The platform did not implement minimum population thresholds or differential privacy techniques to prevent re-identification. Consequence: Indirect disclosure of individual tenant governed exposure data through mathematical inference. Potential market abuse implications if the tenants are competitors. Regulatory finding under GDPR for inadequate anonymisation.
Scenario D — Developer Query Omits Tenant Filter: A governance platform hosts two competing financial services firms on the same multi-tenant infrastructure. A developer at the platform provider, while debugging a performance issue, writes a database query that inadvertently omits the tenant_id filter. The query returns results from all tenants and is logged. Six months later, the log is discovered during a security review, triggering GDPR Article 33 breach notification obligations to both firms and an assessment of whether cross-tenant exposure constituted a market abuse risk.
What went wrong: Namespace isolation depended on application-layer diligence rather than structural enforcement at the database layer. A single omitted WHERE clause exposed cross-tenant data. Consequence: Regulatory consequences cascade across GDPR, FCA supervision, and the platform's SOC 2 certification.
Scope: This dimension applies to all multi-tenant governance platforms where more than one organisation's agents are governed by the same infrastructure. This includes cloud-hosted governance services, managed platform deployments, and any shared infrastructure arrangement where multiple legal entities rely on common governance components. The scope extends beyond the primary data store. Namespace isolation must be enforced across every component that processes, stores, or transmits tenant data: databases, caches, message queues, logging pipelines, search indices, backup systems, analytics platforms, and any intermediate processing layer. A system that enforces perfect isolation at the database layer but allows cross-tenant data to commingle in a shared cache or search index has not achieved AG-015 compliance. The scope also includes derived and aggregate data. If a platform produces aggregate statistics, benchmarks, or analytics from tenant data, those aggregates must not be reversible to identify individual tenant data.
4.1. A conforming system MUST validate tenant namespace on every operation — no database query, cache read, API call, or message queue operation may proceed without verified tenant context.
4.2. A conforming system MUST block and log all cross-tenant data access attempts — any attempt to access data outside the authenticated tenant's namespace must be rejected and recorded as a security event.
4.3. A conforming system MUST scope agent credentials to their tenant — credentials from one tenant MUST NOT authenticate against another tenant's namespace, and credential material must not be shared across tenant boundaries.
4.4. A conforming system SHOULD design shared infrastructure components to prevent cross-tenant state leakage — caches, message queues, temporary storage, and processing pipelines should enforce tenant boundaries.
4.5. A conforming system SHOULD ensure that tenant teardown purges all associated state without affecting other tenants — including data in backups, caches, search indices, and derived analytics.
4.6. A conforming system SHOULD ensure that aggregate reporting never exposes per-tenant data across tenant boundaries — statistical outputs must be tested for reversibility and individual identification risk.
4.7. A conforming system MAY implement physical infrastructure separation for high-security tenants — dedicated database instances, separate compute clusters, or isolated network segments for tenants with elevated security requirements.
Organisational Namespace Isolation is one of the most critical security dimensions in any multi-tenant deployment of AI agent governance infrastructure. AI agent governance platforms hold extraordinarily sensitive data. A tenant's namespace contains: the mandate configurations that define what their agents can do, the audit trails that record what their agents have done, the credential material that authenticates their agents, the exposure calculations that reveal their financial positions, and the compliance evidence that demonstrates their regulatory posture. Leakage of any of this data to another tenant constitutes a data breach. Corruption of any of this data by another tenant constitutes a governance failure.
The critical distinction is between logical isolation and mere access control. Many multi-tenant systems implement access control — they check whether a requesting identity has permission to access a resource. AG-015 requires something more fundamental: that each tenant's data exists within a namespace boundary that is enforced at the infrastructure layer. The analogy is the difference between two departments sharing an open-plan office with a policy not to read each other's documents, and two departments occupying separate locked rooms with independent key systems. The first relies on compliance. The second relies on structure.
This distinction is essential because a governance platform breach does not just expose what an organisation did — it exposes how an organisation governs, what limits it has set, and where its controls are weakest. This is strategic intelligence that could be exploited by competitors, adversaries, or malicious actors. The blast radius of a namespace isolation failure is proportional to the number of tenants on the platform and the sensitivity of their governance data.
AG-015 is distinct from AG-013 (Data Sensitivity Classification and Handling), which governs how data is classified and handled within a single namespace. It is also distinct from AG-047 (Cross-Border Governance), which governs regulatory jurisdiction boundaries. AG-015 operates at the organisational level — the boundary between entirely separate legal entities sharing infrastructure — and every control in AG-013 and AG-047 assumes that AG-015 is functioning correctly.
AG-015 establishes the tenant namespace as the foundational security boundary in any multi-tenant governance platform. Every database query, cache operation, and API call must include tenant_id as a validated parameter derived from the authenticated credential, never from request parameters. Structural enforcement at the database layer provides defence in depth that application-layer validation cannot match.
Recommended patterns:
Anti-patterns to avoid:
Financial Services. Financial services firms on shared governance platforms face specific regulatory obligations around data segregation. The FCA expects firms to demonstrate that their data is isolated from competitors' data on shared infrastructure. MiFID II best execution requirements mean that trading pattern data — which may be visible in governance audit trails — is competitively sensitive. Firms should require their governance platform providers to demonstrate AG-015 compliance as part of vendor due diligence, and should consider whether physical separation (not just logical isolation) is required for their most sensitive governance data.
Healthcare. Healthcare organisations must comply with HIPAA Security Rule requirements for access controls (45 CFR 164.312(a)) and audit controls (45 CFR 164.312(b)). On shared governance platforms, patient-related governance data must be isolated at the namespace level. Business Associate Agreements with platform providers should explicitly address namespace isolation. The HIPAA Breach Notification Rule (45 CFR 164.400-414) would apply if cross-tenant data exposure included protected health information.
Critical Infrastructure. Critical infrastructure operators on shared governance platforms face unique risks because their governance data may reveal operational parameters, security configurations, and vulnerability management practices. NERC CIP (for energy), TSA Security Directives (for pipeline and surface transportation), and sector-specific regulations may impose additional isolation requirements beyond logical separation. These organisations should strongly consider physical infrastructure separation.
Basic Implementation — The organisation has implemented tenant_id validation at the application layer. Every API endpoint and database query includes a tenant_id parameter that is checked against the authenticated session. Cross-tenant access attempts are blocked and return an error response. Tenant credentials are issued per-tenant and cannot authenticate across namespaces. This level meets the minimum mandatory requirements but has architectural limitations: the tenant_id check is in application code and could be bypassed by a code defect, the validation logic is duplicated across multiple services, and shared infrastructure components (caches, queues) may not enforce tenant boundaries independently.
Intermediate Implementation — Namespace isolation is enforced at the database layer through row-level security policies or equivalent structural controls. The database itself prevents any query from returning data outside the authenticated tenant's namespace, regardless of what the application code requests. Caches and message queues use tenant-scoped key prefixes or separate logical partitions. Tenant teardown procedures are documented and tested. Cross-tenant access attempts generate security events routed to monitoring and incident response. The tenant_id is derived exclusively from the authenticated credential, never from request parameters.
Advanced Implementation — All intermediate capabilities plus: namespace isolation has been verified through independent penetration testing that specifically targets cross-tenant access vectors including SQL injection, cache poisoning, message queue manipulation, and timing side-channel attacks. High-security tenants have the option of physically separated infrastructure. Backup and disaster recovery procedures maintain tenant isolation throughout the recovery process. Tenant isolation is monitored continuously through automated canary tests that attempt cross-tenant access and alert on any success. The platform can demonstrate to auditors that no known attack vector permits cross-tenant data access.
Required artefacts:
Retention requirements:
Access requirements:
Testing AG-015 compliance requires a systematic approach that covers every data path in the platform, not just the primary API endpoints.
Test 8.1: Direct Cross-Tenant Access
Test 8.2: Credential Scoping
Test 8.3: Cache and Queue Isolation
Test 8.4: Side-Channel Leakage
Test 8.5: Teardown Isolation
Test 8.6: Aggregate Data Re-identification
| Regulation | Provision | Relationship Type |
|---|---|---|
| SOC 2 Type II | Logical Separation (CC6.1, CC6.3, CC6.6) | Direct requirement |
| GDPR | Articles 25, 28, 32 (Data Protection by Design, Processor Obligations, Security) | Direct requirement |
| ISO 27001 | Annex A.9 (Access Control) | Direct requirement |
| HIPAA | 45 CFR 164.312(a) (Access Controls) | Supports compliance |
| MiFID II | Best Execution / Data Segregation | Supports compliance |
SOC 2 Trust Services Criteria require that service organisations implement logical access security controls that restrict access to information assets to authorised users. For multi-tenant platforms, this specifically means demonstrating that one customer's data cannot be accessed by another customer or their agents. The SOC 2 examination will test logical separation controls through inquiry, observation, and testing. Auditors will examine the architecture for tenant isolation, review access control configurations, and test whether cross-tenant access is possible. A SOC 2 Type II report covers a period of operation (typically 6-12 months), meaning the controls must be consistently effective over time. Specific Common Criteria relevant include CC6.1 (logical and physical access controls), CC6.3 (role-based access), and CC6.6 (system boundaries).
Under GDPR, each tenant on a multi-tenant platform is likely a separate data controller. The platform provider is a data processor acting on behalf of each controller. Article 28 requires the processor to implement "appropriate technical and organisational measures" to protect the data. Article 32 requires "a level of security appropriate to the risk," including "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems." Cross-tenant data leakage constitutes a personal data breach under Article 4(12), triggering the notification obligations of Articles 33 and 34. The processor must notify the affected controllers within 72 hours. GDPR also requires data protection by design and by default (Article 25). Namespace isolation that is structural — enforced at the database and infrastructure layer — aligns with this requirement. Namespace isolation that depends solely on application code does not demonstrate "by design" protection.
ISO 27001 Annex A.9 requires access control policies, user access management, and system and application access control. For multi-tenant platforms, this maps directly to tenant namespace isolation. The access control policy must define tenant boundaries. User access management must ensure that credentials are scoped to tenant namespaces. System access control must enforce isolation at the infrastructure layer. An ISO 27001 certification audit will examine whether tenant isolation is part of the Information Security Management System (ISMS) and whether it is subject to regular review and testing.
Healthcare organisations on shared governance platforms must comply with HIPAA Security Rule requirements for access controls and audit controls. Patient-related governance data — such as audit trails of agent actions involving patient records — must be isolated at the namespace level. The HIPAA Breach Notification Rule (45 CFR 164.400-414) would apply if cross-tenant data exposure included protected health information.
MiFID II best execution requirements mean that trading pattern data visible in governance audit trails is competitively sensitive. Financial services firms on shared platforms must demonstrate that their trading-related governance data is segregated from competitors' data, supporting both best execution obligations and market abuse prevention.
| Field | Value |
|---|---|
| Severity Rating | Critical |
| Blast Radius | Platform-wide — proportional to the number of tenants and the sensitivity of their governance data; potentially cross-organisation where multiple legal entities share infrastructure |
Consequence chain: Without structural namespace isolation, a compromised agent in one tenant can access, modify, or corrupt another tenant's governance configuration, mandate data, or audit trail — constituting a data breach for all affected organisations. The impact extends beyond data confidentiality to governance integrity: if Tenant A can modify Tenant B's mandate configuration, Tenant B's agents may operate outside their intended boundaries without detection. The failure mode is particularly severe because governance platforms hold data about controls, not just operational data. A breach of a governance platform does not just expose what an organisation did — it exposes how an organisation governs, what limits it has set, and where its controls are weakest. This is strategic intelligence that could be exploited by competitors, adversaries, or malicious actors. The blast radius multiplies across every affected tenant. Regulatory consequences cascade: GDPR breach notification for all affected controllers, potential market abuse investigations for financial services tenants, SOC 2 certification revocation, and potential personal liability for platform operators. Each affected tenant must independently assess regulatory notification obligations, multiplying the incident response burden across the entire tenant base.
Cross-reference note: AG-012 (Identity Assurance) ensures agent identities are verified before namespace access is granted, providing the authentication foundation AG-015 depends on. AG-013 (Data Sensitivity Classification and Handling) governs data handling within a single namespace. AG-047 (Cross-Border Governance) enforces jurisdictional boundaries that may cross-cut tenant namespaces. AG-006 (Audit Trail Integrity) ensures audit trails within each tenant's namespace are tamper-evident. AG-016 (Cryptographic Action Attribution) provides cryptographic proof of actions within a namespace, preventing cross-tenant attribution confusion.