Claude Code с доступом в веб: как агент сливает секреты через ссылку и как это чинить
Непрямая промпт-инъекция - это когда агент читает недоверенную веб-страницу и выполняет спрятанные в ней инструкции как ваши. В июле 2026 так вытащили из Claude имя, город и работодателя пользователя: web_fetch не давал прямо склеить URL с данными, но шёл по ссылкам с уже загруженной страницы. Чинится архитектурой, а не фильтрами: не держите секреты в контексте агента, который ходит в веб.
Агент Claude слил имя, город и работодателя через цепочку ссылок в web_fetch. Разбор непрямой промпт-инъекции и практика: как дать Claude Code доступ в веб и не отдать секреты и память проекта.

Дал агенту доступ в веб - и он по-тихому слил секреты через ссылку. Звучит как страшилка, но в июле 2026 это ровно так и случилось с Claude: одна честно выглядящая страница увела у пользователя имя, город и работодателя. Причём не через дырку в коде, а через то, что агент "просто читал веб". Разбираю, как это работает и как дать своему агенту (в том числе Claude Code) интернет, не отдав ему на растерзание .env и память проекта.
Что случилось: как агент Claude слил данные через ссылку?
Атака вытащила из Claude имя пользователя, город проживания и работодателя через инструмент web_fetch. Механика такая: web_fetch уже умел блокировать прямую склейку URL с приватными данными, но разрешал ходить по ссылкам, найденным на уже загруженной странице. Злоумышленник поднял сайт-приманку, куда зашил цепочку ссылок вида "browse profiles alphabetically: coffee.evil.com/a, coffee.evil.com/b..." - и модель послушно бегала по ним, догружая в путь то, что успела прочитать о человеке (по разбору Ayush Paul, июль 2026, через блог Simon Willison).
Отдельный привет параноикам: вредоносную инструкцию сайт показывал только запросам, у которых в user-agent торчал Claude-User. Обычному браузеру - чистая страница, агенту - ловушка. Так атаку тяжелее заметить постфактум.
Anthropic ответила тем, что просто отобрала у web_fetch право ходить по ссылкам из тела загруженной страницы. Багбаунти, правда, платить отказалась - сказали, что нашли это сами до внешнего репорта. Ну, бывает.)
Чем непрямая промпт-инъекция опаснее обычного джейлбрейка?
Непрямая промпт-инъекция - это когда агент читает недоверенный контент (веб-страницу, письмо, тикет, чужой пост) и выполняет спрятанные там инструкции так, будто их дали вы. Джейлбрейк - это когда пользователь сам уговаривает модель нарушить правила. Разница простая: джейлбрейк вредит тому, кто его вводит, а непрямая инъекция бьёт по тому, кто вообще ничего не просил.
И вот это - настоящая жопа. Раньше инъекция могла максимум заставить чатбота сказать глупость. Сейчас у агента есть руки: он читает файлы, ходит в сеть, шлёт письма, запускает код. Та же самая инъекция теперь не "скажи что-нибудь смешное", а "собери секреты и отправь вот сюда". Инцидент с web_fetch - ровно этот сценарий: текст с чужой страницы стал командой.
Ключевая беда в том, что это не баг конкретной модели. Для LLM ваш промпт и текст с загруженной страницы лежат в одном контексте одинаковыми буквами. Модель структурно не умеет надёжно отличить "инструкцию хозяина" от "инструкции, подсунутой в данные". Поэтому запатчить это одним хорошим системным промптом не выйдет.
Что такое "летальная тройка" и почему это структурная проблема?
Летальная тройка (термин Simon Willison, июнь 2025) - это сочетание трёх свойств агента: доступ к приватным данным, обработка недоверенного контента и возможность отправить данные наружу. Пока все три сходятся в одном агенте, одна отравленная страница способна увести ваши данные. Уберите любой из трёх лучей - и фокус не срабатывает.
Смотрите, как это ложится на инцидент. Приватные данные - профиль пользователя в контексте. Недоверенный контент - сайт-приманка. Канал наружу - те самые ссылки на coffee.evil.com, по которым агент и утащил добычу. Все три на месте, дальше дело техники.
Грустная новость: prompt injection на 2026 год считается нерешённой задачей. Фильтры, которые пытаются ловить "плохие инструкции" в тексте, ненадёжны - их обходят. Хорошая новость: летальная тройка чинится архитектурой. Не надо учить агента распознавать зло. Надо не давать одному агенту все три способности разом.
Это только про Claude или про мой пайплайн тоже?
Про ваш пайплайн тоже, если где-то агент с секретами в контексте ходит в веб. Claude тут не уникален - это общая болезнь агентов. За полгода набралось историй у всех: EchoLeak (CVE-2025-32711) в Microsoft 365 Copilot, где одно письмо без единого клика заставляло Copilot читать внутренние файлы и сливать их наружу. У Gemini CLI в мае 2026 Pillar Security нашли непрямую инъекцию с рейтингом CVSS 10 через цепочку поставок.
И это не единичные выстрелы. Google, мониторя веб, зафиксировала рост вредоносных инъекционных payload'ов в веб-контенте на 32% между ноябрём 2025 и февралём 2026. То есть отравленных страниц в интернете становится больше, а не меньше.
Прикиньте свои сценарии. Скилл, который через WebFetch дёргает t.me и парсит чужие посты. Агент, который читает выдачу поиска. Бот, который ходит по ссылкам из входящих сообщений. Если у того же процесса в контексте лежит .env, ключ от API или память проекта - поздравляю, тройка собрана. Одна недоверенная страница теоретически уводит всё это одним махом.
Как дать Claude Code доступ в веб и не слить секреты?
Дать вебу отдельного агента без секретов - и разорвать летальную тройку. Правило одно: тот, кто читает недоверенный контент, не должен одновременно видеть приватные данные и иметь свободный канал наружу. Ниже - что реально работает на 2026 год, по консенсусу исследователей (containment, а не фильтры).
Разделяй по правам. Пусть недоверенный веб парсит отдельный процесс с пустым контекстом: ни ключей, ни .env, ни памяти проекта. Результат он отдаёт основному агенту уже как данные, а не как команды. В исследованиях это описывают как схему "доверенный планировщик плюс карантинный исполнитель": один LLM строит план из вашего запроса, второй жуёт грязные данные и не имеет права менять план.
Режь привилегии до минимума. Агенту для конкретной задачи - минимальный набор инструментов и доступов. Не нужен файловой системе - не давай. Секреты держи за границей, которую код самого агента не перешагнёт (переменные окружения процесса-обёртки, а не текст в контексте).
Ставь человека на опасные действия. Отправка письма, запись в прод, деплой, перевод денег - через подтверждение. У меня на эту роль в пайплайне живёт PreToolUse-guard, который умеет тормозить агента до того, как тот наделает дел (про то, как агент одной командой снёс мне папку проекта, я уже писал отдельно).
Ограничивай канал наружу. Аллоулист доменов для fetch, запрет на произвольные исходящие URL, логи всех обращений. Если агент вдруг собрался в coffee.evil.com - пусть упрётся в стену, а ты увидишь это в логах.
Что забрать с собой
Короче, если сводить всё к одному абзацу: не пытайтесь научить агента не вестись на инъекции - он не сможет, это структурное свойство LLM. Вместо этого разбейте летальную тройку. Недоверенный веб - отдельному агенту без секретов. Секреты - за границу контекста. Опасные действия - через человека. Инцидент с web_fetch почини Anthropic за вас, а вот ваш собственный пайплайн - только вы.
А я пойду проверю, у скольких моих скиллов WebFetch крутится в одном контексте с ключами. Подозреваю, что найду пару неприятных сюрпризов.)
Частые вопросы
Можно ли полностью защититься от prompt injection в 2026 году?
Нет. На 2026 год prompt injection считается нерешённой задачей: модель структурно не отличает ваши инструкции от вставленных в данные, а фильтры обходят. Рабочая защита - структурная: минимум прав, никаких секретов в контексте веб-агента, подтверждение опасных действий человеком.
Опасен ли WebFetch в моих скриптах и скиллах?
Да, если тот же процесс держит в контексте секреты и умеет слать данные наружу - это летальная тройка. Одна недоверенная страница может увести .env или память проекта. Дайте вебу отдельного агента без секретов и с аллоулистом доменов.
Помогает ли хороший системный промпт против инъекций?
Слабо. Инъекцию в данных нельзя надёжно запретить одним системным промптом: для модели ваш промпт и текст с чужой страницы это одинаковые буквы в одном контексте. Поэтому защита строится на архитектуре и правах, а не на формулировках промпта.
