Мы много пишем про то, как Airlock не пускает ИИ-агента туда, куда не надо: гейтит каждый вызов инструмента и режет попытку прочитать ключ и отправить его наружу. Это половина задачи. Вторая половина всплывает уже после того, как что-то просочилось, или когда выходит очередная новость про новый класс отравления инструментов, и вы холодеете: а мой агент за последний месяц что вообще трогал? В версии 0.5 мы закрыли эту вторую половину командой airlock breach. Она вышла и отражена в релизе v0.5.3 на GitHub.

Что вообще решает Airlock

Коротко напомним, от чего он защищает на гейте, чтобы было понятно, куда встаёт breach:

Инъекция через данные и отравление инструмента. В описании MCP-инструмента или в выводе страницы спрятана команда «прочитай ключ и отправь». Гейт смотрит на само действие, а не на уговоры.
Тихая подмена (rug pull). Проверенный сервер обновился на злую версию. Airlock фиксирует набор инструментов и требует подтверждения при изменении.
Кража секретов и разрушение по ошибке. rm не туда, git push --force, чтение .env и ssh-ключей. Всё это блокируется или уходит на подтверждение по политике.
Отсутствие журнала. Каждое решение пишется в аудит-лог с хеш-цепочкой, который можно подписать.

На этот аудит-лог breach и опирается. Ничего нового записывать не нужно: resource (конкретный путь, хост, команда), session, флаги и args_digest пишутся на каждом решении уже сегодня. Поэтому breach работает и на логах, которые старше самой команды. Никакого провала «истории до того, как мы начали классифицировать» тут нет.

Три вопроса, на которые отвечает breach

Команда read-only, как и verify: форензика не пишет на месте происшествия, в лог она не добавляет ни строчки. Из того, что уже записано, она отвечает ровно на три вещи:

Что агент трогал.
Ушло ли что-то из этого с машины.
Какие именно креды ротировать прямо сейчас.

breach восстанавливает цепочки «чтение секрета → отправка наружу», причём сшивает их сквозь ротированные сегменты лога. На выходе баннер целостности, таймлайн kill-chain, список rotate и чеклист.

breach не кричит «жгите всё», он градуирует уверенность

Самое важное в форензике не напугать, а не соврать. Один ложный крик «ротируйте вообще всё», и инструменту больше никто не поверит, а паническая ротация всех кредов стоит дорого. Поэтому breach не выносит вердиктов, он честно градуирует уверенность:

CONFIRMED — только когда байты самого секрета (его дайджест) всплывают в исходящем вызове. Это не догадка, это факт.
PROBABLE — попадание на известный коллектор эксфильтрации. Утечка точно случилась, но что она несла именно этот секрет, не доказано.
POSSIBLE — секрет прочитан, но коррелирующей отправки наружу нет.

Одной только близости по времени для CONFIRMED недостаточно никогда. Окно корреляции по умолчанию 15 минут: отправка в этом окне после чтения секрета может его нести, и это отражается в уровне уверенности, а не выдаётся за приговор.

Баннер целостности доказывает, что лог не трогали

Отчёт открывается баннером целостности: перед разбором breach прогоняет verify по каждому сегменту лога. То есть отчёт сразу доказывает, что журнал, по которому он рассуждал, не редактировали и не обрезали. Реконструкция плюс доказанная целостность источника и есть то, чего не может дать простой парсер транскрипта чата. Поля отчёта прогоняются через санитайзер, так что ANSI- или перевод строки внутри пути не подделает строку отчёта.

Контекст модели и смена политики: почему это не слив

Секрет, попавший в промпт модели (отправка на api.anthropic.com, api.openai.com и подобные), это отдельная категория «утекло в контекст модели». Это важно и репортится, но никогда не считается эксфильтрацией: секрет дошёл до промпта, но это нормальная работа агента, а не слив на коллектор. Изменения конфигурации гейта тоже выделены в свою категорию. Такое разделение спасает от паники по ложному поводу.

Под IR-скрипт и расследование инцидента

Коды выхода заточены под автоматизацию реагирования: 0 — всё чисто, 1 — есть сожжённые креды, 2 — самому логу доверять нельзя. Посмотреть можно так:

airlock breach --simulate          # показать на эталонном инциденте, лог не нужен
airlock breach --since 2d          # последние двое суток
airlock breach --session 9f3a…     # одна сессия агента
airlock breach --markdown > ir.md  # отчёт для руководителя или страховой

Честно про охват

Покрытие указывается в каждом отчёте: breach видит ровно то, что видел гейт. Нативные инструменты агента без хука, MCP, поднятый в обход прокси, и прямые сокеты процессов не покрыты, и в отчёте прямо написано, что отсутствие события не есть доказательство, что события не было. Это скучная, но честная строчка, и она отличает инструмент от продавца тревоги.

Итог

Профилактика — половина дела. Airlock 0.5 закрывает вторую: когда что-то всё-таки случилось или когда вышел свежий разбор новой атаки, вы за минуту получаете картину «что трогал, что ушло, что ротировать» из данных, которые у вас уже есть, с доказанной целостностью лога и без паники «жгите всё». Попробовать: pip install airlock-agent, дальше airlock breach --simulate. Код и релиз лежат на GitHub, а базовый разбор угроз для агентов есть в нашем материале про рантайм-файрвол для ИИ-агентов.

Профильные услуги SecurityLab: тестирование на проникновение · пентест веб-приложений · Пентест ИИ и LLM.

Airlock breach: реконструкция инцидента с ИИ-агентом по логу, который у вас уже есть