Права доступа определяют, кто или что может читать, создавать, изменять и удалять данные. Для ИИ-агента, бота или интеграции это граница возможного ущерба: чем шире доступ, тем больше последствий может вызвать ошибка или компрометация.

Целевая архитектура доступа

Безопасная схема строится из трёх связанных ограничений:

  1. Отдельная идентичность. Каждый агент и каждая интеграция используют собственное подключение или токен.
  2. Минимальный набор операций. Разрешены только действия, необходимые для конкретной задачи.
  3. Минимальная область данных. Подключению открыты только нужные страницы, базы, таблицы или другие ресурсы.
flowchart LR
    A[Задача агента] --> B[Отдельная идентичность]
    B --> C[Нужные операции]
    C --> D[Нужные ресурсы]
    D --> E[Журналы и регулярная проверка]

NIST определяет принцип минимальных привилегий (least privilege) как предоставление пользователю или процессу только тех ресурсов и полномочий, которые нужны для выполнения назначенной задачи. В архивном проекте NIST о ролевой модели управления доступом разрешения объединяются в роли, а роли назначаются пользователям.

Для подключения Notion аналогичную идею границ реализуют сочетанием доступа к ресурсам и возможностей API.

📌
Агенту нужен не «доступ на всякий случай», а заранее описанный набор ресурсов и операций для одной рабочей задачи.

Почему полный доступ опасен

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

Основные риски:

  • Случайное изменение или удаление. Ошибка затрагивает данные, которые не относятся к задаче агента.
  • Компрометация токена. Получивший секрет наследует доступ, разрешённый соответствующему подключению.
  • Каскадная ошибка. Изменение общей настройки может нарушить работу других процессов.
  • Расширение доступа через иерархию. В Notion доступ к родительской странице или базе данных распространяется на дочерние ресурсы.
  • Сложный разбор инцидента. Один общий токен может осложнить установление, какая интеграция выполнила действие.
⚠️
Не выдавайте агенту административные права, если его задача сводится к чтению, созданию или обновлению контента в ограниченной области.

Роли и разрешения решают разные задачи

Роль объединяет разрешения для типового участника. Конкретный состав роли зависит от системы и рабочей задачи. Названия ролей и их границы в таблице ниже условны.

РольТипичный доступПрактическая граница
АдминистраторНастройки, участники, права и данныеТолько для владельцев системы и администраторов
РедакторСоздание и изменение контентаОбычно без управления доступом к странице; точная граница зависит от системы
Агент или ботОперации, необходимые одному процессуТолько выделенные ресурсы и разрешённые действия
ИнтеграцияВызовы определённых APIОтдельный токен и минимальные возможности
ЧитательПросмотрБез изменения и предоставления доступа к странице

Запрет опасных операций полезен как исходная настройка, но не универсален. Если автоматизации действительно требуется удаление или управление доступом, вынесите это в отдельный процесс с узкой областью действия, проверкой условий и журналированием.

Как устроен доступ подключений Notion

На дату проверки, 8 сентября 2026 года, доступ подключения в Notion удобно рассматривать как сочетание двух уровней: доступа к содержимому и возможностей подключения.

1. Доступ к содержимому

Страница или база данных должна быть вручную предоставлена подключению. Без этого API-запрос к ресурсу завершится ошибкой.

Если подключению предоставили страницу или базу данных, оно получает доступ к этому ресурсу и его дочерним ресурсам. Какие действия доступны внутри этой области, дополнительно определяют возможности подключения.

Поэтому безопаснее делиться узким рабочим разделом, а не верхним уровнем пространства.

2. Возможности подключения

Возможности (capabilities) определяют, какие операции и связанные с пользователями сведения доступны через API. Подробное описание приведено в документации Notion по возможностям подключений.

  • Read content — чтение существующего содержимого.
  • Insert content — создание нового содержимого. Эта возможность сама по себе не даёт доступа к чтению полных объектов.
  • Update content — изменение существующего содержимого. Эта возможность сама по себе не позволяет создавать новые страницы.
  • Read comments и Insert comments — отдельные возможности для чтения и добавления комментариев.
  • Уровень доступа к сведениям о пользователях можно ограничить: от полного запрета такой информации до передачи данных с адресами электронной почты.

Возможности можно комбинировать. Подключению, которое только создаёт новые страницы или блоки в доступной области, может хватить Insert content. Экспортёру данных обычно достаточно Read content, а процессу, который меняет существующую страницу или блок, — Update content.

⚖️
Доступ к странице и возможности подключения дополняют друг друга. Разрешение Update content само по себе не открывает все страницы пространства, а предоставленная страница не отменяет ограничений возможностей API.

Права людей и постраничный доступ в базах Notion

Для участников рабочего пространства Notion поддерживает уровни доступа от просмотра до полного доступа. Дочерние страницы наследуют права родительской страницы, а при пересечении нескольких правил действует наиболее широкий предоставленный доступ.

