AgentCore web search no longer needs a gateway. Governance moves into your code

AWS has made its agent web search callable without the agent plumbing. On 10 November 2026 it announced general availability of InvokeWebSearch, an operation on the Amazon Bedrock AgentCore data plane that runs one search and returns ranked results to any code holding the right IAM permission. Until now, web search in AgentCore was reachable only as an MCP tool behind an AgentCore Gateway. The announcement says there are “no resources to create”. The price is $7 per 1,000 queries, the same rate as the gateway route, with no gateway charges.

For builders, the useful question is what moved when the gateway went away. The search index, the price and the citation terms stay the same. The control surface changes. The gateway connector lets an administrator set domain include and exclude lists that the calling agent cannot see or override. The API has no such layer: each request carries its own domain filter. You do get AWS PrivateLink and CloudTrail logging, but CloudTrail records neither the search text nor the filters. You can audit who searched, when and how often. You cannot audit what they searched for.

Our judgement: the API is the better fit for pipelines and hand-written agent loops, where your own code already decides when to search and what reaches the model. Once you leave the gateway, the policy it enforced for you becomes code you write and maintain. This piece covers what the API does, what it costs at realistic volumes, how it differs field by field from the MCP tool, and what AWS has not yet documented. It is based on AWS’s announcement, developer guide, pricing page and earlier launch posts, read on 12 November 2026, plus one independent publisher’s test of the connector. GenAI Brief has not called the API itself.

One signed call, no gateway

The developer guide describes the mechanism plainly. Your code calls the AgentCore data plane endpoint, for example bedrock-agentcore.us-east-1.amazonaws.com, with a request signed by AWS Signature Version 4 for the service name bedrock-agentcore. The SDKs and CLI do the signing. The tool being invoked is an AWS-managed resource with the identifier web-search.v1, sent in the URI path. Nothing has to be provisioned in your account first.

Two fields are required: webSearchId, which must be web-search.v1, and searchQuery, which takes 1 to 200 characters. maxResults is optional, ranges from 1 to 25 and defaults to 25. The optional filters object holds a domainFilter with include and exclude lists of 1 to 100 domains each, and a publishedDateFilter with publishedAfter and publishedBefore timestamps, both inclusive. Per the request reference, the body can contain only searchQuery, maxResults and filters. Any other top-level field fails with a ValidationException, and the body is capped at 32 KiB.

Domain entries are bare names such as example.net, with no scheme or path, and a root domain also matches its subdomains. Each name can be up to 253 characters. If publishedAfter is later than publishedBefore, the request fails validation instead of quietly returning nothing.

The response is a results array in ranked order. It is not paginated: you get up to maxResults results in one response, possibly fewer, and there is no second page. Each result always has text, an extract from the page. title, url and publishedAt appear only when known. That optionality matters downstream. Any code that builds citations has to handle a result with no URL, and AWS’s acceptable-use terms (covered below) require citations wherever results reach end users.

The getting-started page lists four prerequisites: credentials, a supported Region, a current SDK or CLI (older versions do not include the operation) and one IAM permission. The IAM action is bedrock-agentcore:InvokeWebSearch, and the resource is an ARN whose account field is the literal string aws, because AWS owns the tool:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowInvokeWebSearch",
      "Effect": "Allow",
      "Action": "bedrock-agentcore:InvokeWebSearch",
      "Resource": "arn:aws:bedrock-agentcore:us-east-1:aws:tool/web-search.v1"
    }
  ]
}

AWS’s own Python example, lightly trimmed, shows the full shape of a filtered call:

import boto3

client = boto3.client("bedrock-agentcore", region_name="us-east-1")

response = client.invoke_web_search(
    webSearchId="web-search.v1",
    searchQuery="Amazon Bedrock AgentCore release announcements",
    maxResults=5,
    filters={
        "domainFilter": {"include": ["example.net", "example.org"]},
        "publishedDateFilter": {
            "publishedAfter": "2026-01-01T00:00:00Z",
            "publishedBefore": "2026-01-31T23:59:59Z",
        },
    },
)

for result in response["results"]:
    print(result.get("title"), result.get("url"))
    print(result["text"])

The example uses result.get() for the title and URL and direct indexing only for text. That matches the response contract, and code that copies the pattern will not crash on a result without a URL.

What the API is not

The API does not involve a model, does not synthesise an answer and does not fetch full pages. It returns extracts from an index that, according to the Web Search Tool page, Amazon builds and operates itself rather than reselling a third-party engine. AWS uses the words “ranked” and “semantically relevant passages” for what comes back. The developer guide’s suggested uses are an application, “an agent loop that you write yourself”, or a data pipeline.

