AWS has added a standalone Web Search API to Amazon Bedrock AgentCore. The short version: your code makes one SigV4-signed InvokeWebSearch call and gets back ranked results from a web index that Amazon operates. There is no gateway, no target, and no API key. The details come from the AWS Machine Learning Blog post dated November 11, 2026.
This is a different product from the Web Answer tool on AgentCore, which returns a cited answer through the gateway. The new API returns raw ranked results, and you decide what to do with them. It also arrives the same week AWS published a guide for running OpenAI Codex on Bedrock, whose reference repository lists an AgentCore Gateway path with AWS-private web search (see also the AWS post on Codex and Bedrock).
TL;DR: what readers ask first #
| Question | Answer |
|---|---|
| What is the operation? | InvokeWebSearch on thebedrock-agentcore data plane |
| What does it return? | Ranked results with text , plustitle ,url ,publishedAt when the index has them |
| Who runs the index? | Amazon. AWS says queries are not sent to a third-party search engine. |
| How do I authenticate? | SigV4 with standard AWS credentials; no API key |
| Gateway needed? | No |
| Default rate | 10 requests per second per account per Region |
| Max results | 25 (default 25) |
| Query length | 200 characters |
| Price | Not in the visible part of the AWS post; check the AWS pricing page |
What is in the API? #
The managed tool is named web-search.v1. The request fields, as AWS lists them:
webSearchId: alwaysweb-search.v1.searchQuery: up to 200 characters.maxResults: 1 to 25, default 25.filters.domainFilter:includeandexcludelists, up to 100 domains each. A root domain also matches its subdomains.filters.publishedDateFilter:publishedAfterandpublishedBeforeas UTC RFC 3339 timestamps, both inclusive.
The 200-character query cap matters for agents. A model that writes long, chatty queries will hit the limit, so trim or rewrite queries before the call. The date filter is useful for news-aware agents: set publishedAfter to last week and stale pages drop out.
The call in Python and the CLI #
AWS shows boto3 version 1.43.127 or later:
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"]}},
)
for result in response["results"]:
print(result.get("publishedAt"), result.get("title"), result.get("url"))
And the CLI form:
aws bedrock-agentcore invoke-web-search \
--web-search-id web-search.v1 \
--search-query "latest EKS features" \
--max-results 5
Framework support is listed too: langchain-aws 1.9.3 or later has create_web_search_toolkit, and the AgentCore Python SDK 1.26.0 or later has a WebSearchClient. If you build agents on a framework, check those versions first, because older installs will not have the helper.
IAM: one resource ARN #
The caller needs the permission bedrock-agentcore:InvokeWebSearch on the managed resource arn:aws:bedrock-agentcore:us-west-2:aws:tool/web-search.v1. Note the Region in that ARN is us-west-2 in AWS's example, and the account field is aws, because AWS owns the resource. Because it is a normal IAM action, you can allow it for one role and deny it everywhere else with a service control policy. That is a clean way to keep a research agent searchable while a billing agent is not.
How is this different from the gateway and Web Answer? #
| Web Search API | AgentCore Gateway | Web Answer | |
|---|---|---|---|
| Setup | None beyond IAM | Gateway and targets | Gateway tool |
| Output | Ranked results | MCP tools, including search | A cited answer |
| Best for | Custom orchestration, non-agent apps, retries and caching under your control | Most agent workloads | Fast grounded answers |
AWS recommends the gateway for most agentic work. It gives a single MCP endpoint, authentication, semantic tool selection, and optional MCP sessions. The standalone API is for teams that want direct control: your own retry logic, your own cache, or a plain web app that is not an agent at all.
If you are choosing a search backend for agents more broadly, our posts on the Cloudflare Web Search API for agents and Exa 3.0 pricing claims versus verified numbers cover other options. The main trade here is data path: AWS says queries stay inside AWS.
Enterprise controls and their gaps #
AWS lists four control points:
- IAM and SCPs can allow or deny the action.
- CloudTrail logs calls only if you add an event selector for
AWS::BedrockAgentCore::WebSearch. The logs record the tool andmaxResults, not the search text or filters. - AWS PrivateLink interface endpoints keep traffic on your private network.
- Terms of use require you to retain and display the source citations and links in results.
The CloudTrail gap is the one to plan for. If a compliance team asks "what did the agent search for", CloudTrail alone will not answer. Log the query in your own application, and be careful not to log secrets an agent pasted into a query. A search query is also an outbound channel: an agent that has read private data can leak it in a query string. Treat query content as data leaving the system, even when the index is inside AWS.
The citation term is a product constraint, not a footnote. If your product shows a summary built from search results, you must keep the links visible. That affects UI design for answer boxes and chat agents.
What developers should test #
AWS gives no accuracy or freshness numbers in the visible text, so run your own checks before you switch:
- Coverage: run 50 queries from your real workload against your current search tool and this one. Count how many return a usable top-3 page.
- Freshness: use the date filter and check that new pages appear within your tolerance.
- Rate limit: 10 requests per second per Region is fine for one agent and tight for a fleet. Request an increase early, or add a queue.
- Latency: measure p50 and p95 from your Region. The post's example is us-west-2.
- Cost: confirm the price on the AWS pricing page. The visible post does not state it.
For cost tracking across Bedrock services, see Amazon Bedrock tokenomics and FinOps. For the wider platform, the AgentCore October builder roundup and the pluggable agentic framework on AgentCore show where search fits among the other layers.
A worked pattern: a release-notes research agent #
Consider an internal agent that answers "what changed in this cloud service this month". The standalone API fits well, because the job is narrow and you want control over the call.
- The agent receives a question and rewrites it into a query of fewer than 200 characters, for example the service name plus "new features".
- Your code calls
invoke_web_searchwithdomainFilter.includeset to the vendor's documentation and blog domains, andpublishedAfterset to the first day of the month. - You set
maxResultsto 8 rather than the default 25. Fewer results means less text in the model context, which lowers token cost and reduces the chance that one bad page steers the answer. - Your code caches the result for a few hours, keyed on the query and filters. AWS leaves caching to you on this API, so a cache directly cuts your request rate against the 10 per second default.
- The model writes the summary from the results and your UI shows each source link, which the AWS terms require.
The same pattern works in a plain web app with no agent loop, such as a "related news" panel in an internal tool. That is the case AWS names when it lists non-agent applications as a fit for the standalone API.
Two failure modes to design for. First, an empty result list: decide in advance whether the agent says "nothing found" or widens the filters. Second, throttling at the rate limit: use exponential backoff with jitter, and keep a per-agent budget so one runaway loop does not use the whole account quota. A loop that searches on every step can reach 10 requests per second faster than most teams expect, particularly when several agents share an account in one Region.
Context: why AWS is shipping its own search index #
Agents that browse need a search backend, and until now AWS customers either wired a third-party search provider into AgentCore Gateway or used the Web Answer tool. Offering an index that AWS operates changes two things for buyers: the data path stays inside AWS, and procurement and IAM already cover it. That is the same logic that drives AWS to list OpenAI products through its own channels, which we covered in ChatGPT Enterprise on AWS Marketplace. What AWS has not published, at least in the part of the post we could read, is index size, freshness guarantees, or ranking quality. Those are the numbers that decide whether this replaces a dedicated search vendor.
Security notes for agent builders #
Web results are untrusted input. A page can contain instructions aimed at your model. The API returns page text, and an agent that follows that text can be steered. Keep these habits:
- Pass results to the model as quoted data, not as instructions.
- Restrict the
domainFilterinclude list for sensitive agents, so they read only known sources. - Give the search role no other permissions, so a hijacked agent cannot do more than search.
- Log queries yourself, since CloudTrail will not.
Our Claude Code remote sessions security sample applies similar least-privilege thinking to another AgentCore agent.
Bottom line #
For teams already on AWS, InvokeWebSearch removes the last bit of setup from agent web search: IAM permission, one call, done. The open questions are price, accuracy, and query-level audit, none of which the visible AWS text answers. Start with the gateway if you want MCP and guardrails; use the standalone API when you want control and the shortest path.
Related reading #
Details are accurate as of November 12, 2026. API versions, limits, and pricing change; check the AWS documentation before you build.