«Налог на инструменты»: почему ИИ-агенты тратят токены впустую
Каждое обращение к большой языковой модели — это не только сам запрос, но и весь контекст, который в него попадает. Когда агент подключён к серверам Model Context Protocol (MCP), модель при каждом ходе получает полный каталог доступных инструментов: их имена, описания, параметры и схемы. Даже если агент ни разу не воспользуется большинством из них, токены на их обработку уже потрачены — ещё до того, как модель решит что-то вызвать. В Okta этот эффект называют «налогом на инструменты» (tool tax), и он растёт вместе с числом инструментов и пользователей.
Проблема не только в деньгах. Агент видит определения всех инструментов, включая те, к которым у него нет доступа. Попытка использовать такой инструмент будет заблокирована на этапе выполнения, но токены на его обработку в промпте уже израсходованы — вернуть их нельзя. Получается, что с точки зрения и безопасности, и экономики нужно отсекать лишнее до того, как информация попадёт в модель.
Как Okta предлагает резать расходы
Решение Okta строится на ограничении списка инструментов по идентичности. Вместо того чтобы отдавать агенту весь каталог MCP-сервера, администратор через дашборд Okta прописывает, какие именно инструменты разрешены конкретному агенту или пользователю, стоящему за ним. Okta возвращает только этот сокращённый набор, и именно он попадает в промпт модели на каждом ходе. Дополнительно система проверяет права на этапе выполнения, перед непосредственным вызовом.
По сути, это перенос принципа наименьших привилегий на уровень инструментов. Агент не должен знать о существовании ресурсов, баз данных или действий, на которые у него нет явного разрешения. А раз инструмент не попал в промпт, то и токены на его схему не тратятся. Если сравнить с прежним подходом, где можно было ограничить доступ только целиком к серверу, здесь область сужается до отдельных инструментов внутри сервера. Например, для интеграций с Google Workspace, Slack или внутренними MCP-серверами можно открыть агенту только чтение почты, но не отправку сообщений.
Что показало моделирование и чем подход отличается от шлюзов
Okta пока не приводит данных с реальных внедрений — оценки основаны на внутреннем моделировании. Внутри компании собрали каталог корпоративных инструментов, сопоставили их с OAuth-скоупами и разбили пользователей на типовые роли: от специалистов поддержки с правами только на чтение до суперадминистраторов. В некоторых сценариях число видимых инструментов сокращалось более чем на 90%, и стоимость их схем падала примерно в той же пропорции. Абсолютные значения по токенам или долларам не раскрываются, потому что итог сильно зависит от каталога, распределения прав, среднего размера схем, объёма запросов и тарифов конкретной модели.
Скоупинг по идентичности стоит отличать от шлюзовых контролей расходов. Шлюзы умеют ограничивать бюджет по ключу, команде или группе, делать rate limiting и маршрутизацию, но они срабатывают уже после того, как модель приняла дорогое решение. Права на основе идентичности определяют сам набор доступных инструментов заранее, на уровне агента и пользователя, а не группы в целом. Это позволяет не только экономить токены, но и убирать из поля зрения агента всё, к чему он не должен иметь доступ.
Похоже, что Okta видит этот механизм частью более широкой стратегии защищённых агентных сред. Насколько он окажется эффективен на практике, станет ясно после пилотных проектов у клиентов, но сама идея — убирать лишнее из промпта до того, как за него заплатишь, — выглядит логичным шагом в борьбе с разбухающими контекстами ИИ-агентов.
