Multi-Tenant Domain Classification Prompt Template

This prompt is designed for platform engineers who are building AI systems that serve multiple organizations and must enforce strict tenant isolation at the ingress layer. The primary job-to-be-done is to map an unstructured user request to exactly one tenant domain from a predefined registry before any data retrieval, tool access, or policy application occurs. This is a hard security boundary, not a soft routing preference. Use this prompt when the system's authorization model depends on correctly identifying the tenant context from the content of the request itself, such as in an API gateway or a shared AI assistant where the authenticated session does not already provide a definitive tenant scope.

Deploy this classification step when the cost of tenant leakage is high. For example, if a request for 'Acme Corp's Q3 sales data' is misrouted to the 'Globex' tenant domain, the model could retrieve and expose Globex's confidential sales figures. The prompt must be integrated into a pre-processing pipeline that gates access to downstream Retrieval-Augmented Generation (RAG) indexes, tool schemas, and policy packs. It is ideal for systems where a single model instance handles requests from multiple organizations, and the tenant context must be dynamically inferred from the input text. The prompt's output should be a structured decision that a downstream router can act on deterministically, not a conversational suggestion.

Do not use this prompt when tenant context is already reliably available from a trusted source, such as a cryptographically verified API key, a JWT claim, or an authenticated session variable. In those cases, inferring the tenant from the input text introduces an unnecessary attack surface and a potential for misrouting. Similarly, do not use this prompt for general topic classification where data isolation is not at stake; a misclassification in a content tagging system is a minor inconvenience, whereas a misclassification here is a security incident. The next step after understanding this use case is to review the prompt template and begin designing the validation harness that will catch and quarantine any misrouted requests before they reach a data store.

The following prompt template is designed to be placed directly into your system prompt or as the first step in a classification chain. It forces the model to select exactly one tenant domain from a provided registry, return a confidence score, and abstain when the input does not clearly belong to any registered tenant. This is not a general-purpose classifier; it is built for multi-tenant platforms where misclassification means violating data isolation, applying the wrong tools, or exposing one tenant's policies to another's data.

textCopy
You are a multi-tenant domain classifier. Your only job is to read the user's request and assign it to exactly one tenant domain from the registry below. You must not process the request, answer it, or use any tools. You must only classify.

## TENANT REGISTRY
[TENANT_REGISTRY]

## CLASSIFICATION RULES
1. Select the single best-matching tenant domain from the registry.
2. If the request could match multiple tenants, choose the one with the strongest signal. Explain your reasoning in the `rationale` field.
3. If the request does not clearly belong to any tenant, set `tenant_id` to `null` and `abstained` to `true`. Do not guess.
4. Do not use information from other tenants to classify this request. Each classification is independent.
5. If the request mentions multiple tenants, classify based on the primary intent, not the mention.

## INPUT
[INPUT]

## OUTPUT SCHEMA
Return ONLY valid JSON matching this schema:
{
  "tenant_id": "string | null",
  "tenant_name": "string | null",
  "confidence": 0.0-1.0,
  "rationale": "string",
  "abstained": boolean,
  "signals_used": ["string"]
}

## CONSTRAINTS
- Never return a tenant_id that is not in the registry.
- If confidence is below [MIN_CONFIDENCE_THRESHOLD], set `abstained` to `true` and `tenant_id` to `null`.
- The `signals_used` array must list the specific terms, patterns, or context clues that led to the classification.
- Do not include any text outside the JSON object.

To adapt this template, replace [TENANT_REGISTRY] with a structured list of your tenants, including their unique IDs, display names, and any keyword or context signals that help disambiguate them. The registry should be treated as sensitive configuration; never hard-code tenant-specific logic into the prompt itself. Set [MIN_CONFIDENCE_THRESHOLD] based on your routing risk tolerance—start at 0.70 and adjust after evaluating false positives and false negatives in production. The [INPUT] placeholder should receive the raw user text, not a pre-processed or summarized version, because signal loss before classification is a common failure mode. If your platform requires different handling for abstained requests, wire the abstained field into a fallback routing path that either asks the user for clarification or escalates to a human reviewer. Never auto-route an abstained classification to a default tenant.

Wiring this prompt into an application requires treating tenant classification as a security-critical routing decision, not a best-effort label. The prompt output must be validated before any downstream context is attached, any tool is dispatched, or any data store is queried. A misclassification here means one tenant's data, tools, or policies could leak into another tenant's session. The implementation harness must enforce that the returned tenant_id exists in the platform's tenant registry, that the classification confidence exceeds a configurable threshold, and that cross-tenant signals are explicitly checked before the request proceeds.

Start with a pre-invocation guard: extract any tenant hint from the request context (JWT claim, API key binding, URL slug) and pass it as a [HINT_TENANT_ID] variable into the prompt. The model should explain any mismatch between the hint and its own classification. After the model returns, run a post-invocation validator that: (1) confirms the tenant_id is a valid, active tenant in your registry; (2) checks that confidence is above your threshold (start at 0.85 for auto-routing, route 0.60–0.85 to a clarification prompt, reject below 0.60); (3) flags any cross_tenant_signals for human review if the confidence is high but the hint mismatches; and (4) logs the full classification payload, input hash, and model version for audit. For model choice, use a fast, cost-effective model (GPT-4o-mini, Claude Haiku) for the classification step—this is a routing decision, not a generation task. Reserve larger models only for the clarification or escalation path.

Build a retry and escalation loop around the classifier. If the validator rejects the output (malformed JSON, unknown tenant, confidence below threshold), retry once with a repair prompt that includes the validation error. If the retry also fails, escalate to a clarification prompt that asks the user to confirm their organization or department, or route to a human triage queue with the original input and both classification attempts attached. For multi-tenant SaaS platforms, also implement a tenant leakage eval harness that runs offline: maintain a golden set of inputs with known tenant assignments, inject edge cases that blend terminology from two tenants, and measure both false-positive cross-tenant routing and false-negative rejection rates. Run this eval on every prompt change before deployment. Finally, expose a classification trace in your observability stack: log the input hash, classified tenant, confidence, latency, model used, and whether the classification was auto-routed, clarified, or escalated. This trace is essential for debugging tenant routing incidents and proving data isolation to auditors.