Tenant Claim

Expanded Definition

A tenant claim is a token claim that tells a service which organisational boundary a request belongs to. In NHI and Agentic AI systems, it is the difference between a request being treated as “this customer’s workload” versus a generic authenticated caller with no scoped context.

Definitions vary across vendors, but the security purpose is consistent: tenant claims bind identity to a tenancy decision so policy engines, MCP servers, and downstream tools can apply the right access rules. That makes the claim a context signal, not a substitute for authentication or authorisation. It should be validated against trusted issuer logic, tenant directory records, and the resource being requested, rather than accepted because it appears in a token payload. The NIST Cybersecurity Framework 2.0 reinforces the broader need for explicit access governance, while tenant claims operationalise that principle in multi-tenant execution paths.

The most common misapplication is trusting a tenant claim as if it were self-authenticating, which occurs when applications skip server-side tenancy verification and let the token decide the boundary alone.

Examples and Use Cases

Implementing tenant claims rigorously often introduces routing and validation overhead, requiring organisations to balance tenant isolation against token complexity and integration effort.

• A SaaS platform issues a tenant claim so each API call is routed to the correct customer dataset and policy set.
• An MCP server reads the claim before tool execution so an AI agent cannot cross from one organisation’s context into another’s administrative tools.
• A support workflow uses the claim to limit incident responders to a specific tenant while preserving audit trails for delegated access.
• A federated identity setup combines the tenant claim with issuer checks and local tenancy mapping to prevent confused-deputy failures.
• The DeepSeek breach illustrates why context leakage matters: once sensitive data or credentials are exposed, weak tenancy controls can widen the blast radius of misuse.

For comparison, guidance from NIST Cybersecurity Framework 2.0 supports the idea that access decisions should be explicit, repeatable, and auditable rather than inferred from ambient session state.

Why It Matters in NHI Security

Tenant claims matter because NHI failures often begin as context failures. If an AI agent, service account, or machine token is allowed to present the wrong tenant context, the result is not just a bad response, but a cross-boundary action, data exposure, or policy bypass. That is especially dangerous in multi-tenant MCP environments where tool access, retrieval scope, and logging all depend on precise organisational context.

NHIMG research shows how quickly exposed machine credentials can be abused: when AWS credentials are publicly exposed, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, a reminder that tenancy mistakes are often exploited before teams can react. The LLMjacking research also shows how compromised NHIs are used to hijack AI workflows, making tenant scoping part of practical defence rather than architectural neatness. Organisations typically encounter the importance of tenant claims only after a token is replayed into the wrong customer boundary, at which point tenancy validation becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why does tenant ownership matter for NHI governance?
• How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
• What is the difference between tenant ownership and data residency in identity governance?
• What is the difference between user error and tenant misconfiguration in collaboration security?