AWS opens Web Search API for agents: one call, no gateway, no keys

A model doesn't know what happened last week. For an agent to answer questions about fresh releases, prices, or laws, it needs search. AWS already had such search, but only through AgentCore Gateway: you create a gateway, add a web search target, and call the tool from an MCP client. For a platform team with shared policies, that's fine. For a developer who just needs search results, it's an unnecessary layer.

Now AWS has released a standalone Web Search API. It is the InvokeWebSearch operation in the data plane of the bedrock-agentcore service. You don't need to create anything in advance: take your IAM credentials, make the call, and get the results.

What it looks like in practice

In Boto3 it is a single method, invoke_web_search. You pass a query string (up to 200 characters), a number of results from 1 to 25, and filters. For example, you can limit the search to the domains aws.amazon.com and kubernetes.io and ask for pages published after January 1, 2026. The response is a ranked list. Each result has a text snippet, while the title, URL, and publication date are present if the index knows them. That is why you should read them with get rather than by key.

Authentication uses SigV4, so there are no API keys. If your code runs in Lambda, ECS, EC2, or EKS, it is enough to add one permission to the role: bedrock-agentcore:InvokeWebSearch on the managed resource web-search.v1. This is the same permission used by the gateway's service role, so one policy covers both paths.

You can also test it without code: in CloudShell, a single command is enough: aws bedrock-agentcore invoke-web-search. For Python, you need Boto3 version 1.43.127 or newer.

Where it is useful

AWS lists several scenarios where a gateway is overkill:

• your own agent loop or frameworks such as LangChain and LlamaIndex;
• non-agent tasks: dashboards, fact-checking, content enrichment, monitoring;
• cases where you want to handle retries, caching, and error handling yourself;
• applications that already have their own API layer.

For LangChain there is a ready-made toolkit in langchain-aws 1.9.3 and newer. It lets you pin rules the model cannot change: excluded domains, a lower date bound, and a search budget. This is useful when you don't want the agent to widen its own search scope. There is also a WebSearchClient wrapper in AgentCore Python SDK 1.26.0.

Security and limitations

The main argument for enterprise teams is that queries are served by an index managed by Amazon and do not go to a third-party search engine. The same index powers Alexa+, Kiro, and Quick. Access is controlled through IAM and SCPs, and calls can go through PrivateLink without leaving for the internet. With the aws:SourceVpce condition, you can allow search only from your VPC.

There are some caveats:

• CloudTrail records calls as data events, but they are disabled by default. You need to manually add a selector for the AWS::BedrockAgentCore::WebSearch resource. The query text and filters themselves do not appear in the logs.
• The default limit is 10 requests per second per region per account. For high-volume pipelines you will need to request an increase.
• The terms of use require you to keep and display source links along with the results. If your product hides sources, that is a problem.
• Interface VPC endpoints are billed at standard PrivateLink rates.
• The index belongs to Amazon, so check coverage and freshness on your own queries before giving up Brave, Tavily, or Bing.

What to do

If you are already on AWS and want to add web grounding to an agent, start with the direct API: it takes five minutes and there is no need to deploy a gateway. If you have many agents and a shared tool policy, the gateway remains the right choice. To compare with other search APIs, run the same set of queries on both, and in production enable CloudTrail data events right away and restrict domains in the toolkit.