Инспекция браузерного трафика¶

Частый вопрос: «Можно ли проверять, что сотрудник пишет, когда просто открывает chatgpt.com (или claude.ai, gemini.google.com, giga.chat) в браузере и общается в чате?»

Короткий ответ — да, браузерным расширением (на управляемой технике)¶

Раньше единственным способом был self-hosted UI (см. ниже). Теперь есть AIGate Browser Edge — браузерное расширение (Manifest V3), которое контролирует трафик в публичные ИИ-чаты прямо в браузере, на корп-технике.

Само по себе не работает — нужно развернуть расширение

Это не автоматическая/прозрачная инспекция. Без установленного на браузер расширения трафик «браузер → SaaS» по-прежнему не контролируется. Расширение нужно принудительно установить (force-install) на управляемую технику через MDM/GPO/Intune и задать ему адрес гейта и профиль (см. ниже). На личных и неуправляемых устройствах этот способ не применим — там остаётся управляемый self-hosted UI + ограничения на сетевом периметре.

Важно: это НЕ перехват TLS

Расширение не расшифровывает сетевой трафик и не подменяет сертификаты (MITM). Оно работает внутри браузера как content-script: перехватывает запрос на уровне JavaScript-страницы до того, как тот будет зашифрован и отправлен. Поэтому certificate pinning не мешает, а TLS не нарушается — контроль стоит на endpoint'е, а не в сети.

flowchart LR
    user["Пользователь<br/>в браузере"]
    ext["AIGate Browser Edge<br/>(content-script в браузере)"]
    gw["AppSec.AIGate"]
    saas["chatgpt.com / giga.chat / …<br/>(серверы вендора)"]

    user --> ext
    ext -->|"промпт ДО шифрования → scan"| gw
    gw -->|"вердикт"| ext
    ext ==>|"HTTPS (TLS), после проверки"| saas

    classDef ok fill:#e6f4ea,stroke:#34a853,color:#111;
    class ext,gw ok;

Что делает расширение¶

Перехватывает промпт пользователя в поддерживаемом ИИ-чате, отправляет его на тот же движок проверки, что и прокси/SDK (профиль AppSec.AIGate), и применяет вердикт в браузере:

ALLOW — запрос уходит вендору как есть;
SANITIZE — вендору уходит маскированный текст ([EMAIL], [PHONE]…);
BLOCK — отправка отменяется, показывается причина;
DEGRADED (гейт недоступен) — локальная on-device PII-маскировка + предупреждение.

Поддерживаемые сайты: ChatGPT, GigaChat, YandexGPT (Алиса), DeepSeek, Claude и self-hosted OpenWebUI. Перехват работает независимо от технических особенностей конкретного сайта. Политика (что маскировать/блокировать) задаётся профилем AppSec.AIGate — в расширении ничего не «зашито».

Поддержка сайтов и их обновление

Каждый поддерживаемый сайт настраивается под его веб-интерфейс. При значимом изменении интерфейса сайта поддержка обновляется централизованно; до обновления расширение само распознаёт, что перестало контролировать сайт, и предупреждает пользователя. Новый ИИ-сервис добавляется без изменений на серверной стороне.

Что видит пользователь¶

Режим	Что видит
ALLOW	ничего — прозрачно
SANITIZE	синий toast «данные замаскированы перед отправкой»
BLOCK	красный баннер «отправка заблокирована: <причина>» + ссылка на политику
DEGRADED	жёлтый баннер «ограниченный режим — PII замаскированы локально»
monitor-only	ничего (только серверный лог — режим наблюдения/rollout)

Развёртывание и настройка администратором¶

Расширение ставится принудительно на корп-технику и настраивается централизованно (managed-config). Пользователь ничего не меняет. Три шага.

Шаг 1. Создать `scan_only`-профиль¶

В Admin UI → Профили создайте профиль типа scan_only (без провайдера) и настройте детекторы (PII-маскировка, threat, content-safety, content-policy). Скопируйте UUID профиля. Это и есть «что считать нарушением».

Шаг 2. Опубликовать managed-config (адрес гейта + профиль)¶

gateUrl, profileId задаются в политике расширения через MDM/GPO/Intune. Пример для Chrome (Linux) — /etc/opt/chrome/policies/managed/aigate.json:

{
  "ExtensionInstallForcelist": ["<EXT_ID>;https://clients2.google.com/service/update2/crx"],
  "3rdparty": { "extensions": { "<EXT_ID>": {
    "gateUrl":  "https://aigate.corp.internal",
    "profileId": "<UUID scan_only-профиля из Admin UI>",
    "degradedPolicy": "local_pii_mask",
    "enforcementMode": "enforce",
    "unknownSitePolicy": "warn",
    "scanTimeoutMs": 10000
  }}}
}

Где gateUrl — адрес вашего AppSec.AIGate, profileId — UUID профиля из шага 1. На Windows/Edge — те же поля под ...\Policies\...\3rdparty\extensions\<EXT_ID>\policy; в Intune — managed extension settings; в Yandex Browser — корпоративные политики (аналог Chromium).

Шаг 3. Принудительная установка¶

ExtensionInstallForcelist делает расширение установленным, активным и неотключаемым пользователем. Managed-поля read-only; изменения центром применяются без действий пользователя.

