Разрешение формулируют для действия
Фраза «агент управляет кампанией» слишком широка для доступа к бюджету. Управление включает просмотр статистики, изменение ставок, аудитории, срока, общего лимита и способов оплаты. У этих действий разные последствия. Доступ на чтение не должен автоматически открывать остальные операции.
Для каждого действия нужен владелец решения. Бренд определяет допустимую задачу и деньги, агентство отвечает за согласованный процесс закупки, разработчик настраивает исполнение правил. Нельзя перекладывать всё на пользователя, который однажды подключил интеграцию. Он мог разрешить анализ, не имея права увеличивать обязательства компании.
AAMP IAB Tech Lab показывает развитие протоколов взаимодействия рекламных агентов и референсных реализаций. Само подключение такого протокола не подтверждает, что конкретная российская DSP поддерживает нужные ограничения. Полномочия проверяют в документации платформы и испытаниях интеграции.
Здесь мы проектируем правила исполнения, а не разбираем существующий рекламный интерфейс. Примеры команд и журнал ниже учебные, не запись работы какой-либо платформы. Проверить качество рекомендаций отдельно помогает материал о теневом режиме агента.
Матрица должна содержать измеримые границы
Полезная строка матрицы отвечает на вопросы: кто действует, что меняет, в какой кампании, в каких пределах и до какого момента. «Можно немного поднять ставку» не проходит эту проверку. Нужны числовой предел, база сравнения и период действия правила.
| Действие | Самостоятельно | С подтверждением | Кто задаёт правило |
|---|---|---|---|
| Читать агрегированный отчёт | Разрешённые кампании | Выгрузка новых полей | Владелец данных |
| Подготовить медиапредложение | Без создания заказа | Отправка внешнему продавцу | Руководитель закупки |
| Изменить ставку | Внутри заданного диапазона | За пределами диапазона | Медиадиректор |
| Перераспределить бюджет | Внутри общего лимита и долей | Увеличение обязательства | Владелец бюджета |
| Изменить аудиторию | Только заранее разрешённые сегменты | Новая категория данных | Владелец кампании |
| Менять оплату и пользователей | Запрещено в пилоте | Отдельный процесс компании | Финансы и безопасность |
Это пример внутренней политики, не универсальная матрица для всех брендов. В регулируемой категории даже смена текста или аудитории может требовать отдельного согласования. В простой кампании команда может разрешить больше операций. В обоих случаях решение должно иметь автора и дату окончания.
В матрице дополнительно указывают идентификаторы кабинетов и кампаний, часовой пояс, дневной и общий предел, допустимые площадки, запрет на новые источники данных и способ отзыва доступа. Срок действия отличает разрешение на пилот от бессрочного административного доступа.
Ограничение проверяет система, которая выполняет команду
OWASP в описании Excessive Agency выделяет риск избыточных функций, полномочий и автономности. Для рекламной интеграции вывод практический: инструкция в промпте не заменяет проверку прав перед изменением кампании. Модель может ошибиться, неверно понять задачу или обработать вредоносную внешнюю подсказку.
Безопасный порядок выглядит так. Агент формирует предложение изменения. Исполняющий сервис проверяет личность, разрешённую операцию, актуальную версию кампании и лимиты. При необходимости получает подтверждение конкретного изменения. Затем применяет его и записывает фактическое состояние. Отказ тоже попадает в журнал.
Техническая авторизация решает только часть задачи. В спецификации MCP Authorization описаны области доступа. Возможность вызвать инструмент изменения бюджета ещё не означает право увеличить месячное обязательство на любую сумму. Денежные ограничения должны существовать в логике рекламной системы независимо от области доступа протокола.
Если платформа выдаёт только один широкий ключ администратора, внешний сервис может сузить доступ для агента, но сам остаётся чувствительной точкой. Такой компромисс нужно явно принять и защитить. Называть его встроенной защитой DSP нельзя. Для пилота можно оставить агенту только подготовку предложений до появления надёжного исполнительного ограничения.
Считать совокупный расход, а не только размер одной команды
Учебная политика разрешает поднять дневной лимит кампании с 10 до 12 тысяч рублей, но не выше. Агент дважды просит прибавить по 2 тысячи. Проверка «одна команда не больше 2 тысяч» пропустит обе и доведёт лимит до 14 тысяч. Проверка целевого состояния отклонит вторую.
| Время | Запрос | Текущее значение | Решение |
|---|---|---|---|
| 10:00 | Установить 12 000 руб. | 10 000 руб. | Разрешить: предел соблюдён |
| 10:01 | Установить 14 000 руб. | 12 000 руб. | Отклонить: выше 12 000 |
| 10:02 | Сохранить 12 000 руб. повторно | 12 000 руб. | Сверить результат прежней операции |
| 10:03 | Изменить чужую кампанию | Нет разрешения | Отклонить: другой объект |
При нескольких кампаниях нужен ещё общий предел. Допустимые лимиты каждой по отдельности не гарантируют соблюдения бюджета бренда. Перераспределение следует проверять как связанное изменение: сколько снимается с одной кампании, сколько добавляется другой, как выглядит сумма после операции.
Отдельно учитывают зарезервированные и ещё не отражённые расходы. Если отчёт обновляется с задержкой, доступный остаток нельзя считать простым вычитанием последнего показанного расхода. Финансовая модель платформы должна объяснять, что считается обязательством и когда оно освобождается. Если этого объяснения нет, в пилоте нужен более консервативный предел и ручная сверка.
Подтверждение относится к конкретной версии изменения
Сообщение «одобряю оптимизацию» не задаёт границ. Подтверждение должно содержать кампанию, старое и новое значение, общий эффект на бюджет и срок. Если предложение изменилось после одобрения, старое разрешение больше не подходит. Агент не может расширить его собственной интерпретацией.
Предположим, специалист согласовал перенос тысячи рублей между двумя группами. Пока он читал сообщение, другой оптимизатор изменил одну из групп. Исполняющий сервис должен обнаружить, что исходное состояние уже другое. Разумное действие: пересчитать предложение и запросить новое подтверждение, если меняется его смысл или нарушается политика.
Поэтому в журнале нужны версия кампании до изменения, идентификатор предложения, подтверждающий сотрудник и версия политики. Техническую реализацию выбирает разработчик: проверка версии, блокировка или другая согласованная схема. Важно наблюдаемое поведение при конфликте, а не название технологии.
Повторы после сетевой ошибки требуют отдельной защиты. Клиент мог не получить ответ, хотя изменение уже состоялось. Нельзя автоматически выполнить его ещё раз. Механизм повторов подробно разобран в материале о двойном заказе агента; в матрице прав достаточно зафиксировать обязанность связывать повтор с прежним результатом.
Отзыв доступа проверяют действием
Выключенный переключатель в интерфейсе ещё не доказывает остановку. У интеграции могут остаться активные ключи, задачи в очереди и выданные ранее подтверждения. Проверка должна показать, что произойдёт со следующей командой и с уже подготовленной, но не выполненной операцией.
В учебном испытании администратор отзывает доступ, после чего тестовый агент пытается прочитать отчёт и изменить ставку. Ожидаемые ответы зависят от политики: запись всегда запрещается, чтение либо остаётся отдельно разрешённым, либо тоже отключается. Результат и причину отказа сохраняют. Проверку выполняют в тестовой среде без реального увеличения расхода.
Есть две разные остановки. Первая отзывает полномочия агента. Вторая останавливает саму кампанию. Если агент потерял доступ, ранее запущенная реклама может продолжать расходовать бюджет. Команда заранее назначает сотрудника, который способен остановить закупку независимо от агента и его интеграции.
После аварийной остановки нельзя сразу возвращать прежний широкий доступ. Сначала сверяют фактические изменения, остатки обязательств и задания в очереди. Затем восстанавливают только нужные операции. Такая последовательность помогает не возобновить ту же ошибку отложенной командой.
Что проверить российской команде до пилота
Начальный тест выполняют на отдельной кампании и данных, которые разрешено использовать для этой задачи. Внешней модели не передают персональные сведения только потому, что они есть в отчёте. Ответственный за данные определяет допустимые поля, место обработки и правила хранения; статья не заменяет правовую оценку конкретной передачи.
Проверочный набор должен включать попытку изменить чужую кампанию, выйти за общий предел, применить просроченное подтверждение, повторить выполненную команду и действовать после отзыва доступа. Нужен также обычный успешный сценарий. Политика, которая запрещает всё, защищает деньги, но не подтверждает полезность рабочего процесса.
В учебном журнале команд сохранены примеры разрешения и отказа. Для приёмки разработчик добавляет фактические ответы сервиса, а медиаспециалист сверяет состояние кампании после каждой операции. Проверяется исполнение запрета, а не только наличие слова «отклонено» в ответе агента.
Пилот проходит этот этап, когда запрещённые изменения действительно не применяются, разрешённые воспроизводимы, а независимая остановка работает. Подсказки модели и их качество оценивают следующим испытанием. Связанные понятия есть в глоссарии: ограничения автоматизации, распределение расхода во времени и DSP. Источники и редакционная схема проверены 26 октября 2026 года.
