Простая аналогия: у каждого документа есть список людей и групп, которым можно его открыть. Если пользователя нет в списке или у его группы нет нужного права, система не должна показывать документ, даже если AI-агент нашел его через поиск.
В AI-системах ACL особенно важен для RAG и внутреннего поиска. Агент может индексировать документы из Google Drive, Confluence, Notion, CRM или корпоративной wiki. Но при ответе он должен использовать только те фрагменты, которые доступны конкретному пользователю. Иначе ассистент случайно расскажет сотруднику из отдела продаж данные из финансового отчета или юридического договора.
ACL отличается от RBAC. RBAC обычно говорит: у пользователя роль «менеджер», «админ», «юрист» или «поддержка». ACL говорит точнее: у этого пользователя или группы есть доступ именно к этому документу, задаче или записи. На практике они часто работают вместе: роль задает общие возможности, ACL ограничивает доступ к конкретным объектам.
Для AI-агента ACL нельзя заменять промптом. Фраза «не показывай закрытые документы» полезна, но недостаточна. Фильтрация должна происходить до генерации ответа: при retrieval, чтении файла, вызове API и tool calling. Модель должна получать только разрешенные данные, а опасные действия должны дополнительно проверяться в backend.
Хорошая реализация хранит права доступа в metadata: owner, workspace_id, document_id, groups, roles, visibility, sensitivity, allowed_users, denied_users, updated_at. Перед выдачей фрагмента в контекст система сверяет эти данные с текущим пользователем. После ответа полезно писать audit log: кто спросил, какие источники были использованы и какие действия агент пытался выполнить.
Главные риски: индексировать закрытые документы без прав, проверять ACL только на уровне интерфейса, но не retrieval, кэшировать ответы между пользователями, смешивать общие и приватные источники, давать агенту service account с лишними правами и не учитывать отозванные доступы. Для корпоративного AI это одна из самых частых причин утечек.
Примеры
- В Google Drive документ доступен только отделу финансов. RAG-агент не должен использовать его фрагменты в ответе менеджеру по продажам.
- В Confluence страница с внутренними регламентами HR открыта только группе hr-team. ACL хранится в metadata и проверяется перед добавлением фрагмента в контекст модели.
- В CRM менеджер видит только свои сделки и сделки своей команды. AI-агент не должен отвечать по чужим сделкам, даже если они есть в общей базе.
- В Slack агент может читать публичный канал, но не приватный канал руководства, если бот туда не добавлен и у пользователя нет доступа.
- При tool calling агент хочет скачать файл. Backend проверяет ACL файла и права пользователя до вызова API, а не после генерации ответа.
Где используется
- фильтрация документов в RAG по правам конкретного пользователя
- внутренний поиск по Google Drive, Notion, Confluence и корпоративной wiki
- ограничение доступа AI-агента к CRM, задачам, договорам и финансовым данным
- разделение публичных, внутренних, конфиденциальных и персональных источников
- проверка прав перед tool calling и API-действиями
- защита от утечек между отделами, командами и клиентскими workspace
- audit log использованных источников и действий агента
- реализация принципа least privilege для service accounts
- пересчет индекса после изменения прав доступа
- тестирование AI-системы на доступ к запрещенным документам
Связанные термины
Частые вопросы
Что такое ACL простыми словами?
ACL - это список, где написано, кто может работать с конкретным объектом и что именно может делать. Например: этот документ можно читать группе sales, редактировать владельцу и нельзя показывать остальным.
Зачем ACL нужен AI-агенту?
AI-агент часто ищет по документам, CRM, задачам и файлам. ACL нужен, чтобы агент отвечал только по тем данным, которые разрешены конкретному пользователю. Без этого RAG и внутренний поиск могут случайно раскрыть закрытую информацию.
Чем ACL отличается от RBAC?
RBAC управляет доступом через роли: админ, менеджер, юрист, поддержка. ACL управляет доступом к конкретному объекту: этому файлу, этой странице, этой сделке. В зрелых системах роли и ACL обычно работают вместе.
Можно ли настроить ACL только промптом?
Нет. Промпт может напомнить модели правило, но не является надежной защитой. ACL нужно проверять в коде: до retrieval, перед чтением файла, перед вызовом инструмента и перед записью данных.
Какие данные хранить в metadata для ACL?
Обычно хранят owner, workspace_id, document_id, список групп, список пользователей, уровень видимости, sensitivity, дату обновления прав и источник. Эти поля нужны, чтобы фильтровать фрагменты до передачи модели.
Какие ошибки чаще всего приводят к утечкам через AI?
Частые ошибки: индексировать все документы под админским аккаунтом, не фильтровать retrieval по пользователю, кэшировать ответы между пользователями, забывать обновлять права после изменения доступа и давать агенту слишком широкие API-разрешения.
