Як ProvenanceGuard виявляє, коли MCP-агент посилається на не те джерело?

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

ProvenanceGuard ставить інше питання: чи саме джерело, на яке посилається відповідь, дійсно підтверджує це твердження?

Назва режиму помилки

Конфлюзія між джерелами виникає, коли твердження істинне в одному виводі інструменту, але відповідь атрибутує його іншому. Агент підтримки клієнтів може заявити: запис обіцяє 30-денне вікно для повернення. Вікно існує в політичному документі. Об'єднати два виводи — і твердження виглядає підтвердженим. Розділити їх — і атрибуція стає помилковою. У клінічному агенті деталь препарату з історії хвороби стає влучною, як тільки відповідь подає її як висновок з медичної літератури.

Перевірники, сліпі до джерел, пропускають твердження, бо факт десь є в супі. ProvenanceGuard зберігає зв'язок між твердженням і джерелом видимим для інспекції.

Що робить шар після генерації

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

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

Моделі, використані в звітних експериментах

Для тестів статті команда запускала все локально, щоб журнали залишилися в контрольованому автономному середовищі. MiniLM допомагав знаходити релевантне джерело. Модель DeBERTa NLI перевіряла, чи підтримує це джерело твердження. Локальна мовна модель допомагала розбивати відповіді на твердження. Верифікатор також ретельно перевіряє літеральні значення: число, дата, ідентифікатор — якщо їх немає в джерелі, вони не можуть пройти лише тому, що речення звучить правдоподібно. Калібрований крок рішення поєднує ці сигнали.

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

Результати з 281 медичного журналу

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

Експерти стверджували: 139 тверджень не повинні пройти. ProvenanceGuard виявив 138 з них. Один пройшов. Він також затримав 67 тверджень, які експерти вважали підтвердженими, надіславши їх на перегляд або ремонт. Це відображає обережний налаштований режим: він віддає перевагу повторному погляду на деякі підтримувані твердження над тим, щоб пропустити непідтримувані.

Для тверджень з ідентифікованим джерелом система вибирала правильне джерело приблизно у 86 відсотках випадків.

Порівняння з базовими лініями, сліпими до джерел

Чотири інші перевірники підтримки запускали на тих самих твердженнях. ProvenanceGuard показав найкращий результат за мірою статті: як добре система ловить твердження, які треба заблокувати, уникаючи зайвих блокувань.

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

Коли джерела виглядають схоже

У окремому складнішому тесті з кількома схожими джерелами ProvenanceGuard набрав 0.846 F1 за рішенням, які твердження заблокувати, але ідентифікував точне джерело правильно лише у 50,3 відсотках тверджень. Розрізнення схожих джерел залишається важливим викликом для покращення.

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

Ремонт заблокованих відповідей

Блокування корисне лише тоді, коли є що робити з заблокованою відповіддю. Підключене до ремонтного циклу типу RARR повний журнал вирішив усі 173 заблоковані відповіді, хоча 144 з них завершилися запасним текстом, а не суттєвим переписуванням. Система обрала уникнення неперевіреної відповіді замість її вигадування. На реконструйованих багатоджерельних тестових журналах свіжий ремонт вирішив усі 59 спочатку заблокованих відповідей з лише двома термінальними запасними варіантами.

Як автономний фільтр накладні витрати скромні: приблизно пів секунди на відповідь у звітній локальній конфігурації, з викликами NLI та маршрутизації в десятки мілісекунд.

Де ще зустрічається підхід

NVIDIA NVFlow інтегрував опціональний етап верифікації ґрунтування для свого фінансового агента. Він перевіряє готові відповіді проти витягів SEC, які агент отримав, і зберігає окремі рішення без зміни оригінального викатку чи тренувальних даних. Внесок NVFlow використовує підхід ProvenanceGuard до верифікації, усвідомленої джерелом; ремонтний цикл, обговорений вище, належить до ширшої дослідницької системи.

Цю роботу також презентували як постер на Agentic AI Summit 2026 в UC Berkeley.

Чого стаття не охоплює

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