HITL for Multi-Tenant AI Agents: Why the Same Reviewer Pool Can't Govern Different Customers
Most HITL designs assume one deployer, one reviewer pool, one policy. The textbook diagram shows a single agent proposing actions, a single reviewer pool making decisions, a single audit trail recording everything. Clean. Simple. Wrong for production.
Enterprise AI is multi-tenant. The same agent infrastructure serves dozens — sometimes hundreds — of customers. Each customer has their own data, their own compliance regime, their own reviewers, their own escalation chains, their own audit trail retention rules. Treating all customers as one tenant is a privacy violation, a compliance violation, and a design defect that surfaces when the first regulatory inquiry arrives.
This post is about multi-tenant HITL: the architectural patterns that make the same agent infrastructure safely serve many customers, with the data isolation, the reviewer isolation, the policy isolation, and the audit trail isolation that the multi-tenant reality requires.
The Multi-Tenant Reality
The multi-tenant reality has five dimensions:
Dimension 1: Data Isolation
Each customer's data must be isolated from every other customer's data. The agent cannot retrieve documents from Customer A when serving Customer B. The agent cannot use Customer A's history to inform Customer B's action. The LLM prompt cannot mix Customer A's context with Customer B's context.
The data isolation is fundamental to the GDPR and equivalent regulations. The isolation is enforced at the storage layer (separate databases), the retrieval layer (separate indexes), the prompt layer (separate context windows), and the audit layer (separate logs).
Dimension 2: Compliance Regime per Tenant
Each customer's compliance regime may differ. A German customer operates under GDPR + country-specific regulations. A US healthcare customer operates under HIPAA. A US financial customer operates under SOX. A defense customer operates under ITAR.
The same action — processing a refund — may have different approval requirements, different reviewer pools, different audit trail retention, different discoverability rules depending on which customer the action serves.
Dimension 3: Reviewer Pool per Tenant
The customers want their own reviewers. Customer A's reviewers are Customer A's employees — they work for Customer A, they review Customer A's actions, they make decisions in Customer A's interest. Customer B's reviewers are Customer B's employees — different team, different expertise, different priorities.
The same agent infrastructure cannot route all actions to a shared reviewer pool. The customers want (and often require, by contract and regulation) their own reviewers. The HITL system must route per tenant.
Dimension 4: Policy per Tenant
Each customer has their own policies. Customer A's refund threshold is $500. Customer B's threshold is $2000. Customer A requires two-reviewer approval above $5000. Customer B requires senior reviewer approval above $10,000. Customer A's timeout is 5 minutes. Customer B's timeout is 30 minutes.
The same agent infrastructure must apply different policies for different tenants. The policy is not global — the policy is per tenant. The manifest is per tenant.
Dimension 5: Audit Trail per Tenant
Each customer's audit trail must be isolated from every other customer's audit trail. Customer A's audit trail cannot be accessible to Customer B (nor to reviewers who work for Customer B). The retention rules are per tenant. The discoverability rules are per tenant. The integrity proof is per tenant.
The audit trail is the regulatory evidence. The audit trail's integrity must be provable per tenant. The audit trail cannot be co-mingled with another tenant's data.
Why Single-Tenant HITL Fails in Multi-Tenant Reality
Single-tenant HITL designs fail in three ways when applied to multi-tenant reality:
Failure 1: The Shared Reviewer Breach
The agent proposes an action for Customer A. The system routes the action to a shared reviewer pool. The reviewer works for the deployer, not for Customer A. The reviewer sees Customer A's data — including potentially sensitive customer information, financial details, health records, contract terms.
The reviewer is not authorized to see Customer A's data. The reviewer's access violates the data processing agreement. The reviewer's decision (approve/reject) is made by someone who should not have seen the data.
The shared reviewer pattern is a fundamental breach of data isolation. Every action routed through the shared reviewer violates the customer's data protection. The deployment is non-compliant from the first action.
Failure 2: The Cross-Tenant Policy Contamination
The agent serves Customer A and Customer B. The policy for Customer A says "approvals above $1000 need senior review." The policy for Customer B says "approvals above $5000 need senior review." The single-tenant policy picks one threshold — and applies it to both customers.
Customer A's actions above $5000 get senior review (correct). Customer A's actions between $1000 and $5000 don't get senior review (wrong — Customer A's policy requires it).
Customer B's actions between $1000 and $5000 get senior review (wrong — Customer B's policy doesn't require it). The cross-tenant contamination produces wrong coverage for both customers. Neither customer's policy is correctly enforced.
Failure 3: The Audit Trail Mixing
Customer A's action is logged alongside Customer B's action. The audit trail is a single stream. The discoverability is global. The retention is a single rule. The integrity proof covers both customers' actions as one set.
When Customer A's regulator asks for Customer A's audit trail, the response includes Customer B's actions. The cross-tenant contamination in the audit trail is a regulatory violation. When Customer A sues for data breach, the audit trail shows Customer B's reviewers had access to Customer A's data. The audit trail is evidence of the breach.
The Multi-Tenant HITL Architecture
The multi-tenant HITL architecture has six layers:
Layer 1: Tenant Identification
Every action the agent proposes is tagged with a tenant identifier. The tenant identifier is the primary key for all routing, policy evaluation, and audit trail storage.
The tenant identifier is established at agent initialization — when the agent starts serving a request from Customer A's system, the agent is initialized with Customer A's tenant context. The context cannot change during the agent's execution for that request. The tenant isolation is enforced by the runtime.
Layer 2: Tenant-Scoped Policy
The policy manifest is per tenant. Each customer has their own manifest. The manifest specifies:
- Action types and classifications
- Thresholds and risk indicators
- Reviewer pool assignments
- Timeout rules and fallback behavior
- Audit trail retention and discoverability
The agent runtime loads the tenant's manifest at execution time. The same action type can have different policies for different tenants. The policy is always evaluated in the tenant's context.
Layer 3: Tenant-Scoped Reviewer Pool
The reviewer pool is per tenant. The pool is defined in the manifest. The pool contains:
- Reviewer identities (employees of the customer)
- Roles (tier 1, tier 2, senior reviewer)
- Authentication credentials (managed by the customer or by the deployer on the customer's behalf)
- Access control (the reviewer can only see the tenant's data)
The reviewer pool is loaded at routing time. The routing respects the pool structure. The escalation chains follow the pool definition.
Layer 4: Tenant-Scoped Context
The context provided to the reviewer is tenant-scoped. The reviewer sees:
- The action proposed for the tenant
- The agent's reasoning for the tenant
- The relevant context from the tenant's data
- The relevant history from the tenant's interactions
The reviewer does not see:
- Other tenants' actions
- Other tenants' context
- Other tenants' history
- The cross-tenant patterns (reviewer metrics aggregated across tenants)
The context is filtered by the tenant boundary. The filtering is enforced at the data layer, not at the interface layer. The reviewer cannot navigate to other tenants' data even if they try.
Layer 5: Tenant-Scoped Audit Trail
The audit trail is per tenant. Each entry is tagged with the tenant identifier. The audit trail is stored in a tenant-scoped namespace. The retention rules are per tenant. The discoverability is per tenant.
The audit trail's integrity proof is per tenant — each tenant has its own cryptographic chain, its own WORM storage, its own integrity verification. A breach in one tenant's audit trail (or a regulator's review of one tenant's audit trail) does not affect another tenant's audit trail.
Layer 6: Tenant-Scoped Aggregated Metrics
The aggregated metrics — the override rate, the doubt-outcome correlation, the reviewer patterns — are per tenant by default. The deployer can choose to aggregate across tenants for operational visibility, but the reviewer pool never sees cross-tenant metrics.
The per-tenant metrics enable the deployer to improve each tenant's HITL system without exposing one tenant's patterns to another. The improvements are tenant-specific. The lessons learned can be applied to other tenants — but only at the deployer's discretion, with explicit tenant consent.
The Tenant Isolation Mechanisms
The tenant isolation has six enforcement mechanisms:
Mechanism 1: Tenant Identity Verification
Every request to the agent includes the tenant identity. The identity is verified (signed JWT, mTLS, API key) before the agent starts executing. The verified identity is propagated through every component — the policy engine, the reviewer interface, the audit trail.
A request without a verified identity is rejected. An action with a mismatched identity between proposal and execution is rejected. The tenant identity is non-negotiable.
Mechanism 2: Policy Tenant Binding
The policy manifest is bound to a tenant at deploy time. The manifest's signature includes the tenant identifier. The signature is verified at load time. A manifest for Tenant A cannot be loaded into a policy engine running for Tenant B.
The binding prevents policy cross-contamination. The policy engine for Tenant A only ever evaluates Tenant A's manifest.
Mechanism 3: Reviewer Tenant Authentication
The reviewer's authentication includes the tenant identifier. The reviewer logs in to Tenant A's review interface (with Tenant A's credentials). The reviewer cannot access Tenant B's interface even with the correct credentials for Tenant A.
The authentication is per tenant. The reviewer pool is per tenant. The access control is per tenant.
Mechanism 4: Data Retrieval Tenant Filtering
The retrieval layer filters by tenant. The agent's retrieval query includes the tenant identifier. The retrieval returns only documents for the specified tenant. The retrieval cannot return cross-tenant documents by accident or by design.
The filtering is enforced at the storage layer (separate indexes per tenant) and at the query layer (the tenant identifier is required and validated).
Mechanism 5: Audit Trail Tenant Partitioning
The audit trail is stored in tenant-scoped partitions. The partitioning is enforced at the storage layer (separate databases or separate schemas). The audit trail for Tenant A is in a different partition than the audit trail for Tenant B.
The partitioning cannot be bypassed. A query for Tenant A's audit trail cannot return Tenant B's entries. A regulator's request for Tenant A's audit trail receives only Tenant A's entries.
Mechanism 6: Cross-Tenant Access Detection
The system monitors for cross-tenant access attempts. A reviewer trying to access Tenant B's data from Tenant A's interface is flagged. A retrieval query without a tenant identifier is flagged. An audit trail query that spans tenants is flagged.
The detection is part of the security monitor. The flagged attempts trigger alerts. The incidents are investigated.
The Multi-Tenant Deployment Patterns
The multi-tenant HITL deployments follow three patterns:
Pattern 1: Shared Agent, Tenant-Scoped HITL
The agent infrastructure is shared across tenants. The HITL components (policy engine, reviewer interface, audit trail) are tenant-scoped. The deployer operates the shared agent; each tenant operates their own HITL components.
This pattern is common for SaaS deployments where the deployer provides the agent and each customer operates their own oversight. The deployer manages the technical infrastructure. The customer manages the policy and the reviewers.
Pattern 2: Shared HITL Platform, Tenant-Scoped Policy
The HITL infrastructure (reviewer interface, audit trail, policy engine) is shared across tenants. The policy, the reviewer pools, and the audit trail retention are per tenant. The deployer manages the HITL platform; each customer configures their policy and their reviewer pool.
This pattern is common for managed HITL services. The deployer provides the platform; the customer provides the policy and the people.
Pattern 3: Fully Tenant-Scoped
Every component — agent, policy engine, reviewer interface, audit trail — is tenant-scoped. The deployer may manage the infrastructure, but every customer's deployment is isolated at every layer.
This pattern is common for regulated industries (healthcare, defense, financial services) where multi-tenancy at any layer is non-compliant. The customer wants (and often requires) full isolation.
The Compliance Patterns
The multi-tenant HITL architecture supports the compliance patterns each customer requires:
GDPR / DSGVO Compliance
Data isolation (Layer 1, Mechanism 4) ensures the customer's data is not shared across tenants. Audit trail partitioning (Mechanism 5) ensures the customer's data subject access requests can be answered with the customer's data only. The retention rules are per tenant.
HIPAA Compliance
The data isolation, the reviewer authentication, the audit trail partitioning, and the integrity proof all support HIPAA's requirements. The customer can configure the retention and discoverability per the HIPAA rules. The business associate agreement is supported by the technical controls.
SOX Compliance
The audit trail integrity, the retention rules, the two-reviewer approval for financial actions — all supported by the multi-tenant HITL architecture. The customer can configure the SOX-specific requirements in their manifest.
ITAR / FedRAMP Compliance
The fully tenant-scoped deployment pattern (Pattern 3) supports the most demanding compliance regimes. The infrastructure, the policy, the reviewers, the audit trail are all isolated. The deployer provides the platform; the customer controls the deployment.
The Multi-Tenant Reviewer Experience
The reviewer experience is per tenant. The reviewer logs in to their tenant. The reviewer sees their tenant's actions. The reviewer makes decisions in their tenant's context. The reviewer does not see other tenants.
The reviewer's metrics are per tenant. The reviewer's calibration is per tenant. The reviewer's training is per tenant. The reviewer's recognition is per tenant.
The reviewer may work for the customer directly, or they may work for a managed service provider that serves multiple customers. Either way, the experience is per tenant. The reviewer never sees cross-tenant context.
The Deployer's Operational Experience
The deployer operates the multi-tenant infrastructure. The operational experience:
- Per-tenant dashboards: each tenant has their own dashboard with their own metrics, their own alerts, their own queue depth
- Cross-tenant operational metrics: the deployer can see aggregate metrics across tenants (but not reviewer identities, not action content, not customer data)
- Tenant isolation tests: regular tests that verify the isolation is working (the cross-tenant access attempts are blocked)
- Tenant onboarding: the deployer onboards new tenants with their own manifest, their own reviewer pool, their own audit trail
- Tenant offboarding: the deployer offboards tenants with full data deletion (the customer's data, the audit trail, the policy manifest)
The deployer is the operator. The customer is the data owner. The reviewer is the customer's employee. The model is the deployer's choice. The boundaries are clear.
What Changes When Multi-Tenant HITL Is Right
When the multi-tenant HITL architecture is correctly implemented:
- Each customer's data is isolated from every other customer's data
- Each customer's compliance regime is enforced per the manifest
- Each customer's reviewer pool makes decisions in the customer's interest
- Each customer's audit trail is preserved per the retention rules
- Each customer's HITL system improves through their own review patterns
The deployer can scale to many customers without cross-tenant contamination. The customers can trust the deployer with their data because the isolation is proven. The regulators can audit one customer without seeing another's data. The system can grow while preserving the boundaries.
Where Facio Fits
Facio's runtime enforces tenant isolation at every layer. The tenant identity is verified at every request. The policy engine loads the tenant-scoped manifest. The reviewer interface enforces the tenant boundary. The audit trail is partitioned by tenant.
Facio's policy engine supports per-tenant manifests. Each customer has their own manifest. The manifests are signed, versioned, and isolated. The same agent infrastructure can serve many customers with different policies.
Placet.io's review interface is multi-tenant by design. The reviewer logs in to their tenant. The reviewer sees only their tenant's actions. The reviewer makes decisions in their tenant's context. The interface enforces the tenant boundary.
The audit trail is partitioned per tenant. The retention rules are per tenant. The discoverability rules are per tenant. The integrity proof is per tenant. The regulator's request for one tenant's audit trail receives only that tenant's data.
Facio is built for multi-tenant reality. The HITL system that doesn't serve multi-tenant reality is the HITL system that doesn't survive enterprise deployment.
Key Takeaways
- Multi-tenant HITL is the architecture that serves enterprise AI — same agent infrastructure, dozens of customers, different data, different compliance
- Five dimensions of multi-tenant reality: data isolation, compliance regime, reviewer pool, policy, audit trail
- Three single-tenant failures: shared reviewer breach, cross-tenant policy contamination, audit trail mixing
- Six architectural layers: tenant identification, tenant-scoped policy, tenant-scoped reviewer pool, tenant-scoped context, tenant-scoped audit trail, tenant-scoped metrics
- Six isolation mechanisms: identity verification, policy binding, reviewer authentication, retrieval filtering, audit partitioning, access detection
- Three deployment patterns: shared agent with tenant-scoped HITL, shared HITL platform with tenant-scoped policy, fully tenant-scoped
- Compliance patterns supported: GDPR, HIPAA, SOX, ITAR, FedRAMP — each customer's regime is enforced
- Facio + Placet.io are built for multi-tenant — tenant isolation at every layer, signed manifests, partitioned audit trail, multi-tenant review interface
Sources: The multi-tenant HITL analysis draws on multi-tenant SaaS architecture patterns (the design of multi-tenant databases, multi-tenant isolation, multi-tenant security), the established compliance requirements for data isolation (GDPR Art. 28, HIPAA §164.504, SOC 2 CC6.1), and the production realities of HITL deployments in B2B SaaS contexts where dozens of customers share agent infrastructure during 2025-2026.