Стартап AIR закрив раунд фінансування на $50 мільйонів, щоб побудувати інфраструктуру для перевірки навичок (skills) і плагінів, якими користуються AI-агенти. Ідея проста: перш ніж агент отримає доступ до стороннього інструменту — від MCP-сервера до кастомного плагіна, — хтось повинен перевірити, що цей інструмент справді робить те, що заявляє, і не робить того, чого не мав би.

За даними TechCrunch, раунд — пряма відповідь на масове розгортання AI-агентів у компаніях: що більше агентів отримують автономний доступ до зовнішніх систем, то вища ціна помилки, якщо один недбало написаний чи зламаний скіл стане точкою входу для витоку даних або шкідливих дій.

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

Що саме сталося?

AIR отримала $50 млн інвестицій під побудову платформи, яка оцінює й верифікує навички та додатки для AI-агентів — тобто виконує роль проміжного шару довіри між розробником стороннього інструменту і компанією, що хоче його підключити. Замість того щоб кожна команда вручну аудіювала кожен MCP-сервер чи плагін, який хоче використати агент, верифікація виноситься в окремий сервіс.

Ключовий факт тут — сам розмір раунду і момент його залучення: інвестори ставлять $50 мільйонів на те, що ринок AI-агентів дозріє до потреби в окремому шарі безпеки для навичок так само, як ринок мобільних застосунків свого часу дозрів до app store review.

Чому ця проблема загострилася саме зараз?

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

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

Кому це реально потрібно вже зараз?

Найбільше це стосується команд, які будують агентів на MCP-протоколі й підключають сторонні сервери без власного security-огляду кожного з них. Ми вже писали про те, як Anthropic дає бізнесу контроль над даними в Claude API — це той самий тренд: постачальники інфраструктури для агентів усвідомлюють, що enterprise-клієнти не розгорнуть агента в продакшні, поки не матимуть інструменту контролю над тим, що саме він робить і з чиїми даними взаємодіє.

Ймовірно, попит на такі сервіси верифікації зростатиме швидше за здатність команд безпеки вручну аудіювати кожен новий плагін — але це наша оцінка, а не факт із джерела.

Висновок AiiN: що з цим робити просто зараз

Наша теза проста: довіра до навички AI-агента більше не може ґрунтуватися на репутації її автора чи красивому опису в маркетплейсі — вона повинна перевірятися так само формально, як залежність у package.json перевіряється сканером вразливостей. Поява окремої категорії стартапів під верифікацію скілів — сигнал, що індустрія визнала: агент з непроконтрольованим набором навичок — це не зручність, а нова поверхня атаки.

Практично для AI-білдерів це означає одне: якщо у вашого агента вже є список підключених MCP-серверів чи плагінів, варто вести його так само суворо, як список залежностей у продакшн-коді — з переглядом прав доступу, версій і змін при кожному оновленні.

Що таке верифікація навичок AI-агента?

Це процес перевірки того, що сторонній інструмент (skill, плагін, MCP-сервер), підключений до AI-агента, справді виконує заявлену функцію і не має прихованих чи надлишкових можливостей. У випадку AIR цей процес пропонується як окрема інфраструктурна послуга для компаній, що розгортають агентів.

Чим ризик стороннього skill відрізняється від ризику звичайної бібліотеки коду?

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