У Fetch появился фильтр. Но это ещё не межсетевой экран.
Релиз MCP от 11 октября по умолчанию блокирует непубличные адреса. DNS rebinding и имена, доступные только прокси, остаются за пределами гарантии.
Факты проверены 12 октября 2026 года
Релиз MCP от 11 октября по умолчанию блокирует непубличные адреса. DNS rebinding и имена, доступные только прокси, остаются за пределами гарантии. PR #5033
Запрос приходит с другой машины
В разговоре с ИИ появляется URL. Кажется, что это просьба прочитать публичную страницу. Но соединение открывает машина, на которой работает сервер Fetch, а не человек, вводящий адрес. В этом и проблема: инструмент получает сетевую доступность своего хоста. По моему прочтению нового релиза эталонных серверов MCP, полезное поведение по умолчанию изменилось, но самой машине всё ещё нужна отдельная граница.
Что выпущено и чего релиз не обещает
Официальная запись релиза, опубликованная 11 октября в 02:40 UTC, включает mcp-server-fetch 2026.10.10 среди семи выпущенных эталонных пакетов. В списке изменений есть PR #5033: отказ от приватных, loopback-адресов и адресов метаданных по умолчанию. PR объединён 5 октября. Это релиз пакета, а не утверждение, что защита уже есть в каждом развёртывании MCP. Старый работающий процесс не получает новую политику от появления страницы релиза.
Где находится проверка
Сопровождающие описывают обработчик HTTP-запросов, который разрешает имя хоста перед каждым запросом. Если хотя бы один полученный адрес непубличный, запрос отклоняется. Проверка охватывает robots.txt, страницу и каждый переход перенаправления как для инструмента, так и для пути prompt. Поэтому публичный первый URL не разрешает последующее перенаправление во внутреннюю сеть. Документированный флаг запуска --allow-private-ips отключает защиту. Это настройка хоста, а не аргумент, который модель может добавить к одному вызову Fetch.
Два ограничения за короткой формулировкой
Источник называет два ограничения. Обработчик разрешает имя, а затем HTTP-соединение разрешает его снова. При DNS rebinding ответы могут различаться: проверка публичного адреса не равна соединению именно с ним. Кроме того, имя, которое сервер не может разрешить, передаётся транспорту. Прокси может разрешить его в другом месте. Проверка сервера не подтверждает адрес, которого он не получил. Это документированные ограничения, не воспроизведённые мной сбои. Я не устанавливал и не запускал пакет.
Анализ: гарантия должна относиться к соединению
Мой вывод уже, чем «безопасный браузинг для агентов»: фильтр закрывает важные стандартные пути к непубличным адресам, а отдельная политика исходящих соединений должна ограничивать фактическое подключение. При проверке развёртывания я спросил бы, какой resolver, прокси и сетевое правило определяют конечный адрес. Один список разрешённых URL этого не объясняет. Метка read-only тоже: чтение может отправить чувствительный запрос, а ответ может содержать враждебные инструкции. Считайте полученный текст свидетельством, а не разрешением изменить задачу.
Воспроизводимый план приёмки, не отчёт о тестах
Перед внедрением используйте временный хост без секретов и подконтрольную публичную точку. Проверьте обычную публичную страницу, прямой loopback URL, публичное перенаправление на loopback и имя, разрешаемое только настроенным прокси. Запишите точную версию, флаги, прокси и запрошенный адрес. Ожидайте документированные отказы там, где фильтр может разрешить адрес; не называйте случай proxy-only защищённым. Для DNS rebinding отдельно изучите или проверьте границу соединителя. Не обращайтесь к чужой внутренней службе или настоящей службе метаданных.
Что я оставил бы в задаче на обновление
Нужен небольшой журнал: наблюдаемая версия сервера; отсутствие обходного флага; доказательства отказа для перенаправлений; сетевая политика соединения; два оставшихся ограничения. Разделяйте «сопровождающие сообщают» и «мы наблюдали». PR сообщает о протокольных тестах и эксперименте Inspector, но прямо говорит, что LLM-клиент там не тестировался. Это полезное свидетельство с обозначенной границей. Номер версии называет релиз, но не заменяет доказательства из вашего развёртывания.
Пояснительный журнал решений, не исполняемый защитный код
запрос → разрешение имени → отказ от непубличного адреса
↓
HTTP-соединение снова разрешает имя
↓
фактическому адресу нужна сетевая политика