AWS дала агентам веб-поиск без API-ключей: сторож зависимостей отработал за 36 секунд

Модель не знает, что вышло сегодня утром: ни свежих уязвимостей, ни релизов, ни новых цен. Поэтому любому агенту, который работает с актуальными событиями, нужен веб-поиск. В продакшене к нему сразу предъявляют три требования: результаты со ссылками, контроль над тем, каким источникам верить, и гарантия, что поисковые запросы не утекают наружу. По запросам нередко видно, над чем работает команда. AWS закрывает эти требования новым Web Search API в Amazon Bedrock AgentCore и показывает его на практичном примере: ежедневном «сторожe» зависимостей для security-команды.

Что именно запустили

Web Search API отдаёт агенту актуальные результаты одним вызовом. В каждом результате есть заголовок страницы, URL, дата публикации и выдержка, релевантная запросу. Запрос можно ограничить по доменам (включить или исключить) и по диапазону дат. Обслуживает его веб-индекс, которым управляет сама Amazon, а не сторонний поисковик.

Аутентификация идёт через AWS Signature Version 4 с ролью, под которой уже работает агент: на Lambda, ECS или в AgentCore runtime. Отдельного ключа поиска нет, а значит, нечего хранить и ротировать. Для платформенных команд есть второй путь, AgentCore Gateway: администратор задаёт одну политику источников на все агенты и MCP-клиенты, и агент эту политику снять не может.

Для тех, кто сидит на LangChain, инструмент веб-поиска в langchain-aws теперь вызывает этот API. Он работает с LangChain-агентами, LangGraph и Deep Agents.

Как устроен сторож

Граф на LangGraph каждое утро проверяет, не появилось ли что-то новое про пакеты и образы, которые команда выпускает. Три ветки (npm, PyPI, базовые образы контейнеров) идут параллельно. В каждой модель Claude из Bedrock решает, что искать, и в конце возвращает структурированные находки по схеме Pydantic: пакет, заголовок, CVE или ID бюллетеня, заявленная критичность, признак эксплуатации, рекомендуемое действие и URL источника.

Главная идея в разделении труда: модель придумывает запросы и пишет выводы, а всё, что должно выполняться при любом поведении модели, лежит в коде. Инструмент создаётся с фиксированными параметрами: чёрный список доменов, нижняя граница даты, максимум четыре поиска на ветку. Опция model_filters=False оставляет модели один аргумент — текст запроса. Результаты инструмент возвращает дважды: текстом для модели и артефактом для графа, чтобы код мог их проверить.

Перед возвратом каждая находка проходит четыре проверки против того, что вернули поиски этой же ветки:

• URL действительно встречался в результатах;
• заголовок или текст источника называет пакет целым словом;
• CVE или ID из находки есть в тексте источника;
• дата публикации внутри окна наблюдения (нет даты — считается за пределами окна).

Потом шаг keep_new сверяет выжившие находки с хранилищем LangGraph, чтобы одно и то же не приходило дважды, а report собирает таблицу со ссылками.

Что показал прогон

На семидневном окне три ветки сделали 12 поисков и получили 80 источников. Заняло это 36 секунд против 99, если бы ветки шли друг за другом. Проверка отбросила две находки: у одной источник не называл пакет, у другой CVE-номера не было в тексте. Прошли четыре, но отчёт показал две, ещё две уже были в хранилище после ранних тестов. Повторный запуск с теми же данными дал пустой отчёт, как и должно быть у ежедневной задачи.

Ограничения и что делать на практике

Самое важное: проверки ловят выдуманные URL и ID, источники без упоминания пакета и устаревшие страницы. Но они не подтверждают критичность, факт эксплуатации, затронутые версии и рекомендацию. Страница, проиндексированная на этой неделе, может описывать старый инцидент. Для реального security-процесса сверяйте находки с авторитетными базами уязвимостей, и пусть человек смотрит их до любых действий.

Ещё несколько практических деталей:

• InMemoryStore живёт только в рамках сессии. Для ежедневного запуска нужно постоянное хранилище, например DynamoDBStore, а сессии в AgentCore runtime эфемерны.
• Лимит по умолчанию — 10 запросов в секунду на регион на весь аккаунт, параллельные ветки его делят.
• Инструмент называется web_search. Если у агента уже есть другой поиск с таким именем, переименуйте один из них.
• Права нужны минимальные: одно действие bedrock-agentcore:InvokeWebSearch на ресурс, которым владеет AWS.

Выбор между путями простой. Если приложение само вызывает поиск и само задаёт правила, берите API напрямую. Если платформенная команда раздаёт поиск многим агентам и хочет единую политику источников, нужен Gateway. Он же подходит, если поиск нужен MCP-клиентам вроде Claude. Для разных команд достаточно завести отдельный web search target со своим блоклистом.