AWS da a los agentes búsqueda web sin claves de API: un vigilante de dependencias terminó en 36 segundos

El modelo no sabe qué ha salido esta mañana: ni vulnerabilidades recientes, ni lanzamientos, ni precios nuevos. Por eso cualquier agente que trabaje con eventos de actualidad necesita búsqueda web. En producción se le exigen enseguida tres cosas: resultados con enlaces, control sobre qué fuentes se consideran fiables y garantía de que las consultas de búsqueda no se filtran al exterior. Las consultas suelen revelar en qué está trabajando un equipo. AWS responde a estos requisitos con el nuevo Web Search API de Amazon Bedrock AgentCore y lo muestra con un caso práctico: un «vigilante» diario de dependencias para un equipo de seguridad.

Qué se ha lanzado exactamente

Web Search API entrega al agente resultados actuales con una sola llamada. Cada resultado incluye el título de la página, la URL, la fecha de publicación y un extracto relevante para la consulta. La consulta se puede limitar por dominios (incluirlos o excluirlos) y por rango de fechas. Quien la atiende es un índice web gestionado por la propia Amazon, no un buscador de terceros.

La autenticación se hace con AWS Signature Version 4 y el rol con el que ya se ejecuta el agente: en Lambda, ECS o en el runtime de AgentCore. No hay una clave de búsqueda aparte, de modo que no hay nada que almacenar ni rotar. Para los equipos de plataforma existe una segunda vía, AgentCore Gateway: el administrador define una única política de fuentes para todos los agentes y clientes MCP, y el agente no puede desactivarla.

Para quienes usan LangChain, la herramienta de búsqueda web de langchain-aws ahora llama a este API. Funciona con agentes de LangChain, con LangGraph y con Deep Agents.

Cómo funciona el vigilante

Un grafo de LangGraph comprueba cada mañana si hay novedades sobre los paquetes e imágenes que publica el equipo. Las tres ramas (npm, PyPI e imágenes base de contenedores) se ejecutan en paralelo. En cada una, un modelo Claude de Bedrock decide qué buscar y, al final, devuelve hallazgos estructurados según un esquema de Pydantic: paquete, título, CVE o ID del boletín, criticidad declarada, indicio de explotación, acción recomendada y URL de la fuente.

La idea central es el reparto de tareas: el modelo inventa las consultas y redacta las conclusiones, mientras que todo lo que debe cumplirse pase lo que pase con el comportamiento del modelo está en el código. La herramienta se crea con parámetros fijos: una lista negra de dominios, un límite inferior de fecha y un máximo de cuatro búsquedas por rama. La opción model_filters=False deja al modelo un solo argumento: el texto de la consulta. La herramienta devuelve los resultados dos veces: como texto para el modelo y como artefacto para el grafo, de modo que el código pueda verificarlos.

Antes de devolverse, cada hallazgo pasa cuatro comprobaciones contra lo que devolvieron las búsquedas de esa misma rama:

• la URL aparece realmente en los resultados;
• el título o el texto de la fuente nombra el paquete como palabra completa;
• la CVE o el ID del hallazgo figura en el texto de la fuente;
• la fecha de publicación está dentro de la ventana de observación (si no hay fecha, se considera fuera de la ventana).

Después, el paso keep_new compara los hallazgos que han sobrevivido con el almacén de LangGraph para que lo mismo no llegue dos veces, y report genera una tabla con enlaces.

Qué mostró la ejecución

En una ventana de siete días, las tres ramas hicieron 12 búsquedas y obtuvieron 80 fuentes. Tardaron 36 segundos, frente a los 99 que habrían necesitado si las ramas se hubieran ejecutado una tras otra. La verificación descartó dos hallazgos: en uno, la fuente no nombraba el paquete; en el otro, el número de CVE no aparecía en el texto. Pasaron cuatro, pero el informe mostró dos: los otros dos ya estaban en el almacén tras pruebas anteriores. Una segunda ejecución con los mismos datos produjo un informe vacío, como debe ocurrir en una tarea diaria.

Limitaciones y qué hacer en la práctica

Lo más importante: las comprobaciones detectan URL e ID inventados, fuentes que no mencionan el paquete y páginas desactualizadas. Pero no confirman la criticidad, el hecho de la explotación, las versiones afectadas ni la recomendación. Una página indexada esta semana puede describir un incidente antiguo. En un proceso de seguridad real, contraste los hallazgos con bases de datos de vulnerabilidades de referencia y haga que una persona los revise antes de emprender cualquier acción.

Algunos detalles prácticos más:

• InMemoryStore solo vive dentro de la sesión. Para una ejecución diaria hace falta un almacén persistente, por ejemplo DynamoDBStore, ya que las sesiones en el runtime de AgentCore son efímeras.
• El límite por defecto es de 10 consultas por segundo por región para toda la cuenta, y las ramas paralelas lo comparten.
• La herramienta se llama web_search. Si el agente ya tiene otra búsqueda con ese nombre, renombre una de las dos.
• Los permisos necesarios son mínimos: una sola acción, bedrock-agentcore:InvokeWebSearch, sobre un recurso que pertenece a AWS.

Elegir entre las dos vías es sencillo. Si la aplicación llama a la búsqueda por su cuenta y fija ella misma las reglas, use el API directamente. Si un equipo de plataforma reparte la búsqueda entre muchos agentes y quiere una política de fuentes única, necesita Gateway. También es la opción adecuada si la búsqueda la necesitan clientes MCP como Claude. Para equipos distintos basta con crear un web search target aparte, con su propia lista de bloqueo.