Platform / Tenant Isolation

Hard tenant boundaries at the proxy layer

Tenant isolation enforced before the model sees a token. Cross-tenant data bleed becomes architecturally impossible when the boundary lives in the policy plane, not the application.

Request Access Read isolation patterns

Three isolation models

Choose the model that matches your tenancy architecture and compliance requirements.

Header-based isolation

Each request carries a tenant identifier in an HTTP header. Meibel scopes the audit context and rate-limit bucket per tenant automatically.

+ Pros

Minimal integration lift

Works with any client

− Cons

Requires app to set header

API-key scoped isolation

Each tenant gets a distinct Meibel API key. The key itself determines the tenant context — no header required in the request body.

+ Pros

Cryptographically bound

Audit log auto-tagged

− Cons

More keys to manage

Project-level isolation

Separate Meibel projects per deployment. Full policy isolation including redaction rules, rate limits, and log partitioning.

+ Pros

Strongest separation

Independent policies

− Cons

Higher management overhead

Configuration

Define tenant enforcement in your policy YAML alongside redaction and rate-limit rules.

policy.yaml

tenant_isolation:
  enabled: true
  mode: header
  header: X-Tenant-ID
  on_missing_header: reject
  log_tenant_in_audit: true

Close the tenant bleed vector.

Connect your multi-tenant LLM deployment to Meibel. Isolation is enforced from the first call.

Request Access Read isolation patterns