Локальный контур не отменяет контроль доступа

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

Принцип zero trust формулирует это жёстко: расположение внутри корпоративной сети не должно давать неявного доверия. Для AI-агента вывод особенно практичен. Модель может предложить действие, но не должна самостоятельно хранить долгоживущий секрет и решать, достаточно ли у неё полномочий.

Безопасная схема разделяет рассуждение и исполнение. Модель описывает намерение в структурированном виде, отдельный шлюз проверяет пользователя, процесс, ресурс и операцию, а затем выдаёт исполнителю короткоживущий доступ только к нужной системе. Постоянный пароль не попадает ни в prompt, ни в историю диалога, ни в ответ модели.

Что именно опасно в обычной интеграции

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

Типовые проблемы:

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

Официальная спецификация авторизации Model Context Protocol запрещает token passthrough: токен, принятый MCP-сервером от клиента, нельзя просто пересылать в downstream API. Для целевого сервиса нужен отдельный токен. Спецификация также рекомендует минимальные scopes, короткий срок жизни и привязку токена к конкретному ресурсу. Токен «для CRM» не должен приниматься файловым хранилищем.

Архитектура доступа на одну операцию

Практическая цепочка состоит из шести ролей.

1. **Пользователь или бизнес-процесс.** Система знает, кто поставил задачу, к какой компании и подразделению относится человек и активна ли его учётная запись.
2. **Идентичность рабочей нагрузки.** Контейнер агента, шлюз и исполнитель имеют собственные машинные идентичности. SPIFFE, например, выдаёт рабочим нагрузкам короткоживущие X.509- или JWT-документы SVID и автоматически их обновляет. Приложению не нужен постоянный секрет для обращения к локальному Workload API.
3. **Шлюз инструментов и политик.** Он принимает не произвольный текст, а структурированное намерение: действие, объект, поля, основание и идентификатор задачи. Здесь проверяются allowlist, роль пользователя, среда, лимиты и необходимость подтверждения.
4. **Брокер учётных данных.** После разрешения операции он обменивает подтверждённую идентичность на токен с нужными audience, scope и TTL. Для OAuth-систем это может быть Security Token Service по RFC 8693; для базы или инфраструктуры — динамический секрет в Vault либо нативный механизм провайдера.
5. **Детерминированный исполнитель.** Отдельный узкий сервис вызывает CRM, базу или почту. Он держит токен только в памяти, не возвращает его модели и принимает только заранее описанные параметры.
6. **Журнал и отзыв.** Система записывает решение политики, ресурс, операцию, инициатора, срок доступа и результат. При отмене задачи, блокировке пользователя или сбое доступ отзывается, если целевая система это поддерживает.

В этой схеме модель остаётся полезной: извлекает параметры, предлагает план, объясняет результат. Но границу полномочий определяет обычный проверяемый код.

Делегирование пользователя и машинная идентичность — не одно и то же

Нужно различать два вопроса: «кто запустил процесс?» и «какой сервис сейчас выполняет запрос?». Первый отвечает за делегирование полномочий человека, второй — за аутентификацию рабочей нагрузки.

Например, менеджер просит агента обновить карточку клиента. Шлюз проверяет, что менеджер имеет право менять именно этот регион и эти поля. Затем исполнитель доказывает CRM свою машинную идентичность и получает токен на изменение одной карточки или узкого набора полей. Если токен выдаётся только от имени общего робота без связи с инициатором, аудит покажет сервис, но потеряет бизнес-контекст. Если использовать только пользовательский токен без идентичности сервиса, труднее ограничить, какой компонент вправе им воспользоваться.

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

Какие данные можно оставлять в журнале

Секрет не должен попадать в prompt, контекст модели, результат инструмента, трассировку HTTP и сообщение об ошибке. Для расследования достаточно других полей:

  • идентификатор пользователя и рабочей нагрузки;
  • номер бизнес-задачи и версия политики;
  • целевой ресурс, операция и запрошенные scopes;
  • время выдачи, TTL и идентификатор аренды или хеш токена;
  • факт ручного подтверждения;
  • код результата и признак частичного выполнения.

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