So the API’s natural user is a developer who already runs an orchestration loop or a batch job and wants search as one more function call. MCP tool discovery adds nothing for that developer. Our MCP explainer covers why discovery matters when a client does not know its tools in advance. When your code does know its tools in advance, the gateway was an extra hop.

The price is the same, and the gateway fee was small

The announcement and the AgentCore pricing page both list Web Search at $7 per 1,000 queries, or $0.007 per query, billed per query submitted, with no minimum or upfront commitment. The pricing page lists no Web Search free tier; the June AWS News Blog launch post notes only that new AWS customers receive up to $200 in general Free Tier credits. The API costs the same per query as the gateway connector, and the announcement adds that it has “no gateway charges”.

Those gateway charges are small. The pricing page lists AgentCore Gateway API invocations, such as ListTools, InvokeTool and Ping, at $0.005 per 1,000. It lists the gateway’s own Search API, used for semantic tool search, at $0.025 per 1,000, and tool indexing at $0.02 per 100 tools per month. A web search through the gateway therefore costs roughly $7.005 per 1,000 calls before any tool listing or indexing.

The worked example below makes this concrete. The inputs are hypothetical except where marked as AWS’s.

The AWS row reproduces the pricing page’s example as published, for a monthly total of $1,403. Its text says each query triggers two additional tool calls on average, 400,000 in all, and it bills 600,000 InvokeTool calls, which we read as the 200,000 search calls plus those 400,000. The second row is our variant with no extra tool calls. Either way, the gateway portion of the bill is a rounding error next to the search charge. Moving to the API will not cut a web-search bill in any meaningful way.

The last row is the more useful number for budgeting. The quotas page sets a default of 10 InvokeWebSearch requests per second per account per Region, adjustable through AWS Support. An account that runs flat out at that limit for a 30-day month in one Region would submit 25.92 million queries, or $181,440 at list price. Few teams will get close. The figure does bound what a runaway loop can spend in a single Region before throttling starts. A loop running at the cap spends about $252 an hour.

The rate cap is the same on both paths. The Gateway quota table lists “Rate of Web Search Tool requests” at 10 transactions per second. The table does not say whether the two paths draw on a shared allowance, so a team running both should not assume it has 20.

A burst is the realistic problem

The quota matters more for burstiness than for monthly volume. Take a hypothetical research workflow of 2,000 tasks a day, each issuing five searches. That is 10,000 queries, or $70 a day. Spread over eight working hours, the average is about 0.35 requests per second, far below the cap. Now suppose a dispatcher starts 50 tasks at once and each fires its five searches in parallel. That is 250 requests in about a second, against a cap of 10. Most of them will come back as ThrottlingException (HTTP 429).

The troubleshooting page gives the standard remedies: retry with exponential backoff on 429 and 500, and on 503 honour retryAfterSeconds when it is present. Behind a gateway, every search at least passed through one shared component. With direct calls, every service that calls the API needs its own backoff, or a shared token bucket in front of it.

How the API differs from the MCP tool

AWS documents the differences between the two routes on the developer guide’s “Choose between the API and the Gateway connector” section. Several are small enough to cause bugs when code is ported from one route to the other. The table combines that section with the request reference and the connector’s input schema.

The date-bound trap

The most likely porting bug is in the date filter. In the MCP tool, a to value of 2026-10-31 includes all of 31 October. The API’s SDKs and CLI send a date with no time as midnight UTC at the start of that day, so publishedBefore: 2026-10-31 excludes almost all of 31 October. AWS’s guidance is to use the last second of the day, 2026-10-31T23:59:59Z. An agent that searches for “everything published in October” and was written against the MCP tool will silently lose the last day after a mechanical rename of the fields.

The response field name changes too, from publishedDate to publishedAt, so a parser that reads the old key will see every result as undated. A change in the default result count from 10 to 25 will increase the text fed into a model’s context on any call that omits maxResults. None of these differences is a defect. Each is a reason to treat a move between paths as a migration with tests, not a find-and-replace.

Two routes, one permission

One detail in the documentation is easy to overlook. The gateway target configuration guide says the gateway’s service role needs bedrock-agentcore:InvokeWebSearch, “checked per-request against the service-owned ARN” arn:aws:bedrock-agentcore:<region>:aws:tool/web-search.v1. That is the same action and the same resource the new API uses. The documentation describes no separate action for “search via gateway” versus “search directly”.

