Cross-Tenant Exposure

A failure where one user or organisation can reach data belonging to another tenant. In agentic systems, this often appears when boundaries are assumed in the application layer but not enforced tightly enough in the tool, identity, or retrieval layer.

Expanded Definition

Cross-tenant exposure is the failure of isolation between tenants in a shared system, allowing data, prompts, files, embeddings, logs, or actions intended for one tenant to become reachable by another. In NHI and agentic AI environments, the boundary is often assumed in the application layer but must also be enforced in identity, storage, retrieval, and tool execution paths. That makes the term broader than ordinary access control failure: it includes leakage through mis-scoped service accounts, shared vector indexes, weak row-level security, incorrect cache partitioning, and agent tool calls that omit tenant context. Industry usage is still evolving, so definitions vary across vendors, but the core idea is consistent: tenant separation must hold at every control point, not just at login. For architectural context, RFC 3986 is useful for understanding how resource identifiers are structured, even though it does not define tenancy itself.

The most common misapplication is treating a successful authentication flow as proof of tenant isolation, which occurs when downstream storage or retrieval layers ignore tenant-scoped authorization.

Examples and Use Cases

Implementing tenant isolation rigorously often introduces schema, policy, and routing overhead, requiring organisations to weigh stronger separation against higher operational complexity.

• A support agent receives another customer’s records because a shared retrieval index returns semantically similar content without tenant filtering.
• An AI agent uses a tool credential that is valid across tenants, so a single prompt can trigger writes into another organisation’s workspace.
• A shared object store bucket holds logs from multiple tenants, and misconfigured prefixes expose one tenant’s traces to another.
• A service account used by a background job is not bound to tenant context, letting API calls cross into adjacent accounts during retries.
• Tenant-aware controls are compared against breach patterns described in The 52 NHI breaches Report and against identity guidance in RFC 6749 when token scope and delegation matter.

Operational teams also look at whether tenant metadata is preserved end to end, because missing context in logs, queues, or caches can create silent cross-tenant read paths long after the original defect is deployed.

Why It Matters in NHI Security

Cross-tenant exposure is especially dangerous in NHI environments because NHIs are already overrepresented in machine-to-machine access, and mis-scoped credentials can traverse boundaries far faster than a human reviewer can detect. NHIMG reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which makes tenant boundary failures a direct security concern, not just a design flaw. The issue is amplified when secrets are stored outside managed vaults or embedded in CI/CD flows, as described in the Guide to the Secret Sprawl Challenge and the Ultimate Guide to NHIs. A relevant benchmark from NHI Mgmt Group is that 97% of NHIs carry excessive privileges, which increases the blast radius when tenant controls fail. For agentic systems, the concern extends to tool use, retrieval, and delegated execution, where one bad assumption can cross organizational lines in a single action. Organisations typically encounter this consequence only after a tenant reports unfamiliar data or an AI agent performs an out-of-scope action, at which point cross-tenant exposure becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams prevent cross-tenant data leaks in multi-tenant apps?
• Why do shared-schema multi-tenant systems create cross-customer risk?
• Tenant-consistent feature exposure
• Cross-Tenant Leakage