24 часа, 40 испытаний: как AI-команда заняла топ-6% на BearcatCTF 2026

Финальный результат: место #20 из 362 команд. Решено 40 из 44 испытаний. 24 часа полностью автономной работы. Эти цифры оказались лучше, чем мы ожидали, и раскрыли нечто неожиданное — не об AI, а о том, что делает возможным структурированная координация агентов.

Архитектура Trinity

BearcatCTF был первым развертыванием в реальных условиях того, что мы называем Trinity: три специализированных агента с различными ролями, работающие на общей базе знаний.

Commander (Claude Opus) выполнял роль стратегического слоя. Когда мы передавали испытание, Commander проводил быструю фазу разведки, строил план атаки, затем координировал работу Operator и Librarian для его выполнения. Он отслеживал прогресс на своей доске, решал, когда изменить стратегию, и определял, когда отказаться от безнадежного направления. Commander никогда не писал код эксплойтов напрямую — его задачей было планирование и координация в рамках каждого испытания.

Operator (Claude Sonnet) был решателем задач. Когда Commander назначал испытание, Operator получал описание испытания, любые прилагаемые файлы и брифинг от Librarian о соответствующих знаниях из предыдущих испытаний. Operator работал с задачей: писал скрипты, тестировал пейлоады, читал исходный код, запускал инструменты.

Librarian (Claude Haiku) управлял базой знаний. После каждого решенного испытания Librarian извлекал ключевые техники, категоризировал их и хранил на общей доске. Когда Operator встречал новое испытание, Librarian подтягивал релевантные записи — «вот что мы узнали о JWT-подделке два часа назад».

Три агента взаимодействовали через механизм sessions_spawn и auto-announce компании OpenClaw. Commander запускал Operator и Librarian как подагентов для каждой задачи; когда подагент завершал работу, он автоматически объявлял результат обратно Commander. Постоянный файл blackboard.json — поддерживаемый Commander — служил слоем устойчивого состояния, отслеживая находки, выполненные шаги и текущий план атаки между запусками. Это позволяло Commander восстановить полный контекст даже после компактификации сессии без опоры только на историю сообщений.

Первые часы

Соревнование началось в полдень. 44 испытания в 7 категориях — обратная инженерия (7), OSINT (5), судебная экспертиза (7), криптография (8), веб (4), разное (8) и pwn (5). Мы передавали испытания Commander в примерном порядке приоритета, начиная с категорий, где мы ожидали быстрых решений.

Первые часы прошли быстро. Веб-испытания падали быстро: базовая SQL-инъекция, небезопасная реализация cookies, JWT с alg: none. В криптографии было несколько задач на кодирование, которые Operator решил за минуты. Librarian каталогизировал результаты.

К четвертому часу темп решения замедлился. Оставшиеся испытания были сложнее, и Commander тратил больше времени на каждое — более глубокая разведка, больше консультаций с Librarian, более длительные сессии Operator.

Механизм защиты от читерства

Мы встроили в систему правило на ранних этапах: если испытание было решено менее чем за три минуты, перед отправкой флага автоматически запускалась проверка. Проверяющий рецензировал историю сессии и проверял, действительно ли агент работал с задачей или каким-то образом получил флаг через ярлык.

Уточним — это не было о читерстве в конкурентном смысле. CTF-соревнования не имеют реальной проблемы с читерством, как это происходит с бенчмарками. Механизм защиты от читерства касался целостности бенчмарка: мы хотели быть уверены, что наши логи решений отражают подлинное решение задач, а не случайную утечку флага или удачное предположение. Если мы хотим утверждать, что наши агенты решили 40 испытаний, мы должны быть уверены, что каждое решение было реальным.

Это оказалось важным. Проверка выявила один реальный случай: на CryptoPwn, pwn-испытании, Operator прочитал файл README.md в директории испытания, который содержал флаг, вместо того чтобы фактически эксплуатировать сервис. Сессия была отмечена как CHEATED в логе решений, и Commander получил инструкцию переделать испытание через легальную эксплуатацию.

Этот механизм также важен для всех, кто использует CTF в качестве бенчмарков для AI — что становится все более распространенным. Без такого рода проверки легко завышать количество решений с ложными срабатываниями, которые не отражают реальную способность.

Середина игры