In practice, as we read it, an organisation cannot allow the gateway route and forbid the direct route by denying the action. A blanket deny on bedrock-agentcore:InvokeWebSearch would also block the gateway’s role. The separation has to be made by principal: grant the action to gateway service roles and to the specific workloads approved for direct calls, and to nobody else. Teams that already gave broad bedrock-agentcore:* permissions to developer roles for AgentCore experiments should check whether those roles can now search the web directly, without any of the gateway’s domain lists in the path.

Governance: PrivateLink and CloudTrail, with gaps

The governance story in the announcement has two parts: calls from a VPC through AWS PrivateLink, and logging as CloudTrail data events. Both are real controls. Each has edges a security reviewer should know about.

PrivateLink covers the network path

The PrivateLink page says to create an interface VPC endpoint for the AgentCore data plane service, com.amazonaws.region.bedrock-agentcore. With private DNS enabled, the SDKs and CLI reach the API through the endpoint with no code change. The AgentCore PrivateLink overview confirms that this is the same endpoint that serves Runtime, Memory, Identity and the built-in tools, and not the separate gateway endpoint, com.amazonaws.region.bedrock-agentcore.gateway. It lists Web Search as supported on the data plane, with the control plane marked not applicable, since there is nothing to manage.

An endpoint policy attached to the interface endpoint applies to InvokeWebSearch requests in addition to IAM policies. That gives network owners a second gate. A VPC endpoint policy can allow the action only for named roles, so a principal that holds the IAM permission but is not named in the endpoint policy still cannot search through that endpoint. The overview also notes that VPC endpoint policies can restrict callers only by IAM principal, not by OAuth user. That limitation does not affect this API, which accepts IAM callers only.

PrivateLink governs how your request reaches AWS. It says nothing about where the query goes afterwards. On that, AWS’s claim is that the query stays inside AWS. The Web Search Tool page says queries are “served entirely within AWS infrastructure” and “are not sent to a third-party search engine or routed outside AWS”. The product page, which covers both the AgentCore connector and the separate Amazon Bedrock Web Search tool, adds in a general FAQ that neither inputs nor generated search queries are written to durable storage and that results are not stored against the account. These are vendor statements. They are specific enough to put in a contract review, and nothing in the public material lets an outsider verify them.

CloudTrail records who and when, not what

The CloudTrail page is precise, and its precision is the story. Calls are recorded as data events with event name InvokeWebSearch, event source bedrock-agentcore.amazonaws.com and resource type AWS::BedrockAgentCore::WebSearch. Data events are off by default and do not appear in Event history. To capture them you need a trail or event data store with an advanced event selector for that resource type, and AWS warns that data events carry additional charges.

What gets logged:

• Every authenticated request, including requests that were throttled, denied by IAM or rejected for an invalid field. An AccessDeniedException appears with errorCode AccessDenied.
• Not requests rejected before authentication: unsigned requests, failed signatures or oversized bodies.
• Not requests denied only by a VPC endpoint policy. If your endpoint policy is doing its job, the blocked attempts it stops are invisible in CloudTrail.
• In requestParameters, only webSearchId and, if set, maxResults. CloudTrail does not record the search text or the filters.

The last point decides what an investigation can establish. After an incident you could show that a given role made 4,000 searches between 02:00 and 03:00 from a given VPC endpoint. You could not show what it searched for, which domains it filtered to, or whether it ignored a domain policy. The Amazon Bedrock Web Search feature, a separate product covered below, documents a fetchedSources field in CloudTrail for auditing page fetches. The AgentCore API page describes no equivalent record of returned URLs, and the product page’s general FAQ says that “by design, CloudTrail does not record query text or the URLs search returned.”

We read this as a deliberate trade. A log of every query an agent sends is a sensitive dataset: agent queries routinely embed customer names, ticket contents or internal project terms. AWS has chosen not to create that dataset in your CloudTrail. The cost of that choice falls on teams with a duty to reconstruct what their agents did. They have to log queries themselves, at the application layer, and then govern that log: retention, access, redaction. Our LLM observability guide covers what to capture in agent traces. Web search queries belong in the same tracing, under the same access controls as prompts.

The control that did not come across

The bigger governance difference is not in either feature the announcement highlights. It is the one the API lacks. On the gateway route, AWS documents two layers of domain filtering. An administrator sets target-level exclude lists, and from connector version 1.2.0 include lists, through parameterValues.domainFilter when creating the target. Those lists are “hidden from the calling agent and applied to every request that flows through the target”. From connector version 1.2.0, the agent can also pass request-level filters. The August filtering post sets out the composition rules: the effective allowlist is the intersection of the administrator and request lists, the effective denylist is their union, and “runtime filters can narrow but never expand the scope set by an administrator.”