В базах доступны отдельные уровни, включая уровень «может редактировать содержимое» (Can edit content). Он позволяет создавать и изменять страницы базы и значения их свойств, но не менять структуру базы, свойства, представления, сортировки и фильтры.

На тарифах Business и Enterprise можно настроить постраничный доступ по свойству пользователя (person) или свойству Created by. Это позволяет выдать человеку доступ только к назначенным ему записям, даже если база целиком ему недоступна.

Если у человека нет доступа к базе как к целому, он не откроет базу целиком. Назначенная запись может быть доступна через уведомление или связанное представление (linked view).

⚠️
Постраничное правило не ограничит участника, если он уже получил более широкий доступ через рабочее пространство, группу, командное пространство или другое правило. После настройки проверьте итоговый доступ тестовой учётной записью.

Постраничные правила для участников и доступ API-подключения — разные механизмы. Для подключения по-прежнему проверяйте выбранные страницы, дочерние ресурсы и его возможности.

Эталонная схема для контент-агента

Используйте этот шаблон как отправную точку:

КомпонентНастройкаПроверка
ИдентичностьОтдельное подключение для агентаТокен не используется сайтом, другим ботом или сотрудником
ОбластьТолько рабочая страница или базаПриватная контрольная страница недоступна
ОперацииНапример, чтение и обновление без лишних возможностейРазрешённый запрос проходит, запрос вне области или без нужной возможности отклоняется
СекретПеременная окружения или менеджер секретовТокена нет в коде, репозитории и диагностических сообщениях
КонтрольВладелец подключения и журнал действий, если их поддерживает стекДействие можно связать с конкретным запуском

Порядок настройки в Notion

  1. Создайте отдельное подключение для конкретного агента.
  2. Включите только нужные возможности содержимого, комментариев и пользовательских данных.
  3. Предоставьте подключению наиболее узкую подходящую страницу или базу.
  4. Проверьте, какие дочерние страницы и ресурсы стали доступны вместе с ней.
  5. Храните токен вне исходного кода: в переменной окружения или менеджере секретов. При прямых REST-запросах передавайте его в заголовке Authorization: Bearer <TOKEN> и указывайте Notion-Version: 2026-03-11 и Content-Type: application/json, как показано в руководстве Notion по авторизации. Перед внедрением сверяйте актуальную версию API.
  6. Выполните разрешённое действие на тестовой записи.
  7. Убедитесь, что подключение не читает контрольную приватную страницу и не выполняет запрещённую операцию.
  8. Зафиксируйте владельца подключения и порядок отзыва доступа.

Проверка результата

Проверьте оба уровня доступа на тестовой странице и отдельной приватной контрольной странице:

  1. Разрешённый запрос к расшаренному ресурсу проходит и возвращает ожидаемое содержимое или состояние.
  2. Запрос к странице, которая не предоставлена подключению, завершается ошибкой доступа.
  3. Подключение только с Read content может вызвать операцию получения базы (Retrieve a database), но не может вызвать Update database. Подключение только с Update content может изменять существующую страницу, но не создавать новые страницы.

Успешная проверка означает, что разрешённое действие выполнено, ресурс вне области недоступен, а операция без нужной возможности отклонена.

Когда пересматривать и отзывать доступ

Проверяйте права после изменения задачи агента, структуры страниц или состава команды. Рассмотрите замену или отзыв токена при подозрении на утечку, случайной публикации секрета, завершении работы подрядчика или выводе интеграции из эксплуатации.

Не полагайтесь только на смену токена. Если область доступа или возможности подключения изначально слишком широки, новый секрет сохранит ту же проблему.

Чеклист быстрой проверки

У каждого агента и каждой интеграции отдельная идентичность
Назначен владелец подключения
Описана конкретная задача агента
Включены только необходимые возможности API
Открыты только нужные страницы, базы или другие ресурсы
Проверено наследование доступа дочерними страницами
Административные и деструктивные действия закрыты либо вынесены в отдельный контролируемый процесс
Токены отсутствуют в коде, репозитории и журналах
Секреты хранятся в переменных окружения или менеджере секретов
Разрешённый сценарий проверен на тестовых данных
Запрещённая операция действительно отклоняется
Доступ к контрольному приватному ресурсу отсутствует
Действия интеграции можно связать с конкретным запуском
Определены условия отзыва и замены токена
Права пересматриваются после изменений процесса или структуры данных

Официальные источники и документация

Страница проекта NIST по RBAC помечена как архивная: проект больше не поддерживается, содержание не обновляется и может быть устаревшим. Детали конкретной системы проверяйте в её актуальной документации.

Следующий шаг

Notion + ИИ: что можно доверить агенту, а что должен решать человек

Если вы проектируете доступ для агентов и интеграций, полезно заранее разобрать рабочие сценарии, границы данных и последствия ошибок.

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov