Как узнать, какие ИИ-инструменты имеют доступ к вашему Google Workspace

Вы можете увидеть все ИИ-инструменты с OAuth-доступом к вашему Google Workspace в консоли администратора, в разделе Security → Access and data control → API controls → App access control. Здесь перечислены все сторонние приложения, авторизованные в вашем домене — включая ИИ-ассистентов, расширения браузера и ботов для заметок со встреч — вместе с данными Google, к которым каждому из них предоставлен доступ.

В этом руководстве рассматривается этот путь, что консоль показывает на самом деле, где заканчиваются её возможности и как поддерживать список в актуальном состоянии, когда он у вас уже есть.

Где найти доступ сторонних приложений в консоли администратора Google?

1. Войдите в admin.google.com как супер-администратор или администратор с привилегией Services.
2. Перейдите в Menu → Security → Access and data control → API controls.
3. Нажмите Manage App Access (в некоторых версиях консоли обозначается как App access control).

Вы попадаете на список, разделённый на Configured apps (приложения, для которых ваша организация явно установила уровень доступа) и Accessed apps (все приложения, используемые в данный момент, независимо от того, настраивали вы их или нет). Для каждого приложения видно:

• Название приложения, издателя и OAuth client ID.
• Присвоен ли ему значок верификации Google.
• Отдельные запрашиваемые области доступа (scopes) к сервисам Google — Drive, Gmail, Calendar, Admin Directory и так далее — разворачиваемые для каждого приложения.
• Сколько пользователей в вашем домене авторизовали его.
• Уровень доступа, который можно задать: Trusted, Limited, Specific Google data или Blocked.

Вы также можете экспортировать весь список в формате CSV и применять разные уровни доступа к разным организационным подразделениям, а не ко всему домену сразу.

Как понять, какие из этих приложений — ИИ-инструменты?

Консоль Google никак не помечает приложения как «ИИ» — она перечисляет все подключённые через OAuth приложения одинаково, будь то надстройка для таблиц или ассистент на основе большой языковой модели. На практике ИИ-инструменты можно распознать по названиям вроде прямого указания ИИ-поставщика (OpenAI, Anthropic, Perplexity), бота для заметок со встреч (Otter.ai, Fireflies, Fathom), помощника для написания текстов (Grammarly, Jasper) или более узкой надстройки («GPT for Sheets and Docs», «AI Email Writer»), название издателя которой никак не намекает на её функцию. Их распознавание — это ручная работа по сопоставлению шаблонов: просматривайте названия приложений и издателей и проверяйте запрашиваемые области доступа — приложение, запрашивающее drive.readonly или gmail.readonly под незнакомым названием, стоит проверить внимательнее, независимо от категории.

Как проверить, какие ИИ-инструменты авторизовал конкретный человек?

Общедоменное представление, описанное выше, показывает, что у приложения есть пользователи; но оно не говорит, *кто именно* и *когда* его авторизовал. Для этого:

1. Перейдите в Menu → Directory → Users и откройте учётную запись нужного человека.
2. Откройте вкладку Security.
3. Прокрутите до раздела Connected applications.

В этом разделе перечислены все сторонние приложения, которые авторизовал этот конкретный пользователь, уровень доступа (какие области доступа приложение может использовать) и дата авторизации. Администратор с привилегией User Security Management может отозвать любое из этих разрешений прямо на этой странице. Это единственное место в консоли, где показано, *когда* приложение было авторизовано — но это означает проверку по одному человеку за раз, без массового экспорта и без возможности отфильтровать «только ИИ-инструменты».

В чём реальные ограничения ручной проверки?

Общедоменный экран App access control агрегирует количество пользователей, но не показывает детали по каждому из них; экран Connected Applications для отдельного пользователя содержит детали, но не даёт общего представления. Ни один из них не покажет вам:

• Используется ли доступ до сих пор, или он был предоставлен один раз и забыт.
• Что именно приложение сделало с данными, к которым у него есть доступ — консоль показывает, что оно *может* получить, а не то, что оно *получило*.
• Как картина менялась со временем, поскольку нет исторической хронологии предоставленных доступов или расширенных областей доступа.
• Какие из перечисленных приложений являются ИИ-инструментами — если вы сами не узнаёте каждого поставщика по названию.

Для Workspace с небольшим количеством подключённых приложений просмотр обоих экранов вручную вполне реалистичен. Когда речь заходит о нескольких десятках приложений и нескольких сотнях пользователей, поддержание списка в актуальном состоянии перестаёт быть разовой задачей и становится повторяющейся — та же информация проверяется заново, бесконечно. Причём оба экрана требуют роли администратора с соответствующей привилегией (Services для общедоменного представления, User Security Management для представления по отдельным пользователям) — организации с несколькими администраторами всё равно нужен человек, который регулярно проверяет оба экрана, а не задача, которая естественным образом достаётся тому, кто случайно это заметил.

Чего не покажет ручной просмотр и как на это отвечает 8200.dev?

Ручной путь отвечает на вопрос *что может получить доступ к данным*. Он не отвечает на вопрос *кто это использовал, когда и нужно ли это до сих пор* — а именно эти вопросы на самом деле определяют, должен ли доступ приложения сохраняться. Agent Guard от 8200.dev инвентаризирует всех ИИ-агентов и подключённые через OAuth приложения по всем вашим подключённым источникам в едином, постоянно обновляемом представлении, оценивает риск каждого из них и объясняет находку простым языком вместо строки со scope-значениями. Обнаружение производится только для чтения: подключение Google Workspace использует область доступа только для чтения метаданных Drive, а более глубокая инвентаризация OAuth-приложений, показанная выше, становится доступна после того, как организация включает аудит OAuth-приложений, что требует повторной авторизации с дополнительными областями доступа только для чтения Admin SDK, необходимыми Google именно для этого представления — ничто здесь само по себе не изменяет доступ; любое действие остаётся рекомендацией, пока организация не решит выполнить его.

Полный список коннекторов приведён в статье «full connector list» — там показано, как это распространяется за пределы Google Workspace на Microsoft 365, Slack, GitHub и самих ИИ-поставщиков.