Что делать при сбоях

Короткоживущий токен снижает окно риска, но требует аккуратного исполнения.

  • Если токен истёк до вызова, исполнитель получает новый только после повторной проверки политики.
  • Если операция могла выполниться, но ответ потерян, нельзя слепо повторять запись. Нужен idempotency key или запрос состояния целевой системы.
  • Если заблокирован пользователь, брокер должен прекратить новые выдачи, а активные аренды — отозвать, где это возможно.
  • Если ошибочна audience, целевой сервис обязан отклонить токен, даже когда подпись корректна.
  • Если брокер недоступен, агент не должен переходить на сохранённый «аварийный» пароль. Для критичных процессов лучше остановиться и передать задачу человеку.
  • Часы шлюза, брокера и исполнителя должны быть синхронизированы, иначе короткий TTL даст ложные отказы или лишнее окно действия.

Для операций записи полезно разделить подготовку и подтверждение. Агент формирует проект изменения, человек видит объект и последствия, а шлюз выдаёт доступ только после подтверждения. Отправка письма, платёж, удаление и массовое изменение должны иметь отдельные политики и лимиты.

Минимальный стек для малого и среднего бизнеса

Необязательно строить собственную систему управления идентичностью. Пилот можно собрать вокруг уже существующих компонентов:

  • корпоративный каталог или IdP для пользователей;
  • небольшой шлюз инструментов с JSON-схемами и allowlist;
  • Vault, облачный STS или нативный механизм временных учётных данных целевой системы;
  • отдельный исполнитель для каждой рискованной интеграции;
  • разные идентичности для разработки и производства;
  • отдельные права на чтение и запись;
  • подтверждение человека для необратимых действий.

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

Модельная экономика

Рассмотрим условную компанию с шестью интеграциями, двумя средами и разными правами на чтение и запись. Без централизации получится до 24 постоянных наборов полномочий: 6 × 2 × 2. Это не обязательно 24 разных пароля, но именно столько сочетаний нужно учитывать при ротации, аудите и разборе инцидентов.

После внедрения брокера клиенты могут не хранить downstream-секреты вообще. Однако доверие не исчезает: у брокера остаются корневые подключения, политики и право выдачи. Их нужно защищать сильнее обычного приложения.

Иллюстративный, а не рыночный расчёт: 120 часов разработки и интеграции по 3 000 рублей дают 360 000 рублей запуска; ещё 6 часов сопровождения в месяц — 216 000 рублей в год. Такая схема оправдана раньше там, где агент пишет в несколько систем, обрабатывает чувствительные данные, требует регулярной ротации или проверяемого аудита. Для одного read-only справочника достаточно узкого шлюза и отдельной учётной записи с минимальными правами.

Пилот за десять рабочих дней

1. Проведите инвентаризацию секретов одного процесса: где они хранятся, кто их видит, какие действия разрешают.
2. Выберите один read-only инструмент и опишите его вход и выход строгой JSON-схемой.
3. Задайте audience, минимальные scopes, TTL и условия отказа.
4. Подключите идентичность пользователя и рабочей нагрузки к шлюзу; секрет целевой системы оставьте только у брокера или исполнителя.
5. Прогоните не менее 50 типовых задач и отдельные негативные сценарии: истёкший токен, неверный ресурс, отключённый пользователь, повтор операции и попытка запросить лишнее поле.
6. Измерьте долю разрешённых корректных вызовов, ложные отказы, время выдачи, число ручных подтверждений и полноту журнала.
7. Только после этого добавляйте запись. Сначала ограничьте один объект или одно поле, затем расширяйте разрешения по фактическим сценариям.

Управленческий критерий прост: пилот успешен не тогда, когда агент смог вызвать API, а когда ни модель, ни её контейнер не получили универсальный постоянный ключ, а каждое действие можно связать с человеком, политикой и конкретным результатом.