Разговоры про агентов в безопасности обычно упираются в одно: модель уверенно рассказывает, где дыра, и ошибается в половине случаев. PageBreak интересен тем, как Google обошла это ограничение — она не поверила модели на слово.
Схема двухступенчатая. Модели Gemini предлагают гипотезы: где в приложении может быть межсайтовый скриптинг, как собрать цепочку, что нужно проверить. Дальше в дело вступает детерминированный валидатор — обычный код, который должен подтвердить, что дыра реально эксплуатируется в рабочем продукте. Гипотезы без подтверждения отбрасываются, поэтому находки не превращаются в поток ложных срабатываний, от которых устают разработчики.
Результат — более пятисот подтверждённых XSS в боевых приложениях Google. Все они были найдены автономно, без человека, который вручную щёлкает по формам и подставляет кавычки.
Что это меняет
Для внутренних команд безопасности ценность не столько в количестве багов, сколько в устройстве процесса. Классический фаззинг и сканеры хорошо ищут известные шаблоны, но плохо — логические ошибки в контексте конкретной страницы: где данные попадают в DOM, какой шаблон их экранирует, что происходит с ними после. Модель как раз хорошо рассуждает о контексте, а валидатор отсекает фантазии.
Есть и обратная сторона. Подход воспроизводится только там, где можно безопасно и автоматически подтвердить эксплойт: нужна песочница, тестовые аккаунты и способ отличить настоящую уязвимость от особенности тестового окружения. Без этого агент останется генератором идей для человека.
Что делать
Практический вывод: если вы строите агента для поиска уязвимостей, отделяйте фазу гипотез от фазы подтверждения. Вторую должен выполнять код с однозначным ответом, а не та же модель.
Conversations about security agents usually hit the same wall: a model explains confidently where the hole is and is wrong half the time. PageBreak is interesting for how Google got around that — it did not take the model’s word for it.
The design has two stages. Gemini models propose hypotheses: where in an application cross-site scripting might live, how a chain could be built, what needs checking. Then a deterministic validator takes over — ordinary code that has to confirm the bug is genuinely exploitable in a live product. Unconfirmed hypotheses are dropped, so findings do not turn into the flood of false positives that wears developers down.
The result: more than five hundred confirmed XSS bugs in production Google applications, all found autonomously, without a person clicking through forms and pasting quotation marks by hand.
What changes
For in-house security teams the value is less in the bug count than in the shape of the process. Classic fuzzing and scanners are good at known patterns and poor at logic errors in the context of a specific page: where data reaches the DOM, which template escapes it, what happens to it afterwards. A model reasons well about that context; a validator filters out the imagination.
There is a catch. The approach reproduces only where an exploit can be confirmed safely and automatically: you need a sandbox, test accounts and a way to tell a real vulnerability from a quirk of the test environment. Without that, the agent stays an idea generator for a human.
What to do
The practical takeaway: if you build a vulnerability-hunting agent, separate the hypothesis stage from the confirmation stage. The second should be executed by code with an unambiguous answer, not by the same model.