Ти підключив агента до десятка MCP-інструментів і пустив його розгрібати понеділковий бeklог. Slack, GitHub, платіжне API — повний зоопарк одомашнених сервісів. Життя нарешті автоматизоване. А потім агент повторює невдалий платіжний запит, і твій клієнт отримує подвійне списання.

Ніщо в MCP не повідомило агенту, що цей endpoint не можна безпечно повторювати. Жодного маркера, жодного прапорця. Просто голе API і модель, яка робить те, що моделі роблять — "допомагає".

А от у чому штука. Специфікація MCP додала саме ті поля безпеки, які б тобі знадобились. Чотири анотації — readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Чотири булеві значення, які могли б повністю запобігти сценарію з подвійним списанням. Команда MCP опублікувала їх 16 березня 2026 року. І специфікація назвала кожне з них "Hint" — "підказка".

Не контракт. Не обмеження. Підказка. Як стікер на зарядженому пістолеті: "можливо, не варто цілити в людей".

Через шість тижнів індустрія винесла свій вердикт. Microsoft випустив Agent Governance Toolkit 2 квітня — YAML-based policy enforcement, написаний з нуля, жодного посилання на анотації MCP. Anthropic запустив Managed Agents permission policies 21 квітня — кастомні allowlists та scoping, анотації повністю проігноровані. Google наступного дня, 22 квітня, представив Agent Gateway — та сама схема, та сама побудова policy engine з нуля. Три великі платформи за двадцять днів. Жодна не використала метадані безпеки, які вже існують у протоколі, на який вони всі спираються.

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

Джастін Спар-Саммерс, співтворець MCP, сказав тиху частину вголос під час перегляду специфікації у березні 2026 на GitHub: "Сама інформація, якби їй можна було довіряти, була б дуже корисною, але мені цікаво, як клієнт може використати цей прапорець, знаючи, що йому не можна довіряти." Розробник метаданих безпеки публічно поставив під сумнів, чи може хтось їм довіряти. Це не червоний прапорець. Це фабрика червоних прапорців.

Самодекларовані метадані безпеки без верифікації — це не функція безпеки. Це скринька для пропозицій. destructiveHint: false від ненадійного MCP-сервера рівно настільки ж достовірне, як запитати інструмент "ей, ти небезпечний?" і повірити відповіді. Понад 17 000 MCP-серверів зараз розкидані по публічних реєстрах. Кількість тих, що мають незалежну верифікацію своїх оголошених анотацій: нуль.

Кожна серйозна система розібралася з цим десятиліття тому. Unix не підказує дозволи файлів — ядро їх примусово застосовує. OAuth не підказує скоупи — авторизаційний сервер їх валідує. Docker не підказує привілеї контейнерів — рантайм їх накладає. У кожній працюючій моделі безпеки сутність, що робить заяву про безпеку, — це не та сама сутність, яку обмежують. Це не параноя. Це перше, чого тебе вчать, перш ніж пускати до продакшену.

Анотації MCP порушують цей принцип за дизайном. Сервер інструмента декларує власні властивості безпеки, клієнт їх читає, і ніщо між ними не верифікує заяву. Блог MCP визнав це прямо: "Сервер може заявити readOnlyHint: true і все одно видаляти файли." Власна документація специфікації визнає, що мітки безпеки можуть брехати, і немає механізму це відловити.

Слово "hint" зробило решту шкоди. Коли називаєш метадані безпеки "підказкою", ти кажеш кожному інтегратору: це опціонально, ненадійно і не ваша проблема. Вони послухали. Три платформи, три системи governance з нуля, нульове впровадження існуючих анотацій на рівні протоколу — все протягом квітня 2026 року. Не тому, що метадані марні, а тому, що специфікація заздалегідь промаркувала їх як декоративні.

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

Тож ти пишеш YAML-політики вручну. Налаштовуєш allowlists інструментів руками. Будуєш ті самі гарантії, які анотації мали забезпечувати, тільки з нуля, бо рівень безпеки самого протоколу превентивно сказав тобі на нього не покладатися. Найтрудомісткіша модель безпеки з можливих — не тому, що кращих метаданих не існує, а тому, що хтось вирішив назвати їх "hint".

Фікс навіть не технічний. Чотири поля спроєктовані правильно. Модель даних працює. Зламане одне слово і філософія за ним. Зміни "hint" на "declaration". Додай endpoint верифікації — дай клієнтам тестувати оголошені властивості на відповідність спостережуваній поведінці. Зроби брехню такою, що можна виявити. Найдешевший апгрейд безпеки у всьому агентному стеку лежить у специфікації, правильно структурований і повністю кастрований рішенням щодо назви, яке сказало 17 000 серверам і трьом governance-платформам не сприймати його серйозно.

Хтось зібрав вогнегасник, написав на ньому "може містити, а може й не містити воду" — і тепер дивується, чому будівля горить.