Реєстри агентів повідомляють вам, що існує, а не чи можна йому все ще довіряти.
Чотирикомпонентна структура для реєстрів можливостей агентів, яка охоплює існування, придатність, статус та походження, а також простий тест останньої перевірки, який ви можете пройти сьогодні.
Уявіть агента під час звичайної роботи, який шукає інструмент за назвою, викликає його, отримує зрозумілу відповідь та продовжує роботу. Операція успішна, і саме це є тривожним, адже ніхто в команді ніколи не перевіряв цю функціональність. Системи реєстрації та сервіси виявлення мають контролювати подібні ситуації, і вже протягом одного тижня з’явилося кілька продуктів та специфікацій, які всі стверджують, що є цим шаром контролю.
Жоден з них не є хибним, але разом вони охоплюють лише половину того, що команда повинна знати перед тим, як агент використає нову функціональність. У цій статті проблема розбивається на чотири окремі запитання, показується, на які з них відповідають поточні системи реєстрації, наводиться конкретна перевірка, а також короткий список дій щодо тих питань, які залишилися нерозв’язаними.
Що з’явилося у шарі реєстрації
Наведена нижче інформація відображає дані на момент написання тексту; перевіряйте актуальну документацію перед тим, як покладатися на конкретні функції чи номери версій.
Реєстр агентів AWS
Реєстр агентів на AWS тепер доступний для широкого використання. Це своєрідний приватний каталог із вбудованою системою управління, який може містити агентів, сервери MCP, картки агентів A2A, навички та довільні користувацькі ресурси. У проекту навмисно розділено два рівні. Адміністратори працюють на рівні управління, де записи схвалюються чи відхиляються; користувачі здійснюють запити на рівні пошуку, який відображає лише схвалені записи. Кожен запис проходить через п’ять станів (проєкт, у процесі, схвалено, відхилено, застаріло). Переходи між цими станами здійснюються за допомогою подій EventBridge, а CloudTrail веде журнал аудиту.
З початком загальної доступності з’явилась підтримка інфраструктури як коду (CloudFormation, CDK та Terraform), можливість обміну даними між рахунками через RAM, а також автоматичне виявлення в усій організації агентів, які вже працюють на AgentCore. Цю функцію легко проігнорувати, проте вона існує тому, що неконтрольовані „тіньові“ агенти вже стали справжньою проблемою у керуванні активами. Серед компаній, які вже впровадили цей інструмент, — Southwest, PepsiCo, Syngenta, Amdocs та Sony, що свідчить про те, що клієнти вже перейшли від етапу тестувань. AWS детально описує цю концепцію у своєму блозі про машинне навчання.
Agentic Resource Discovery (ARD)
Окрім цього, специфікація, підтримувана кількома постачальниками, також пристосована для усунення цієї прогалини. Agentic Resource Discovery була створена співавторами з Google, Microsoft та Hugging Face та оприлюднена під ліцензією Apache 2.0; до її розробки також долучилися NVIDIA, Salesforce та Databricks. Стаття The New Stack описує її як DNS для агентів. Її інтерфейс навмисно залишений простим. Повідомлення передаються у форматі JSON-LD через REST. Обов’язковим є лише один кінцевий пункт — POST /search — до якого надсилається опис завдання замість назви ресурсу. Кінцеві пункти для перегляду є необов’язковими. Федерація дозволяє компанії зберігати свій власний каталог у приватному режимі, одночасно передаючи запити до зовнішніх реєстрів, яким вона довіряє. На момент написання специфікація знаходиться на версії 0.91, її механізм управління все ще залишається відкритим, і W3C згадується як один із можливих організаторів її подальшого розвитку.
Постійна перевірка як продукт
Третьою компанією, яка вийшла на ринок, був стартап AIR, який працював у таємниці та зібрав 50 мільйонів доларів за два раунди фінансування (Sequoia очолив перший, Greenoaks — другий). Його діяльність полягає у перевірці плагінів, навичок та серверів MCP, які використовують агенти. Одна з їхніх статистик, яку варто пам’ятати: приблизно 27% навичок та додатків з відкритим кодом, які вони наразі оцінюють, відсіваються.
Коли три компанії протягом кількох днів зосереджуються на одному аспекті, це зазвичай означає, що галузь досягла згоди щодо того, де знаходиться відсутній елемент.
Чому пошук не є завданням MCP
MCP ніколи не стверджував, що вирішує проблему пошуку інструментів. Він визначає механізм виклику інструменту після того, як агент вже вирішив, який саме використати. A2A виконує аналогічну функцію для розмов між агентами, які вже знають один про одного. У обох випадках припускається, що пошук та вибір необхідної функціональності вже відбулися раніше. Якщо ви хочете ознайомитися з цим розмежуванням більш детально, перегляньте як Model Context Protocol дозволяє агентам знаходити та викликати інструменти.
Змінилась кількість. Підключення серверів MCP вручну є контрольованим процесом за допомогою кількох інструментів. Однак коли їх більше тисячі, якими володіють різні внутрішні команди, постачальники SaaS та хмарні платформи, агент, обмежений жорстко визначеним списком у своїй конфігурації, ледве можна вважати агентом; він більше схожий на фіксований скрипт, який випадково викликає модель. Механізм виявлення дозволяє змінювати набір можливостей під час виконання. Однак це означає, що ніхто не перевіряв цей набір, і лише деякі команди врахували цей компроміс у своїх оцінках.
Ще один фактор тиску походить від способу розширення агентів. Дослідники, які вивчили код одинадцяти інструментів для створення агентів, що налічують близько чотирьох мільйонів рядків коду та включають такі засоби, як OpenHands, Gemini CLI, Codex CLI та Claude Code (arXiv 2609.00006), виявили, що там навички у форматі SKILL.md випередили MCP: дев’ять із одинадцяти інструментів підтримують навички, а вісім — MCP. Отже, найшвидше поширюваним механізмом розширення є Markdown-файл, наповнений інструкціями, які буде виконувати агент. Такі файли не мають механізму підпису та майже не підтримують версіонування, тому запис у реєстрі, що посилається на один з них, мало що говорить про те, якою буде його функціональність завтра.
Чотири запитання, на які має відповісти реєстр
Кожного разу, коли агент збирається використати функціонал, який раніше у нього не був, потрібні чотири окремі відповіді. Вони звучать схоже, але стосуються різних проблем, і їх розділення дозволяє побачити, що насправді робить даний продукт у порівнянні з тим, заради чого його купують.
Існування: чи є щось, що це робить?
Чи існує якийсь функціонал, який може виконати це завдання, і де він розміщений? Саме для цього призначений метод POST /search у ARD, а механізм виявлення AWS також добре справляється з цим завданням. Проблема є реальною, і з практичної точки зору вона вже майже вирішена.
Підходящість: який варіант підходить для цього завдання?
Пошук повертає кілька варіантів, тож який з них має використовувати агент? Самі автори ARD кажуть, що тут порівняння DNS не працює: запит повертає кілька варіантів замість однієї авторитетної адреси, і кожен сервіс застосовує власні правила довіри та ранжування. Залишити це нерозрішеним є доцільним для молодої специфікації. Однак це недоцільно для вашого впровадження, адже саме у процесі ранжування зловмисник найбільше хотів би втрутитися, подібно до отруєння пошукових систем чи зловживань іменами доменів у реєстрах пакетів.
Статус: чи схвалено зараз?
Саме тут AWS є найсильнішим: стани життєвого циклу разом із подіями забезпечують чітку модель відповідей, яка є більш розвиненою, ніж у будь-яких інших системах. Слабкістю є те, що схвалення може застаріти. Припустимо, запис було виявлено автоматичним способом, схвалено у березні, а потім проігноровано. До вересня система все одно буде розглядати його з такою ж впевненістю, ніби його ще сьогодні вранці перевірив куратор.
Походження: хто його написав та що змінилося?
Хто створив цю функціональність, що змінилося з моменту останнього огляду та що вона завантажує під час роботи? Жоден з поточних запусків не дає відповідей на ці питання, і саме це є основою фінансування AIR. Їхня позиція, яка залишається актуальною, полягає у тому, що перевірка має бути постійною, а не одноразовою. Навичка, яка пройшла перевірку місяць тому, може стати шкідливою після оновлення залежностей чи захоплення облікового запису адміністратора, при цьому її запис у каталозі залишається абсолютно незмінним. Академічні дослідження підтверджують це. Нещодавні дослідження основ агентів, заснованих на навичках (arXiv 2608.29596), моделюють життєвий цикл у дев’ять етапів та розміщують публічні реєстри, ринки та конкурентів у центр архітектури, замість того щоб розглядати їх як додаткові елементи після запуску.
Проблеми пошуку проти проблем ланцюга постачання
Перші два запитання стосуються пошуку. Останні два — ланцюга постачання, і галузь вже стикалася з цим раніше через розширення браузерів, базові зображення контейнерів та пакети npm. У кожному випадку каталоги існували задовго до того, як хтось міг підтвердити їхній вміст, і саме в цей період траплялися інциденти з безпекою.
Останній перевірений тест
Ця перевірка робиться навмисно простою, тому що відповідь має більше значення, ніж сама платформа. Візьміть свій поточний список можливостей агента — це може бути належний реєстр чи просто таблиця — та виберіть будь-який запис. Потім знайдіть два часові позначення:
- Коли він був схвалений?
- Коли востаннє хтось, чи то людина, чи автоматизована процедура, порівнював його з вихідним кодом?
Коли ці часові позначки збігаються, у вас є каталог, а не план керування. Перша фіксує рішення, прийняте раніше; друга відображає поточну реальність. Підрахуйте кількість днів між цими двома датами: саме стільки часу здатність, схвалена кимось та потім забута, залишалася доступною для змін без уваги інших. Враховуючи, що близько чверті навичок, доступних для загального користування, вже не пройшли базову перевірку, це число є об’єктивним показником вашої реальної вразливості.
У багатьох командах немає другої часової позначки для відображення. Саме ця відсутність є справжнім наслідком: проблема полягає не у поганому значенні, а у відсутності поля.
Що робити цього кварталу
Практичний план складається з трьох частин у порядку зростання складності.
- Впровадіть реєстр. Проблема інвентаризації є справжньою, а неконтрольований агент є небезпечнішим за неконтрольовану підписку SaaS, оскільки він діє самостійно. Команди, які вже працюють з Bedrock, повинні уважно розглянути варіант AWS; ті, хто потребує федерації та нейтралітету постачальника, можуть віддати перевагу ARD.
- Додайте поле, якого бракує у реєстрі. Надайте кожному запису час останньої перевірки, який оновлюватиметься автоматизованою програмою, а не людиною. Заздалегідь вирішіть, що спричинить застаріння: закінчення терміну, кварантин чи сповіщення. Будь-який з цих варіантів кращий за сучасну типову практику, коли застарілий запис просто залишається активним необмежений час.
Корисним доповненням до цього плану є шар керування під час виконання, який визначає, що саме може робити виявлена функція; права доступу, бар’єри схвалення та рівні ризику для агентів охоплюють цей аспект.
Основні висновки
- Реєстри та специфікації виявлення тепер досить добре відповідають на запитання „що існує“ та „чи схвалено це“.