Параметры managed-config

Полный список (degradedPolicy local_pii_mask/block_all, enforcementMode enforce/monitor_only, unknownSitePolicy, controlledSites, scanTimeoutMs, bufferMaxSize, подписанный remote-каталог адаптеров). Дефолты безопасны: enforce + local_pii_mask + warn + тайм-аут 10 с.

Свой self-hosted OpenWebUI

Если вы используете self-hosted OpenWebUI, добавьте его адрес в поле selfHostedHosts managed-config (например "selfHostedHosts": ["openwebui.corp.internal"]) — расширение начнёт инспектировать этот хост. Адрес у каждой инсталляции свой и в расширении не «зашит».

Degraded-режим (гейт недоступен)¶

При недоступности гейта расширение не пропускает трафик вслепую: по умолчанию (local_pii_mask) локально маскирует PII — email, телефоны, карты (Luhn), секреты, ИНН/СНИЛС (regex) и ФИО (лёгкий эвристик: словарь имён + морфо-суффиксы фамилий и отчеств, без ML; покрытие имён ~99% на бенчмарке) — и предупреждает; для регулируемых сегментов (block_all) — блокирует любую отправку до восстановления гейта. Инциденты буферизуются metadata-only (без текста промпта, 152-ФЗ) и досылаются в аудит при возврате гейта. Угрозы и контент-безопасность локально не проверяются — это зона серверной детекции.

Ограничения — важно понимать¶

Покрывается браузер на управляемой технике. Десктопные ИИ-приложения, IDE-плагины, мобильные клиенты, прямой API и личные/неуправляемые устройства — вне периметра.
Локально (degraded) — только PII; угрозы/контент требуют гейта.
Каждый сайт требует адаптера; при смене разметки сайта адаптер обновляется (есть детект «ослепшего» адаптера + доставка адаптеров без релиза).

Поэтому расширение — слой defense-in-depth для endpoint'а, а не замена сетевого контроля. Для полного покрытия (любые устройства, не только браузер) его дополняют управляемой точкой входа.

Для полного покрытия — управляемый self-hosted UI¶

Чтобы инспектировался весь чат-трафик (включая неуправляемые устройства), дайте пользователям внутренний чат-интерфейс, который ходит в модель через AppSec.AIGate, и закройте прямой доступ к публичным SaaS на сетевом периметре.

Вариант A. Self-hosted UI → AppSec.AIGate (прозрачный прокси)¶

Разверните OpenAI-совместимый веб-чат (OpenWebUI, LibreChat) и укажите base_url шлюза AppSec.AIGate. Шлюз проверяет запрос, проксирует в модель, проверяет ответ.

flowchart LR
    user["Пользователь<br/>→ внутренний UI"]
    ui["OpenWebUI / LibreChat<br/>(self-hosted)"]
    gw["AppSec.AIGate"]
    llm["LLM backend<br/>(OpenAI / GigaChat / …)"]

    user --> ui -->|"base_url = шлюз"| gw -->|"проверка ✓ затем прокси"| llm
    llm --> gw --> ui --> user

    classDef ok fill:#e6f4ea,stroke:#34a853,color:#111;
    class gw ok;

📄 Способ 1 — прозрачный прокси · Nginx · Ingress в Kubernetes.

Вариант B. Self-hosted UI → LiteLLM (+ AppSec.AIGate guardrail)¶

Если уже используете LiteLLM как единый LLM Gateway, направьте веб-чат на него, а AppSec.AIGate подключите как guardrail. Удобно, когда LiteLLM уже маршрутизирует трафик на несколько провайдеров.

flowchart LR
    user["Пользователь<br/>→ внутренний UI"]
    ui["OpenWebUI"]
    lg["LiteLLM"]
    ad["llm-gateway-adapter"]
    gw["AppSec.AIGate"]
    llm["LLM backend"]

    user --> ui -->|"base_url = LiteLLM"| lg
    lg <-->|"guardrail webhook"| ad <--> gw
    lg -->|"если разрешено"| llm --> lg --> ui --> user

    classDef ok fill:#e6f4ea,stroke:#34a853,color:#111;
    class gw,ad ok;

📄 Способ 3 — guardrail-адаптер · Интеграция с LiteLLM · Пошаговое руководство.

Как выбрать¶

	Браузерное расширение	Self-hosted UI (прокси / guardrail)
Где контроль	endpoint, внутри браузера	управляемый UI, в сети
Устройства	только управляемые (MDM)	любые (через внутренний UI)
Покрытие	публичные веб-чаты в браузере	весь трафик к LLM через UI
Что нужно	force-install + managed-config	развернуть UI + закрыть SaaS на периметре
Лучше всего	контроль «последней мили» на корп-технике	полное покрытие, неуправляемые сценарии

Итог

На корп-технике браузерное расширение даёт прямой контроль публичных ИИ-чатов. Для полного покрытия дополните его управляемым self-hosted UI и ограничением прямого доступа к SaaS на сетевом периметре. Сетевой TLS-перехват по-прежнему не используется и не нужен — расширение работает на endpoint'е, до шифрования.

Дополнительная информация¶

Способы подключения шлюза — обзор всех вариантов со схемами.
Интеграция с LiteLLM · Python SDK.