The API documentation describes no equivalent. “With the API, each request carries its own domain filter,” the developer guide says. The connector, by contrast, “can also apply target-level domain lists to every request, without the calling agent seeing them.” We found no IAM condition key in the AWS pages we read that would let a policy constrain the filter’s contents. AWS’s machine-readable service reference for bedrock-agentcore, checked on 12 November 2026, lists InvokeWebSearch against the web-search resource with no action-specific condition keys, and no key in the service relates to search domains or filters. Global keys, such as those for the source VPC endpoint, still apply. As documented, a principal with the permission can search any domain the index covers.

For an agent that takes instructions from untrusted text, this matters. An agent steered by a prompt injection could drop a domain filter or swap it for one that suits the attacker. On the gateway route, the administrator’s lists still apply. On the direct route, the filter is whatever the code sends. Our prompt-injection guide explains why authority over tool arguments should not sit with the model. The practical fix is simple to state: never let the model construct the filters object. Build it in code from configuration, and treat any model-proposed domains as a request to narrow within that set, never to widen it.

Four AWS routes to web grounding

The API is the fourth way AWS now offers to put web results in front of a model. The routes overlap, use different IAM prefixes and suit different jobs. This taxonomy is ours, assembled from each feature’s documentation.

The Web Answer page says it “runs an agentic search for each question”, reads relevant pages and returns a finished, cited answer, with queries of up to 30,000 characters. The Bedrock Web Search guide describes a tool added to a Responses API request on the bedrock-mantle endpoint. Its Fetch operation can reach the live web on a cache miss only when the caller holds bedrock-websearch:ExternalWebAccess and leaves external_web_access enabled. That guide carries its own warning: enabling external access “introduces data exfiltration risk”, because an agent could encode data into a URL and fetch it.

That warning helps place the new API. InvokeWebSearch has no fetch operation and no external-access switch. It queries the index and returns extracts, so it does not open the URL-encoding exfiltration path that the Bedrock guide describes for live fetch. Query text still travels to the search service. An injected agent could put sensitive data into a query string, and CloudTrail would not show it. That risk applies to every search tool, but it is narrower than a fetch tool that can hit arbitrary URLs.

Choosing between the routes is mostly about who should hold the decision. If your code should decide, use the API. If an agent built on an MCP framework should decide, and a platform team wants one place to set policy, use the connector. If you want an answer rather than evidence, use Web Answer. If you are already calling a supported OpenAI model through the Responses API on Bedrock and want the model to run the whole loop, use the Bedrock tool. Teams comparing broader agent runtimes can find AgentCore’s place among them in our comparison of managed agent orchestration platforms.

Five months from MCP-only to a plain API

AWS’s pages let us reconstruct how the service reached this point. Dates are publication or release dates as each source states them. Where two sources disagree, both are shown.

Two details stand out. First, the versions table dates version 1.2.0, the release that added request-level filters, to 20 July, a month before AWS announced the filters on 19 August. That may reflect a staged rollout or a documentation convention. The public sources do not say. Second, US East (Ohio), US West (Oregon) and Asia Pacific (Sydney) appear in the November Region list without an announcement among the pages we read. We cannot say when each Region became available for the connector.

The direction of travel is clear. AWS began by packaging web search for MCP agents, then added the controls a platform team asks for (filters, administrator allowlists, more Regions), then client compatibility (MCP annotations), then a higher-level answer tool, and now a lower-level primitive. The same index is now available at three levels of abstraction, and AWS is pricing the bottom two identically.

What the evidence does not yet show

Most of what is known about this service comes from AWS. Several questions that matter for production use are not answered in the public material.

Freshness. AWS’s June technical post says the index reflects new content “within minutes”, and the Web Search Tool page repeats the claim. The one independent measurement we found points the other way, though the sample is small. In August, a Classmethod engineer tested the connector in Tokyo on version 1.1.0, searching DevelopersIO for its own articles with maxResults=5. Of 99 high-traffic articles drawn from Google Search Console, 84 (85%) appeared. For 39 articles published in the previous eight or nine days, hit rates were 0 of 1 within 24 hours, 1 of 4 at 24 to 48 hours, 20% to 33% at two to four days old, and between 67% and 83% for articles four to nine days old. The author says the data cannot separate an article’s age from its popularity, and several age buckets hold only one to six articles. It is one publisher, one language mix and one connector version, and it measured whether a specific page appeared, not whether the index had crawled it. It still contradicts an expectation of minute-level freshness for an ordinary technical blog. Anyone building alerting or news monitoring on this API should run the same kind of test on their own target sources first.

