Cross-Tenant Leakage

Expanded Definition

Cross-tenant leakage describes a failure of tenant isolation in which one customer can see or influence another customer’s data, configuration, or execution context. In SaaS, identity, and agentic workflows, the boundary may be broken by an unscoped query, a shared cache key, a reused token, or a background job that runs without tenant context. The risk is not limited to data exposure. It can also include state mutation, policy drift, and unintended tool actions that occur under the wrong tenant.

Definitions vary across vendors, especially when platforms blur the line between multi-tenant application design and shared identity infrastructure. For NHI security, the important distinction is that leakage is a tenancy control failure, not just a confidentiality issue. NIST’s Cybersecurity Framework reinforces the need for access control and continuous monitoring, while cross-tenant risk is often amplified by shared service principals, federated tokens, and agent execution paths. The most common misapplication is treating all tenant exposure as a simple permissions bug, which occurs when shared credentials or context propagation fail across asynchronous jobs.

Examples and Use Cases

Implementing tenant isolation rigorously often introduces operational overhead, requiring organisations to weigh stronger segmentation against more complex routing, caching, and observability.

• A support tool returns another customer’s case notes because the API handler reads from a shared cache entry without tenant-specific partitioning.
• A background reconciliation job updates the wrong account because the service account token is valid across tenants and the job omits tenant scoping.
• An AI agent connected through Anthropic’s report on an AI-orchestrated cyber espionage campaign retrieves records from the wrong workspace after its tool call inherits stale context.
• A secrets manager or vault policy is shared too broadly, allowing one tenant’s automation to read another tenant’s credentials, echoing the concerns highlighted in the Guide to the Secret Sprawl Challenge.
• Incident responders discover that an export job used a global service identity instead of a tenant-bound one, creating a silent cross-tenant data path.

For deeper NHI context, the 52 NHI Breaches Analysis shows how identity failures cascade once isolation assumptions are broken.

Why It Matters in NHI Security

Cross-tenant leakage is especially dangerous in NHI environments because service accounts, API keys, workload identities, and agents often operate at machine speed with broad reach. Once a token, cache, or job loses tenant context, the impact can spread faster than manual controls can detect. NHI Management Group research shows that 97% of NHIs carry excessive privileges and 96% of organisations store secrets outside secrets managers in vulnerable locations, conditions that make tenant isolation harder to enforce and easier to bypass. The same research also found that only 5.7% of organisations have full visibility into their service accounts, which means many cross-tenant paths remain undiscovered until after exposure. This is why tenant-scoped identity design, least privilege, and rigorous offboarding are governance requirements, not optional hardening steps. The Ultimate Guide to NHIs is a useful reference for the broader lifecycle controls that reduce blast radius.

Organisations typically encounter cross-tenant leakage only after a customer report, audit finding, or incident response investigation, at which point tenant scoping becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Cross-Environment Governance
• How should security teams prevent cross-tenant data leaks in multi-tenant apps?
• How should teams implement RBAC in multi-tenant SaaS without creating access leakage?
• Where does cross-environment agent discovery fit in an IAM programme?