Introducing the Web Search API on Amazon Bedrock AgentCore

AI agents and applications that answer questions about recent events, product releases, prices, or regulations need information newer than their model’s training data. Until now, Web Search on Amazon Bedrock AgentCore delivered that information to agents through AgentCore Gateway , a capability of Amazon Bedrock AgentCore. That means creating a gateway and a web search target and calling the tool from an MCP client. The setup fits platform teams that share one search policy across many agents, but it’s more than you need when your own code only requires search results. Today, we’re announcing the Web Search API on Amazon Bedrock AgentCore. With it, your own code can search the web with a single API call. It returns ranked results from a web index that Amazon operates, each with a text extract and, when available, the page title, URL, and publication time. You call it from the AWS SDKs or the AWS Command Line Interface (AWS CLI), signed with the same AWS Identity and Access Management (IAM) credentials you use for your other AWS services. There are no resources to create first. Authenticate, call, and get results. Use it in an application, an agent loop you write yourself, or a data pipeline. Why a standalone API? The AgentCore Gateway is the recommended path for most agentic workloads. It gives agents one secure Model Context Protocol (MCP) endpoint that combines web search with your other tools. It also handles inbound and outbound authentication, semantic tool selection, and optional MCP sessions . But developers told us they also need a lower-level integration point for scenarios where the gateway is not the right fit: Custom orchestration frameworks – Developers building their own agent loops, or using frameworks like LangChain or LlamaIndex, want to call web search directly as a tool within their orchestration logic rather than routing through a gateway. Non-agent use cases – Not every application that needs web grounding is an agent. Search-powered dashboards, fact-checking pipelines, content enrichment workflows, and monitoring systems all benefit from real-time web results without requiring agent infrastructure. Tighter control over the request lifecycle – Some developers want to manage retries, caching, and error handling themselves rather than delegating to the gateway. Simpler integration for existing applications – Applications that already have their own API layer can call the Web Search API directly, adding web grounding without adopting the full AgentCore Gateway stack. The Web Search API complements the gateway. It runs on the same search infrastructure that powers Alexa+, Kiro, Quick, and other Amazon products, with the same quality and compliance posture, exposed as a direct API operation. How it works The Web Search API is the InvokeWebSearch operation on the bedrock-agentcore data plane, the same endpoint that other AgentCore tools such as AgentCore Browser , a capability of Amazon Bedrock AgentCore, use. Requests are signed with AWS Signature Version 4 (SigV4) from your standard AWS credentials, so there’s no API key or secret to manage. Figure 1: How a Web Search API request flows The numbered steps are: Your application calls InvokeWebSearch with the AWS SDKs or the AWS CLI, which sign the request with SigV4 using its AWS credentials. From a virtual private cloud (VPC), the call can go through an interface VPC endpoint. The API checks with AWS Identity and Access Management (IAM) that the caller has bedrock-agentcore:InvokeWebSearch on the AWS managed web search tool. The API applies the filters in the request: the domains to include or exclude and the publication time range. The API searches a web index that Amazon operates. Queries are served inside AWS and aren’t sent to a third-party search engine. The API returns up to maxResults ranked results, each with a text extract and, when available, the page title, URL, and publication time. The calling identity needs one IAM permission on an AWS managed resource. It’s the same action and resource that a gateway’s service role uses for web search, so one policy covers both routes. For details, see Grant permission to call the API . { "Version": "2012-10-17", "Statement": [ { "Sid": "InvokeWebSearch", "Effect": "Allow", "Action": "bedrock-agentcore:InvokeWebSearch", "Resource": "arn:aws:bedrock-agentcore:us-west-2:aws:tool/web-search.v1" } ] } A first search request The following example searches two trusted domains for pages published in 2026, in the US West (Oregon) Region (us-west-2), with the AWS SDK for Python (Boto3) : import boto3 client = boto3.client("bedrock-agentcore", region_name="us-west-2") response = client.invoke_web_search( webSearchId="web-search.v1", searchQuery="multi-region EKS cluster deployment best practices", maxResults=10, filters={ "domainFilter": {"include": ["aws.amazon.com", "kubernetes.io"]}, "publishedDateFilter": {"publishedAfter": "2026-01-01T00:00:00Z"}, }, ) for result in response["results"]: print(result.get("publishedAt"), result.get("title"), result.get("url")) Every result has a text extract. The title, URL, and publication date come back when the index has them, so read them with get . One result from a live call, shortened: { "title": "One Amazon EKS, many edges: How to choose your edge container strategy on AWS", "url": "https://aws.amazon.com/blogs/containers/one-amazon-eks-many-edges-how-to-choose-your-edge-container-strategy-on-aws/", "text": "Separate the standard from the deployment model Choosing the wrong platform isn't really the issue. ...", "publishedAt": "2026-09-25T15:52:00Z" } That’s the full integration. If your code runs on AWS Lambda , Amazon Elastic Container Service (Amazon ECS) , Amazon Elastic Compute Cloud (Amazon EC2) , or Amazon Elastic Kubernetes Service (Amazon EKS) , the execution role provides credentials automatically. Add the permission to that role, and the same code runs unchanged. Key API features Domain filtering – Include or exclude specific domains to scope search results to trusted sources (for example, only aws.amazon.com and kubernetes.io for an assistant focused on AWS). Each list holds up to 100 domain names, and a root domain also matches its subdomains. Date filtering – Restrict results to a publication time range with publishedAfter and publishedBefore , given as RFC 3339 date-times in UTC such as 2026-01-01T00:00:00Z. Both bounds are inclusive. Configurable result count – Request between 1 and 25 results per query. If you don’t set maxResults , the API returns up to 25. The search text, searchQuery , can be up to 200 characters. Results with text extracts – Each result includes a text extract and, when available, the page title, URL, and publication time, ready to feed into your model’s context window. Getting started in under 5 minutes Here are two ways to get a first result: Option 1: AWS CloudShell (no local setup) Open AWS CloudShell in your browser. It uses the credentials of your console session. Your role will have the bedrock-agentcore:InvokeWebSearch permission, from the preceding policy or from the broader AWS managed policy BedrockAgentCoreFullAccess . Run: aws bedrock-agentcore invoke-web-search \ --web-search-id web-search.v1 \ --search-query "latest EKS features" \ --max-results 5 Option 2: Local development Install the AWS CLI, or the AWS SDK for your language. For Python, use Boto3 1.43.127 or later. Create an IAM role with the preceding policy. Get credentials for that role: assume it from your application or an AWS CLI profile, or sign in with it through your identity provider. Run the preceding Python example, or call the API from any AWS SDK. There’s no resource to create and no API key to manage. Authenticate, call, and get results. Using the Web Search API with agent frameworks The Web Search API fits naturally into popular agent frameworks. LangChain agents get it through the AgentCore web search tool in langchain-aws 1.9.3 and later: from langchain.agents import create_ag