Tenant Trust Boundary#

Intended is a multi-tenant platform. Each tenant — typically an organization or a distinct business unit — operates within a trust boundary that isolates its policies, keys, tokens, and audit data from every other tenant. This page explains what a trust boundary is, what it isolates, how it is enforced, and what happens when boundary checks fail.

What Is a Trust Boundary#

A trust boundary is a security perimeter that separates one tenant's authorization domain from all others. Everything inside a boundary belongs to exactly one tenant. Nothing crosses a boundary without explicit, verified authorization.

In Intended, the trust boundary is not an abstraction implemented purely through application logic (e.g., filtering database queries by tenant ID). It is enforced through multiple layers, including cryptographic isolation of signing keys, tenant-scoped token claims, and runtime-level request routing.

What the Boundary Isolates#

Every trust boundary isolates six categories of tenant resources:

1. Policies#

Each tenant defines its own policy set. Policies are stored, versioned, and evaluated entirely within the tenant's boundary.

• A policy created by Tenant A is invisible to Tenant B
• Policy evaluation only considers the requesting tenant's active policies
• There is no concept of a "global" or "shared" policy that applies across tenants

2. Signing Keys#

Each tenant has dedicated cryptographic key material for signing decision tokens.

• Private signing keys are scoped to a single tenant
• Public verification keys are published on per-tenant JWKS endpoints
• Key rotation schedules are independent per tenant
• A key compromise in one tenant does not affect any other tenant

3. Decision Tokens#

Decision tokens are bound to the tenant that requested the evaluation.

• The tid claim in every token identifies the issuing tenant
• A token issued for Tenant A is rejected if presented in Tenant B's context
• Token verification includes a mandatory tenant scope check (see Decision Token Model)

4. Identity Registries#

Each tenant maintains its own identity registry — the set of subjects (users, agents, service accounts) recognized within that tenant's boundary.

• An identity registered in Tenant A's registry is not recognized in Tenant B
• Intent submission requires the subject to be present in the tenant's identity registry
• There is no cross-tenant identity federation within the Intended runtime

5. Audit Logs#

Every evaluation, token issuance, denial, and administrative action is logged within the tenant's audit scope.

• Tenant A's operators can only query Tenant A's audit logs
• Audit log storage is partitioned by tenant
• Cross-tenant audit queries are not supported, even for platform operators

6. Configuration#

Tenant-level configuration — including token TTL defaults, key rotation schedules, and enforcement mode settings — is scoped to the boundary.

• Tenant A's configuration changes do not affect Tenant B
• Default values are set at the platform level but are overridden per tenant when configured

How Isolation Is Enforced#

Tenant isolation is enforced at multiple layers. No single check is solely responsible — the layers are defense-in-depth.

Layer 1: Request Authentication and Tenant Resolution#

Every API request to the Intended runtime includes a tenant identifier derived from the caller's authentication credentials. The runtime resolves the tenant before any business logic executes.

Layer 2: Data Isolation#

At the data layer, tenant resources are partitioned so that queries are structurally incapable of returning cross-tenant results.

• Policy storage is partitioned by tenant identifier
• Audit log entries are tagged and indexed by tenant
• Key material is stored in tenant-scoped namespaces

Layer 3: Cryptographic Isolation#

Even if data isolation were somehow bypassed, cryptographic isolation provides a second barrier:

• A token signed with Tenant A's key cannot be verified with Tenant B's public key
• The kid (key identifier) in the token header is tenant-scoped, so a verifier looking up the key will only find keys for its own tenant
• There is no master key that can sign tokens for arbitrary tenants

Layer 4: Runtime Enforcement#

The authority runtime enforces tenant scope at every stage of the pipeline:

• Intent submission: The tenant resolved from the credential must match the intent's tenant_id
• Policy evaluation: Only policies belonging to the resolved tenant are loaded
• Token issuance: The token is signed with the resolved tenant's key and the tid claim is set to the resolved tenant
• Verification: The verifying service checks the tid claim against its own tenant context

Fail-Closed Defaults#

The trust boundary model follows a strict fail-closed principle: any ambiguity or failure in tenant resolution results in denial.

When Fail-Closed Applies#

Why Fail-Closed Matters#

In an authorization system, the cost of a false positive (incorrectly allowing an action) is typically much higher than the cost of a false negative (incorrectly denying an action). Fail-closed ensures that bugs, misconfigurations, or unexpected states result in denial rather than unintended access.

For example, if the runtime cannot load a tenant's policy set due to a transient error, it does not fall back to a permissive default. It denies the request and returns an error indicating that policy evaluation could not be completed.

Tenant Lifecycle#

Provisioning#

When a new tenant is provisioned:

Suspension#

A tenant can be suspended by a platform operator. While suspended:

• All API requests authenticated to the tenant are rejected
• No policy evaluations occur
• No tokens are issued
• Existing tokens remain verifiable until they expire (they are already signed), but new tokens cannot be obtained
• Audit logs remain accessible to platform operators for investigation

Deactivation#

When a tenant is permanently deactivated:

• All active sessions and credentials are revoked
• Signing keys are marked as retired (public keys remain available for a grace period so that recently-issued tokens can still be verified by downstream services)
• Audit logs are retained according to the platform's data retention policy
• Policy definitions are archived but no longer evaluated

Cross-Tenant Scenarios#

Intended does not support cross-tenant authorization. There is no mechanism for Tenant A to issue a decision token that is valid in Tenant B's context, or for a policy in Tenant A to reference resources in Tenant B.

If an enterprise needs two organizational units to share authorization context, the recommended pattern is:

1. Define both units within the same tenant
2. Use resource naming conventions and policy scoping to separate their authorization domains within the shared boundary
3. Use the policy engine's condition system to enforce which subjects can access which resource prefixes

This keeps the authorization model within a single trust boundary while providing logical separation.

Verifying Tenant Isolation#

Operators and security teams can verify that tenant isolation is functioning correctly:

• JWKS endpoint inspection — confirm that each tenant's JWKS endpoint returns only that tenant's public keys
• Cross-tenant token test — attempt to verify a token from Tenant A using Tenant B's verification context; the verification must fail
• Policy enumeration — list policies for a tenant and confirm that no policies from other tenants appear
• Audit log query — query a tenant's audit logs and confirm that no events from other tenants are present

Related Resources#

• What Is Intended — platform overview and positioning
• Authority Runtime Pipeline — how tenant scope is enforced in the pipeline
• Decision Token Model — how tokens are bound to a tenant
• Trust Model — the broader security model