AI-порталAI-портал

Tenant Isolation for AI в 2026: как не смешать контекст, логи и права между клиентами

Tenant isolation for AI в 2026: разделение prompts, retrieval, memory, traces, caches и tool permissions в multi-tenant LLM-системах.

Tenant isolation for AI в 2026 важна потому, что multi-tenant LLM-система смешивает сразу несколько чувствительных слоёв: prompts, retrieved docs, user memory, tool permissions, traces, caches и иногда даже human review artifacts. Если хотя бы один из этих слоёв не учитывает tenant boundary, система может утекать не только через базу данных, но и через assembled context, shared cache или observability.

Tenant isolation для AI — это не только про базу данных. Даже если таблицы разделены правильно, ошибка всё ещё может возникнуть в retrieval, prompt assembly, trace logging или review queue, где данные разных клиентов случайно оказываются рядом.
Самый опасный anti-pattern - думать, что tenant isolation заканчивается на row-level access в storage. Для LLM-приложения это только начало. Реальная утечка часто происходит позже: в кэше, assembled prompt, memory layer, observability или tool routing.

Короткая версия

У хорошей tenant isolation в AI-системе обычно есть минимум шесть границ:

  1. Data storage
  2. Retrieval / indexing
  3. Prompt assembly
  4. Memory and sessions
  5. Tracing / logs
  6. Tools / permissions / quotas

Что особенно важно

  • tenant key должен проходить через весь pipeline;
  • shared cache без tenant-aware keying опасен;
  • retrieval и observability требуют не меньшей изоляции, чем storage;
  • human review queue тоже может стать cross-tenant leak.
Без техники
База разделена по tenant_id, но retriever, cache и traces живут почти в общем пространстве.
С техникой
Tenant boundary enforced в storage, index, prompt assembly, cache keys, logs, review queue и tool permissions. Пересечение становится не случайностью, а явным инцидентом.
ПромптIsolation intuition
Где в AI-системе tenant leak часто возникает позже всего и поэтому недооценивается?
Ответ модели

Часто в observability, cache и human review artifacts. Базу обычно изолируют раньше, а вот assembled context и traces долго остаются полуобщими.

1. Изоляция должна проходить через весь pipeline

Полезно думать не "есть ли tenant_id в БД?", а "идёт ли tenant boundary до самого конца workflow?".

Критичные точки:

  • retrieval index;
  • prompt assembly;
  • session memory;
  • tool access;
  • traces and feedback;
  • approval/review artifacts;
  • provider usage attribution.

Если хотя бы один слой полуобщий, tenant isolation уже неполная.

2. Retrieval и cache особенно коварны

Даже при хорошей storage isolation можно ошибиться здесь:

  • shared vector index без tenant filter;
  • cache key без tenant dimension;
  • search snippets без provenance boundary;
  • stale summary memory reused across tenants.

Именно эти ошибки часто не видны как obvious database bug, но приводят к реальному leakage.

Если ответ может быть переиспользован из cache, в cache key почти всегда должны входить tenant, locale, policy version и route. Иначе оптимизация очень быстро становится cross-tenant risk.

3. Observability и review queues тоже требуют изоляции

Полезно отдельно думать о:

  • trace viewers;
  • annotation queues;
  • support/debug dashboards;
  • human review tools;
  • exported incident bundles.

Очень типичный failure mode:

  • основной ответ клиенту изолирован;
  • но trace или screenshot попадает в общую очередь review;
  • дальше утечка происходит уже через internal tooling.

4. Tool permissions должны быть tenant-aware

У разных tenants могут отличаться:

  • allowed integrations;
  • approval policy;
  • external domains;
  • budgets;
  • retention rules;
  • human review ownership.

Поэтому tenant isolation - это не только про data visibility, но и про control-plane policy.

5. Shared provider and gateway layers тоже опасны

Даже если все запросы идут через один gateway, нужно разделять:

  • project keys;
  • spend attribution;
  • rate limits;
  • usage visibility;
  • provider logs;
  • fallback behavior.

Иначе инфраструктурный слой начинает видеть и смешивать tenants сильнее, чем приложение предполагало.

6. Что особенно часто ломают команды

DB isolation only

Остальной pipeline живёт почти без tenant awareness.

Shared cache keys

Кэш не различает tenants.

Mixed review queues

Human review может открыть чужие артефакты.

Traces without access boundary

Observability tool показывает run-ы не тем людям.

Tenant-blind retrieval filters

Индекс знает про документы разных клиентов, но filter applied не везде.

7. Какие метрики полезны

Минимальный tenant-isolation dashboard обычно включает:

  • cross-tenant retrieval incidents;
  • cache cross-hit anomalies;
  • review artifact access by tenant;
  • trace access violations;
  • tool permission mismatches by tenant;
  • spend attribution drift.

Плюсы

  • Tenant-aware design снижает риск data leakage по всему AI pipeline
  • Кэш, retrieval и observability становятся безопаснее, а не только быстрее
  • Tenant-specific policies лучше отражают реальные enterprise требования
  • Изоляция review and trace tooling закрывает часто забытый класс рисков

Минусы

  • Усложняет cacheing, observability и platform architecture
  • Слишком грубая изоляция может снижать reuse и efficiency
  • Нужно протягивать tenant context через большее число систем
  • Без audits часть нарушений остаётся незаметной долгое время

Пример tenant-aware cache key

cache_key = hash(
  tenant_id
  + route
  + model
  + prompt_version
  + locale
  + normalized_input
)

Пример retrieval guard

def retrieve(query, tenant_id):
    return vector_index.search(
        query=query,
        filter={"tenant_id": tenant_id}
    )

Практический совет: tenant boundary стоит логировать так же явно, как trace_id. Если по трейсу нельзя быстро понять, к какому tenant относился run и кто имел право его видеть, изоляция почти наверняка неполная.

Проверьте себя

1. Почему tenant isolation в AI не заканчивается на базе данных?

2. Какой anti-pattern особенно опасен?

3. Что особенно часто забывают изолировать?

Источники

  1. OWASP Top 10 for LLM Applications
  2. Helicone Docs - Rate Limiting & Spend Controls
  3. LiteLLM Documentation
  4. OpenTelemetry - GenAI semantic conventions
Предыдущая
Synthetic Incident Drills в 2026: как репетировать поломки agent stack до реального инцидента
Следующая
Tenant-Aware Observability в 2026: как видеть деградацию по клиентам, а не по средней температуре