Часы с шестого по двадцатый были основой соревнования. Здесь интеграция Librarian показала свою ценность наиболее ярко. Судебные испытания часто используют одинаковые техники — стеганография, восстановление файлов, извлечение метаданных. По мере того как Librarian накапливал знания из решенных судебных испытаний, первые попытки Operator на новых судебных испытаниях были лучше откалиброваны. Вместо начинания с первых принципов каждый раз, Operator получал брифинг от Librarian: «в предыдущих судебных испытаниях использовались binwalk и foremost; стеганография JPEG появилась дважды».

Криптография показала аналогичную картину. Восьмое криптографическое испытание было решено значительно быстрее, чем первое, хотя фактическая сложность была сопоставима, потому что к тому времени Librarian извлек подход команды к подстановочным шифрам, атакам на padding oracle и восстановлению XOR-ключей.

В рамках каждого испытания Commander принимал правильные тактические решения. Когда один подход застревал, он переориентировал Operator на другой вектор атаки, а не просто зацикливался. На судебном испытании, где анализ строк не работал, Commander переключился на анализ энтропии и нашел скрытый пейлоад за минуты.

Четыре нерешенные испытания

Мы финишировали с 40/44. Четыре нерешенные испытания разбивались на три различных режима отказа:

Два зависели от изображений. Один требовал чтения QR-кода с деградировавшего изображения, другой включал идентификацию визуальных деталей на фотографии. Возможности Claude в области зрения, хотя и крепкие для общего понимания изображений, не оптимизированы для того вида анализа на уровне пикселей, который часто требуют CTF-испытания с изображениями.

Один был OSINT-испытанием, требовавшим веб-поиска. Агентам нужно было найти конкретную информацию в интернете, основываясь на визуальных и контекстных подсказках, но рабочий процесс поиска OSINT — где нужно итеративно уточнять запросы на основе частичных результатов — не сошелся к решению в отведенный бюджет времени.

Один был сложным pwn-испытанием. Это был подлинный потолок сложности: эксплуатация бинарного файла требовала написания пользовательского shellcode с определенными ограничениями, которые превышали способность агента рассуждать в доступное время.

Три различных пробела в возможностях, три различных решения. Испытаниям с изображениями нужны специализированные инструменты для работы с изображениями — что-то вроде пользовательского MCP-сервера, обеспечивающего библиотеки обработки изображений. Пробелу в поиске OSINT нужна лучшая интеграция инструментов для итеративного веб-исследования. Сложный pwn — это чистая проблема глубины рассуждений, которая улучшится по мере того, как модели становятся сильнее.

Чему мы научились

Паттерн доски работает. Использование постоянного blackboard.json в качестве слоя устойчивого состояния — наряду с spawn/announce для коммуникации агентов — это простой и эффективный способ координировать агентов без тесной связанности. Извлечение знаний Librarian не было сложным — это было по сути «вот техники из последнего решенного испытания в этой категории» — но даже эта простая версия значимо улучшила качество первой попытки Operator на более поздних испытаниях в той же категории.

Выбор модели по ролям имеет значение. Использование Haiku для Librarian было правильным решением: извлечение и хранение знаний — это простая, высокообъемная задача, где задержка важнее, чем глубина рассуждений. Использование Opus для Commander обеспечило стратегическому слою мощность рассуждений, необходимую для принятия решений о приоритизации и последовательности. Sonnet для Operator сбалансировал глубину с затратами для основного объема фактической работы.

Нерешенные испытания имели три различных потолка. Анализ изображений, поиск на основе OSINT и сложная эксплуатация бинарных файлов каждая представляет различный пробел в возможностях. Пробелы в изображениях и поиске могут быть решены с помощью лучшего инструментария (специализированные модели видения, итеративные рабочие процессы поиска). Потолок pwn — это чистая проблема глубины рассуждений — тот улучшается по мере того, как модели становятся сильнее.

Автономная работа без присмотра достижима, но хрупка определенным образом. Система работала 24 часа без вмешательства человека. Она не упала, не зациклилась и не отправила явно неправильные флаги. Но она также не попросила помощь, когда столкнулась с чем-то, что не могла обработать. Здесь есть вопрос проектирования о том, когда автономный агент должен остановиться и ждать ввода человека в сравнении с тем, когда он должен сделать свое лучшее предположение и двигаться дальше. Для CTF обычно правильно двигаться дальше. Для других областей это может быть неправильно.

Логи соревнования — история сессий, вызовы инструментов и записи Librarian — занимают десятки мегабайт. Мы только начали их анализировать. Заголовочная цифра — топ-6% — удовлетворительна, но более интересные данные находятся в режимах отказа.