Achilles — Auth: Авторизация и ACL

1 Роли → Admin Panel Кто пользователь на платформе.

Owner

Полный доступ
Управление админами
Критичные настройки

Admin

Пользователи
Источники
Company-агенты
Мониторинг

Member

Запросы
Личные агенты
Данные в рамках ACL

Team Lead — capability, не роль v2 → Agent Engine

Member получает права на свою команду: управление её агентами и настройками.

2 Проверка прав Можно ли это действие.

Абстракция require()

Эндпоинт проверяет наличие нужного permission, а не конкретную роль.

как

В v1 require() сопоставляет permission с ролью по статической таблице ROLE_PERMISSIONS. Сюда же подключится тонкая настройка прав из v2.

RBAC middleware

FastAPI-зависимость — единая точка проверки: принимает требуемый permission, не роль. Роль на эндпоинтах напрямую не проверяется.

смена роли

Роль берётся из claim access-токена — её свежесть и чтение из БД для критичных проверок описаны в JWT claims.

Проверка владения ресурсом

RBAC отвечает «можно ли действие вообще», владение — «над своим ли объектом». Личные агенты и API-ключи доступны только владельцу: эндпоинт сверяет owner_id ресурса с текущим user_id поверх permission. Защита от IDOR.

v2 Командное владение — доступ участников к ресурсам своей команды — появляется с capability Team Lead.

зачем поверх RBAC

Без проверки владения один Member редактировал бы агента другого — типовой IDOR. Owner / Admin обходят проверку владения только там, где это их штатная зона (управление пользователями), не для доступа к данным источников.

Граница админских прав

Owner и Admin видят данные строго в рамках source ACL, как Member. Сквозного обхода ACL по роли нет.

break-glass и аудит

Экстренный доступ в обход source ACL — это отдельная явная настройка с обязательной записью в журнал. Admin Panel.

Гранулярные permissionsv2

Таблицы permissions и user_permissions дают тонкую настройку прав поверх ролей.

детали и приоритет

Позволяют расширить или урезать права отдельного пользователя. Назначаются через Admin Panel. Приоритет однозначный: явный запрет (deny) важнее любого разрешения — от роли или точечного гранта. Сначала складываются гранты (роль + расширения), затем вычитаются deny.

3 Идентичность Внешние идентичности пользователя.

Таблица identity_mapping → Модель данных

Связывает пользователя платформы с его внешними логин-идентичностями — универсальный мост входа: боты мессенджеров (source='slack' · 'telegram' · 'mattermost', v1), SSO-провайдеры (Okta, Azure AD, v2). Поля и ограничения — в модели данных.

наполнение

При старте пустая — наполняется при входе через любой источник: в v1 это боты Slack, Telegram и Mattermost.

Личности из контент-источников — в Knowledge Store → Knowledge Store

Кто пользователь в Jira / Slack / Confluence — это source_principal → identity в Knowledge Store, не здесь. Мост к платформенному аккаунту — identity.user_id → users: так логин-федерация и контент-личности не смешиваются в одной таблице.

Свод личностей по email → Knowledge Store

Люди источника сводятся в одну identity только по точному email; Harvester производит. Нечёткое «разные email, тот же человек» — v2 (deep entity resolution).

несовпавшие

Нет email, коллизия или неоднозначность — запись остаётся unmatched и уходит в ручную привязку администратором через Admin Panel.

Мост к аккаунту — авто-связь по email → Knowledge Store

Когда человек заводится в платформе — инвайт принят, setup, смена email админом — его users связывается с уже существующей identity того же свода Knowledge Store по точному email (identity.user_id). Так вошедший сразу видит свои аккаунты в источниках. Правило и хранение — в Knowledge Store; здесь — момент срабатывания со стороны входа.

адрес не совпал

Email входа ≠ email в источнике — личность остаётся без моста и привязывается вручную в Admin Panel; нечёткое авто-сведение по разным адресам — v2.

4 ACL данных → Knowledge Store → Harvester → Query Engine Что пользователю доступно.

Подход — Hybrid, маппинг при запросе

Source ACL хранится в оригинальных терминах источника в Knowledge Store. При запросе платформа резолвит аккаунты пользователя и фильтрует выдачу pre-filter'ом: запрос ведёт Query Engine, фильтр исполняется в хранилище одним SQL.

принцип

Кто что видит, определяет только сам источник.

Container-level ACL

Права задаются на контейнерах (Jira-проект, Confluence-пространство, Slack-канал), а вложенные сущности их наследуют.

override

Ограничения на отдельный документ важнее контейнерных и переопределяют их.

Двойной фильтрv2

Доступ проверяется дважды: по source ACL и по платформенным ограничениям Admin Panel. Снять должны оба.

Fail-safe

Сквозной принцип всего слоя: по умолчанию доступ закрыт. Любая неоднозначность, ошибка проверки или нехватка данных о правах трактуется в пользу запрета — лучше не показать доступное, чем показать запрещённое.

5 Хранилище → Knowledge Store Где физически хранится ACL.

Хранение ACL

PostgreSQL — таблица entity_acl (source of truth)
Postgres-граф — node/edge-таблицы в той же базе; единый ACL-JOIN покрывает и обход, без отдельной проекции прав
pgvector — ACL-фильтр SQL WHERE/JOIN сужает множество до поиска → vector search top-N уже по разрешённому (pre-filter, не отсев после)