0.137.2

16.06.2026

Fixed

Агент с пустым network.ip_whitelist не мог подключиться к LLM-провайдеру на приватном IP (blocked internal/private IP: 192.168.2.57), хотя глобальная настройка ssrf_whitelist (по умолчанию разрешает 192.168.0.0/16) этот IP допускала, а другой агент на тот же эндпоинт работал. Корень проблемы был заложен в: per-agent SSRF-guard (построенный только из network.ip_whitelist/ip_blacklist) прокидывался в LLM-путь агента и для cloud-spec провайдера заменял, а не дополнял глобальный whitelist — пустой список перекрывал «разрешено глобально». Теперь подключение агента к LLM-провайдеру регулируется только глобальным SSRF-guard (endpoint задаёт админ), а per-agent network.ip_whitelist управляет исключительно исходящим доступом инструментов агента (web_fetch/web_search/exec). См. ADR docs/adr/2026-06-16-ssrf-llm-vs-agent-network.md.

Changed

Per-agent SSRF-guard для инструментов = объединение глобального whitelist и network.ip_whitelist агента (internal/agent/loop.go, buildToolsSSRFGuard). Пустой ip_whitelist наследует глобальную политику (раньше = «блокировать всё приватное»); ip_whitelist только расширяет, ip_blacklist — сужает. Внешне для пользователя: «разрешить всё» глобально = реально всё для инструментов агента; сетевые разрешения агента больше не ломают его собственное LLM-подключение.
«Разрешить всё» = всё, кроме cloud-metadata. Добавлен security.alwaysBlockedNetworks (169.254.169.254/32, fd00:ec2::254/128, 100.100.100.200/32 — AWS/GCP/Azure/Oracle/Alibaba IMDS), проверяемый ДО whitelist в SSRFGuard.isPrivate. Теперь при глобальном whitelist 0.0.0.0/0 literally разрешены все диапазоны, кроме metadata-эндпоинтов (защита от утечки учётных данных облачного инстанса). Ранее комментарии в коде утверждали, что metadata «блокируется всегда», но фактически это было неверно — теперь комментарий и поведение совпадают.

Removed

API (internal-пакеты): удалено поле AgentRunSpec.SSRFGuard (internal/agent/types.go), параметр ssrfGuard у RouteStrategy/RouteStrategyWithStore (internal/agent/strategy_router.go), опция WithAgentSSRFGuard и oneshotConfig.ssrfGuard (internal/providers/oneshot.go), а также 3-е возвращаемое значение registerToolsForAgent. Эти символы живут в internal/ (не импортируются извне модуля), поэтому для внешних потребителей ломающих изменений нет. Поле providers.ChatRequest.SSRFGuard сохранено как низкоуровневый механизм providers-слоя, но agent-слой его больше не populate (всегда nil → глобальный guard).