Обычно это делается через service account. Сам по себе service account не является обычным сотрудником и не может просто читать пользовательские данные. Super admin домена должен явно разрешить ему domain-wide delegation в Google Admin Console и указать, какие OAuth scopes ему доступны.
Простой пример: агент поддержки должен искать ответы в Google Drive команды, агент-ассистент должен создавать события в календарях сотрудников, а внутренний бот должен обрабатывать письма общего отдела. Вместо того чтобы каждый пользователь вручную давал consent, администратор выдает централизованное разрешение на уровне домена.
Это мощный и опасный доступ. Если выдать слишком широкие scopes, приложение сможет действовать почти как пользователь: читать письма, файлы, календари или управлять настройками. Поэтому domain-wide delegation используют только там, где обычный OAuth от конкретного пользователя не подходит.
Безопасная схема выглядит так: минимальные scopes, отдельный service account под конкретный сценарий, хранение ключей в secret manager, audit log, регулярный пересмотр доступов, тестовый домен или пилотная группа перед запуском на всю компанию.
Примеры
- AI-агент ищет документы в Google Drive от имени сотрудника и видит только те файлы, к которым у этого сотрудника есть доступ.
- Сервис создает встречи в Google Calendar для менеджеров без ручного подключения OAuth каждым пользователем.
- Система обрабатывает письма общего отдела через Gmail API и создает задачи в CRM.
- Администратор выдает service account scope только на чтение Drive, а не полный доступ ко всем Workspace API.
- После увольнения сотрудника агент больше не должен действовать от его имени, если workflow зависит от конкретного user email.
- Команда безопасности проверяет audit log и список authorized clients в Admin Console раз в месяц.
Где используется
- интеграция AI-агента с Google Workspace
- поиск по Google Drive и Docs
- автоматизация Gmail для отделов
- создание и чтение событий Google Calendar
- централизованный доступ к Workspace API
- корпоративные боты без consent каждого пользователя
- обработка документов в Google Drive
- синхронизация базы знаний компании
- безопасная интеграция внутренних сервисов
- администрирование Workspace через API
Связанные термины
Частые вопросы
Domain-wide delegation дает доступ ко всем данным домена?
Не автоматически. Доступ ограничивается OAuth scopes, которые super admin выдал приложению. Но даже один широкий scope может быть очень опасным.
Кто может включить domain-wide delegation?
Обычно это делает super admin Google Workspace в Admin Console: API Controls, Domain-wide delegation, client ID и список OAuth scopes.
Чем domain-wide delegation отличается от обычного OAuth?
При обычном OAuth каждый пользователь сам дает consent. При domain-wide delegation администратор разрешает приложению действовать от имени пользователей домена централизованно.
Когда лучше не использовать domain-wide delegation?
Если достаточно обычного OAuth, отдельного shared drive, API key без пользовательских данных или ручного подключения одного аккаунта, лучше выбрать более узкий вариант.
Какие меры безопасности обязательны?
Минимальные scopes, отдельный service account, запрет лишних операций, secret manager для ключей, audit log, approval на опасные действия и регулярная ревизия доступа.
Можно ли использовать DWD для AI-агента?
Да, но осторожно. Агент должен получать только нужные scopes, проверять права пользователя, логировать действия и не выполнять опасные операции без approval.
