Изоляция клиентов для агентских AI-систем агентства

Прямой ответ

Никогда не смешивайте сырые базы знаний клиентов, учётные данные и память диалогов между арендаторами (tenant - отдельный клиент/аккаунт). Изолируйте по клиенту на уровне хранения, поиска и ключей инструментов. «Один огромный промпт со всеми клиентами» - это утечка, которая ещё не случилась.

Агентству удобно шарить инфраструктуру. Клиенту важно, чтобы его бренд, цены и переписка не всплыли у соседа.

Почему агентства ломают изоляцию

• Копипаст-операции: один чат, много клиентов.
• Общие ящики и общие админ-токены.
• Один vector store (хранилище эмбеддингов) «на всех».
• Промпт-шаблоны, куда вшиты факты клиента A и случайно уехали в сессию клиента B.
• Субподрядчики с вечным доступом «на всякий случай».

Слои изоляции

1. Auth и tenant id - каждый запрос несёт идентификатор клиента; без него инструменты молчат.
2. Ключи и секреты - отдельные credentials на клиента или строго scoped роли; не один master-ключ на агентство.
3. Индексы знаний - отдельные namespace / коллекции; по умолчанию не «одна БД на всех».
4. Память диалогов - сессии не пересекаются; history клиента A недоступна B.
5. Логи - отдельные потоки или жёсткая фильтрация по tenant, если нужен audit per client.

Промпты

Общие шаблоны навыков (skill templates) - нормально: «как отвечать на возврат», «как собрать бриф».
Факты клиента, цены, пароли, внутренние URL и имена сотрудников - никогда в общий system prompt.

Клиентский контекст подмешивается в runtime из изолированного store, а не «запекается» в общий мозг.

Маршрутизация multi-store

Если агентство ведёт много магазинов/брендов: явный brand/store id на каждый вызов инструмента. Никакого «угадай магазин по вайбу». Ошибочный store id = запись в чужой каталог.

См. также паттерн ops-агента на много магазинов.

Как вписывается Dali

Dali закладывает границы tenant в ops-агентов агентств: решения.