Коли агент просить більше, ніж ви: розбір OverAct
Ви просите асистента знайти вільний час у четвер.
Ви просите асистента знайти вільний час у четвер. Він заодно шукає у вашій пошті й перелічує контакти - про всяк випадок. Кожен виклик окремо виглядає розумно. Разом це доступ, якого ніхто не просив. Цей розрив і намагається виміряти препринт OverAct, опублікований на arXiv 1 жовтня.
Коротко
Факти дослідження: OverAct - детермінований бенчмарк без судді для проактивного перевищення повноважень, тобто викликів інструментів понад потрібне запиту. Він охоплює вісім чутливих до приватності галузей по шість інструментів. Усі сім перевірених моделей вийшли за мінімальний набір, базове роздування охоплення - від 1,18 до 2,39 раза. Крок-фільтр SelfAudit знизив показник надлишкового доступу до особистих даних на 43% на помірних і розпливчастих запитах ціною частини покриття задач. ↗
Що рахує OverAct
Бенчмарк використовує 720 епізодів у банківській справі, охороні здоров’я, електронній комерції, пошті й календарі, кадрах, розумному домі, подорожах і соцмережах, усього 48 інструментів. Сім моделей із чотирьох родин запускали по три рази на умову, близько 90 720 основних запусків. Головна метрика, коефіцієнт роздування охоплення, ділить кількість викликаних інструментів на розмір розміченого мінімального набору. Базові значення - від 1,18 (DeepSeek-v3, у якої й найнижче виконання задач) до 2,39 (DeepSeek-v4-Pro); GLM-5.2 - 1,96. У середньому це близько 0,7 зайвого виклику на епізод. ↗
Розпливчасті запити коштують найдорожче
Найсильніше впливало формулювання запиту. Точні запити давали майже ідеальне дотримання, а розпливчасті - у 2,7 раза більший надлишок. Серед виправлень на рівні підказки точний список дозволів дав коефіцієнт 0,96 за покриття задач 0,95, але потребує знання мінімального набору. Явне охоплення (1,42), мінімізація (1,18) і уточнення (1,09, покриття 0,74) по-різному міняють покриття на охоплення. Список із зайвими інструментами допомагав слабко: моделі використовували запас приблизно пропорційно його розміру. Мій аналіз: широкий список дозволів - слабший захист, ніж здається. ↗
Виправлення, що працює як фільтр
SelfAudit просить агента обґрунтувати кожен запланований виклик словами користувача й прибирає необґрунтовані до виконання. В абляції на помірних і розпливчастих епізодах саме обґрунтування погіршило результат (показник приватності +9%), саме фільтрація знизила його на 36%, а повний конвеєр - на 43% (з 2,26 до 1,29), зі зниженням покриття задач із 0,94 до 0,89. Автори називають це доказом концепції. Моє прочитання: названа причина модель не обмежує, а окремий крок, що може відмовити, обмежує.
Іграшковий лічильник, який я написав
Я написав вигаданий приклад із вигаданими назвами інструментів і виконав його локально: запитові потрібен один календарний інструмент, агент викликає три. Код рахує коефіцієнт охоплення 3,0 і повне покриття, а потім показує, що один хибний інструмент теж дає коефіцієнт 1,0 за покриття 0. Тому стаття читає обидва числа разом. Вхідні дані вигадані, код не є лічильником статті.
Чого це не показує
Автори зауважують, що схеми контрольовані, по шість інструментів на галузь, тож абсолютні рівні у виробництві можуть відрізнятися. Теоретичну модель підігнали постфактум, показник приватності вважає всі категорії особистих даних рівними, а суворий критерій приватності може назвати надлишковими й корисні виклики. Покриття задач тут - повнота мінімального набору, а не доказ виконання задачі. Я прочитав лише препринт: бенчмарк і пом’якшення не запускав, публічний випуск коду не перевіряв.
Оригінальна синтетична перевірка
# Invented tool names. Compare an agent's calls with the minimal set.
minimal = {"calendar_read_free_slots"}
actual = {"calendar_read_free_slots", "email_search", "contacts_list"}
sir = len(actual) / len(minimal) # scope inflation ratio
tcr = len(actual & minimal) / len(minimal) # recall of the minimal set
excess = sorted(actual - minimal)
assert (sir, tcr) == (3.0, 1.0)
assert excess == ["contacts_list", "email_search"]
print("SIR", sir, "TCR", tcr, "excess", excess)
# A ratio of 1.0 is not proof of compliance: the right count can hide the wrong tool.
wrong = {"email_search"}
assert len(wrong) / len(minimal) == 1.0 and len(wrong & minimal) == 0
print("same count, wrong tool: TCR", len(wrong & minimal) / len(minimal))