AI Extensions, 7 листопада: Quarry і значення незавершеного сканування

Читання файла перед HTTP-запитом може означати інше, ніж ті самі виклики у зворотному порядку. Cisco Project Quarry пропонує правила для послідовностей подій у діалозі агента, а не лише оцінки окремих повідомлень.

Це огляд відкритої альфа-версії й плагіна, перевірений 7 листопада 2026 року. Я прочитав документацію, приклади конфігурації та ліцензію. Пакет не встановлював, модель не підключав, приватні діалоги не сканував і аналіз інциденту Cisco не відтворював. Останній коміт основної гілки датований 3 листопада. Це сигнал супроводу, не оцінка якості.

Плагін відкриває шлях до детектора

Документація плагіна описує п'ять інструментів лише для читання: пошук довідки, компіляцію правила, дерево рішень, підрахунок шляхів рішень і сканування явно переданого JSON діалогу. Через MCP хост агента звертається до локально встановленого рушія. Інструмент сканування сам не читає файли чи збережені сесії. Хост може мати інший доступ до файлів, отже це контракт інструмента, не ізоляція всього сеансу.

Документований запуск використовує репозиторій як єдиний пакет і зафіксовану конфігурацію uv. Підтримуються Python 3.11-3.13. Для локальних прикладів ключ провайдера не потрібний. Семантична модель змінює межу даних: її адаптер може надсилати вибрані частини діалогу на налаштовану адресу.

Файл LICENSE містить Apache 2.0 з вимогами повідомлень і відмовою від гарантій. DSL має альфа-статус і може змінитися до 1.0. Для проби я зафіксував би перевірену ревізію.

Що перевіряє автомат

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

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

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

Зберегти третій результат

CLI розрізняє код 0: завершено без збігів; 1: завершено зі збігами; 2: неправильний ввід або незавершене сканування. Таймаут чи помилка обчислення не означає «нічого не знайдено».

Посібник інтеграції вимагає перевіряти статус перед використанням збігів. QuarryGuard робить це сам; з DSLScanner відповідальність лежить на виклику. Мій пояснювальний приклад не запускався й не реалізує блокування:

def classify_supplied_trace(scanner, conversation):
    result = scanner.scan_data(conversation)
    result.raise_for_status()
    return "matched" if result.rule_matches else "complete_clean"

# Помилки сканування обробляє хост.
# Жоден результат не надає дозволу користувача на дію.

Хост може окремо зупиняти операцію за збігом чи помилкою. Перевірка після HTTP-запиту не зупинить уже надісланого запиту. Чистий результат не створює згоди користувача.

Межі свідчення

За ввімкненого пояснення Quarry повертає підтримувальні події, witness. Для деяких правил рушій вилучає події й повторює перевірку, щоб скоротити набір. Ліміти можуть залишити зайві події; може існувати інший набір. Це одне пояснення, не обов'язково найкоротше чи повна історія інциденту.

Сусідні елементи скороченого witness могли бути далекими в оригінальній трасі. Для правил відстані потрібні початкові позиції. Умови відсутності чи «всі повідомлення» можуть потребувати всього набору; статична умова може збігтися з порожнім witness. Порожнеча сама по собі не означає помилки.

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

Обмежена проба

Я запропонував би вигадані випадки: потрібний порядок читання й запиту, зворотний порядок, безпечну іншу адресу, пошкоджені аргументи та перевищення ліміту. Записувати ревізію правила, завершеність, збіги й початкові позиції. Це план, не результати Quarry.

Перевірене правило -> компіляція -> сканер
Вигадана траса -> перевірка -> завершено без/зі збігом
                        |
                 помилка або незавершеність
                        |
                  окрема політика хоста

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

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

Моя оцінка: Quarry вартий обмеженої проби для перевірюваних правил послідовності. Альфа-статус, адаптери й завершеність мають залишатися в звіті. Публікація Cisco розбирає інцидент контрфактично, без відтворення на його оригінальних даних. Це не показник точності детектора.