Index scale. The Web Search Tool page and AWS’s June technical post say “tens of billions of documents”. The product page describes an index spanning “billions of documents”. Both are AWS’s own descriptions, neither comes with a method, and the difference may only be loose wording. No public figure lets a buyer compare coverage with other search providers.

Latency and quality. AWS publishes no latency figures or relevance benchmarks for the API. The product page carries a customer statement attributed to Prox: more than 5,800 research sessions and nearly 75,000 successful search calls in July, “with 99.8% completing in under one second.” That predates the API, so it concerns the connector route, and it does not say whether the 99.8% refers to sessions or calls, or what “completing” covers. GenAI Brief has not measured latency.

Filter edge cases on the API. For the connector, AWS’s August post says results without a recognisable domain are excluded when a domain filter is active, and results without a recognised publication date are excluded when a date filter is active. AWS frames this as favouring precision over recall. The API reference does not repeat the rule. Since url and publishedAt are optional fields in API results, the answer matters: does a date-filtered API call ever return undated results? We do not know. A proposed test: run identical filtered queries through both routes and compare which results lack publishedAt.

Central domain policy. As discussed, we found no documented mechanism for restricting the API’s domains centrally. If AWS adds an IAM condition key on the filter, or account-level domain lists for the API, the governance comparison above changes materially.

Acceptable use at pipeline scale. The API inherits the connector’s terms. You must “retain and display the source citations and links” with each result in any output shown to end users, and you may not “extract, store, or reproduce content from Search Results in bulk” or “build or populate a competing index or database.” AWS’s own guide suggests using the API in a data pipeline. The public terms do not say where a pipeline that stores results for later retrieval crosses into “bulk”. Teams planning to cache results, build a retrieval corpus from search output, or feed results into fine-tuning data should get that answered in writing.

Ecosystem support. Third-party tooling is still built on the gateway path. LiteLLM’s AgentCore search provider, as documented when we read it, connects to a gateway’s MCP endpoint, expects a tool name ending in ___WebSearch, and ignores its own unified search_domain_filter parameter for this provider. Frameworks that want the API’s simpler auth will need new adapters. Until then, “AgentCore web search” in a framework’s documentation probably means the gateway route.

What would change our conclusion? A documented central domain control for the API would remove the main governance cost of leaving the gateway. An independent freshness test showing minute-level indexing across many sites would make the API credible for monitoring work. A clear AWS statement on caching and storage limits would settle whether it suits retrieval pipelines.

A checklist before switching

For teams already using the connector, or deciding which route to start with, the documentation supports a short list of decisions.

1. Decide who owns the search decision. If a model chooses when to search through an MCP client, the connector remains the natural fit. If your code decides, the API removes a hop and a resource to manage.
2. Write down your domain policy before you leave the gateway. If a target-level include or exclude list exists today, reproduce it in code, in one shared wrapper, and make the model unable to widen it. Do not let each service assemble its own filters object.
3. Scope the IAM grant by principal. Grant bedrock-agentcore:InvokeWebSearch only to the roles meant to call it, and audit existing wildcard AgentCore permissions, which may already cover the action.
4. Use the VPC endpoint policy as a second gate. For workloads in a VPC, allow the action only for named roles on the com.amazonaws.region.bedrock-agentcore endpoint. Remember that denials by that policy alone will not appear in CloudTrail.
5. Turn on data events if you need the call record, and log queries yourself if you need the content. CloudTrail gives you identity, time, result count settings and errors. Query text and filters have to come from your application traces, which then need the access controls you apply to prompts.
6. Fix the date bounds. Replace MCP to dates with explicit end-of-day timestamps in publishedBefore, rename publishedDate to publishedAt in parsers, and set maxResults deliberately instead of inheriting a default that rose from 10 to 25.
7. Pace calls against 10 requests per second. Put a shared limiter in front of parallel agents, back off on 429 and 500, honour retryAfterSeconds on 503, and request a quota increase before load testing.
8. Keep citations attached. Carry url and title through to any user-facing output, handle results that lack a URL, and do not store results in bulk until the terms question is settled.
9. Check the Region. If you run in AWS GovCloud (US-West), the API is not available there and the connector is.
10. Test freshness on your own sources. As a proposed exercise, search for pages you know were published in the past day, week and month, and record which appear. The only independent data point so far suggests days, not minutes, for at least one publisher’s articles.

The API makes AgentCore’s search usable from a cron job, a Lambda function or a hand-written agent loop with nothing in between. That is a real simplification. The gateway also carried policy, and the API leaves that policy to you. Teams that write it down, put it in one wrapper and keep the model away from the filter get a cheaper-to-operate search primitive at the same price. Teams that treat the switch as a field rename will get searches nobody constrained and logs that cannot say what was searched.