Okta оголосила про scoping для Model Context Protocol (MCP) — механізм, який обмежує перелік інструментів, ресурсів і даних, доступних ШІ-агенту в межах конкретної сесії чи ролі. Мета проста: менше зайвих tool-визначень у системному промпті — менше токенів на кожен виклик моделі, і менша поверхня для зловживання довірою агента.

Для команд, які вже підключили десяток MCP-серверів до одного агента — CRM, календар, репозиторій коду, платіжний шлюз — рахунок за токени росте непропорційно корисності. Кожен доданий сервер додає у контекст власний набір схем інструментів, і модель змушена «прочитати» їх усі ще до того, як користувач поставить перше запитання.

За даними AI News, Okta підійшла до проблеми токен-витрат агентів через призму, яку компанія знає найкраще, — управління доступом. Ідея в тому, щоб агент бачив не весь каталог підключених MCP-серверів одразу, а лише те, що реально потрібно для конкретної задачі чи ідентичності користувача, від імені якого він діє.

Що саме означає «scoping» у контексті MCP?

Scoping — це обмеження набору tool-схем і ресурсів, які модель отримує в контекстному вікні під час конкретного виклику, замість передачі повного списку всіх зареєстрованих MCP-серверів щоразу. Технічно це нагадує те, як OAuth-scopes обмежують доступ токена до конкретних API-ендпоінтів, — тільки тут слово «токен» працює у подвійному значенні: і токен доступу, і LLM-токени, які модель витрачає на читання інструкцій.

На практиці це означає, що адміністратор може прив'язати видимість MCP-сервера до ролі, відділу чи окремої задачі агента. Агент бухгалтерії не бачитиме інструментів для деплою коду, а агент підтримки — інструментів для зміни платіжних даних. Вужчий набір видимих інструментів — це одночасно економія на промпті і менший ризик того, що модель скористається невідповідним інструментом.

Чому токен-витрати взагалі стали болем для команд, що будують агентів?

Кожен виклик агента з підключеними MCP-серверами платить «податок» ще до корисної роботи: опис кожного tool, його параметрів і прикладів використання займає місце в контексті й тарифікується як вхідні токени. При десятках інструментів цей податок може сягати тисяч токенів на кожен запит — незалежно від того, чи агент узагалі скористається бодай одним із них.

Кому це реально заощадить бюджет на інференс?

Найбільше виграють команди enterprise-масштабу, де один агентний шар обслуговує кілька відділів і десятки внутрішніх систем через MCP. Саме там каталог інструментів росте найшвидше і найменше контролюється централізовано. Для одиночного розробника з двома-трьома MCP-серверами економія в токенах буде помітною, але не критичною — головний виграш там радше в безпеці, ніж у рахунку за інференс.

Ймовірно, за нашою оцінкою, найбільш зацікавленими покупцями стануть компанії, які вже користуються identity-стеком Okta і хочуть поширити ту саму модель контролю доступу на шар ШІ-агентів, не будуючи окрему систему авторизації з нуля.

Що з цим робити AI-білдерам просто зараз?

Навіть не чекаючи на конкретний продукт від Okta, принцип scoping варто застосовувати вже сьогодні: не підключайте агенту весь каталог MCP-серверів «про всяк випадок» — прив'язуйте видимість інструментів до ролі, задачі чи сесії користувача. Та сама логіка «менше зайвого в контексті» стосується не лише інструментів, а й самих даних: ми вже писали про те, чому «думки» Claude і ChatGPT можуть зберігати ваші паролі — чим ширший видимий агенту контекст, тим більше шансів, що чутливі дані опиняться там, де їм не місце.

Наша теза в AiiN: token-scoping для MCP — не окрема фіча, а логічне продовження принципу найменших привілеїв, перенесеного з класичного IAM у світ агентів. Компанії, які будують на MCP, найближчим часом муситимуть обирати між зручним плоским доступом до всіх інструментів і дешевшим та безпечнішим динамічним доступом за ролями — і крок Okta показує, що ринок identity-провайдерів уже готує для цього готові рейки.

Що таке Model Context Protocol простими словами?

MCP — це відкритий протокол від Anthropic, який дозволяє ШІ-моделям стандартизовано підключатися до зовнішніх інструментів, баз даних і сервісів через єдиний інтерфейс, замість окремої інтеграції під кожного провайдера моделі.

Чи доведеться переписувати наявні MCP-інтеграції через scoping?

З опису анонсу це не випливає: scoping додається як шар контролю доступу поверх наявних MCP-серверів, а не як заміна самого протоколу, тож наявні інтеграції мають лишитися сумісними.

Scoping вирішує проблему вартості агента чи ще й точності?

Обидва аспекти пов'язані між собою: вужчий видимий набір інструментів одночасно знижує вартість виклику і підвищує ймовірність того, що модель обере правильний інструмент серед меншої, релевантнішої вибірки.