--- title: "Web Search as a Managed Connector: Wiring Amazon Bedrock AgentCore WebSearch Into Any Agent" description: "Amazon Bedrock AgentCore WebSearch is a managed MCP connector, not a search-API wrapper: an Amazon-operated index with zero data egress, IAM-authorized so there are no secrets to rotate, and $7 per 1,000 queries confirmed on the bill." canonical_url: "https://artificialcuriositylabs.ai/posts/agentcore-websearch-managed-connector/" md_url: "https://artificialcuriositylabs.ai/posts/agentcore-websearch-managed-connector.md" published_at: "2026-07-10T00:00:00.000Z" tags: - "agents" - "mcp" - "infrastructure" - "patterns" --- Most "add web search to your agent" integrations are a wrapper around someone else's search API: an API key in an env var, a rate limiter, a result parser, and a bill from a third party. Amazon Bedrock AgentCore WebSearch removes all four. It ships as a managed MCP connector you attach to a Gateway — the search index, auth, and result shaping happen inside AWS, and your agent discovers the tool with a standard `tools/list` call. I wired it into my local agents and have run 331 real searches through it. This post covers what makes it worth choosing over a search-API wrapper, how the wiring actually goes together (including the auth), and what the numbers look like after about 10 days of real use. ## What the managed connector actually is WebSearch on AgentCore [went GA on June 16, 2026](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-web-search/), currently in `us-east-1` only. It is a [built-in connector target](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-search-tool.html) on an AgentCore Gateway, spoken over MCP. You attach it with `connectorId: "web-search"` and the Gateway handles schema management, endpoint resolution, and service authentication. Two things make it more than a search proxy. First, it is [backed by a web index Amazon operates directly](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/), spanning tens of billions of documents, rather than reselling a third-party engine. Second, it returns semantic snippets tuned for a model's context window — ranked excerpts with source URLs, titles, and publication dates — not raw HTML you then have to strip. The design goal is intelligence per token, and it combines the web index with knowledge-graph facts so entities resolve to verified data rather than inferred page text. The practical consequence: queries never leave your AWS environment. There is no outbound call to an external search vendor, so there is no data egress and no third-party credential to rotate. ## Why choose it over a search-API wrapper The reason an agent needs web search at all is grounding. A model's knowledge is frozen at training time, so anything current — a release from last week, a price that changed yesterday, a filing from this morning — is either unknown or hallucinated. WebSearch closes that gap by [grounding responses in current, cited web knowledge](https://aws.amazon.com/blogs/aws/announcing-web-search-on-amazon-bedrock-agentcore-ground-your-ai-agents-in-current-accurate-web-knowledge/), which is the difference between an agent that guesses and one that answers. The rest of the case is what you *don't* build. Rolling your own web search for an agent is [several projects stacked together](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-search-tool.html): procure a third-party search API, manage keys and quotas and rate limits, parse inconsistent result formats, write snippet-extraction logic so the model gets passages instead of raw HTML, reason about where queries travel and how they're retained, and keep coverage fresh over time. The managed connector collapses all of it into one `connectorId`. Concretely, the benefits that matter: - **Grounding over guessing** — real-time facts and cited sources instead of stale training data, which directly cuts hallucination on timely questions. - **Zero infrastructure** — no search API to provision, no quotas to tune, no result parser to maintain. The Gateway exposes it as a standard MCP tool. - **Framework-agnostic** — any MCP-compatible client works: Strands, LangChain, LangGraph, CrewAI, or a hand-rolled shim. Nothing is tied to one agent framework. - **A purpose-built index, not a reseller** — backed by an index [Amazon operates directly](https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-agentcore/) (tens of billions of documents, refreshed within minutes), the same search infrastructure behind Alexa+, Amazon Q Business, and Kiro. Broad coverage answers long-tail questions a popularity-ranked engine misses, and a knowledge graph resolves entities to verified facts. - **Zero data egress** — queries stay inside AWS, which removes an entire category of security and compliance review for teams that care where data travels. - **Usage-based pricing** — [$7 per 1,000 queries](https://aws.amazon.com/blogs/aws/announcing-web-search-on-amazon-bedrock-agentcore-ground-your-ai-agents-in-current-accurate-web-knowledge/) with no upfront commitment, plus Free Tier credits for new accounts. You pay per search, not for standing infrastructure. The through-line: improvements to freshness, coverage, and relevance flow to your agent automatically through the same connector, with no version upgrade or migration on your side. ## The shape of the wiring The connector lives in AWS. The caller can be a local agent on your laptop speaking MCP over stdio, or — more commonly — an autonomous agent deployed on AgentCore Runtime or your own compute, calling the Gateway directly. Either way the caller discovers the tool with `tools/list` and invokes it with `tools/call`; the only difference is how it signs. A deployed agent signs with its execution role; a local agent uses a small shim. The path is the same shape: ``` Caller · deployed agent on AgentCore Runtime / Lambda / ECS → execution role signs (SigV4) · local agent on your laptop (Codex / Cursor / Zed / Claude Code / Kiro / GitHub Copilot) → MCP shim signs (SigV4) → POST https://.gateway.bedrock-agentcore..amazonaws.com/mcp → target (connectorId: web-search) → Amazon web index + knowledge graph → ranked snippets + source URLs + titles + dates ``` You create the Gateway once with `authorizerType: AWS_IAM` and `protocolType: MCP`, then add a connector target pointing at `web-search`. The Gateway assumes an execution role to reach the backend; that role needs no special search permissions because AWS operates the search stack. If you want to bound what the tool can reach, the connector supports a [domain denylist](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-search-tool.html) — a list of domains the Web Search Tool is not allowed to query, configured on the target at creation time through the SDK or CLI (`create-gateway-target`, the same call that sets `connectorId: web-search`). One thing worth calling out, because it trips people up: *configuring* the connector needs current AWS tooling (or the console), but *calling* it does not. The invocation path is just a SigV4-signed JSON-RPC POST to the gateway URL, so an agent or shim runs on whatever SDK version it already has. ## Wiring in the auth The Gateway is IAM-authorized, so the caller has to present a SigV4-signed request from an AWS principal. That is the entire auth model: does the caller hold valid AWS credentials for the account that owns the gateway? There is no token endpoint, no client secret, no refresh loop. The signing is identical whether the caller is a deployed agent or a local one — it resolves credentials from the standard AWS chain (environment variables, then a named profile, then an instance or container role) and signs each MCP request before sending it. A deployed agent on Runtime or Lambda gets its execution role from that chain; my local shim gets a profile from the same chain. Same code, different credential source: ```python import botocore.session, botocore.auth, botocore.awsrequest def sign(url, body, region): creds = botocore.session.Session().get_credentials().get_frozen_credentials() req = botocore.awsrequest.AWSRequest(method="POST", url=url, data=body, headers={ "Content-Type": "application/json", "Accept": "application/json, text/event-stream", "MCP-Protocol-Version": "2025-06-18", }) botocore.auth.SigV4Auth(creds, "bedrock-agentcore", region).add_auth(req) return dict(req.headers.items()) ``` Notice what `get_credentials()` does not take: no API key, no secret, no token. A deployed agent presents its execution role automatically; on my laptop the tool config sets a profile name and a region and botocore does the rest. In neither case is there a search credential in the config to leak, rotate, or expire — the AWS identity the caller already has *is* the credential. Because resolution is per-process, the same signed path works unchanged across every local agent harness that speaks stdio MCP. Point Codex, Cursor, Zed, Claude Code, Kiro, or GitHub Copilot at the same shim and they all inherit web search, each using whatever profile its environment provides — while a fleet of deployed agents inherits it through their execution roles with no shim at all. ## What 331 real searches look like Numbers from my own gateway over about 10 active days since I started using it — not a benchmark, just the real traffic from running agents. | Metric | Value | |---|---| | WebSearch invocations | 331 across 10 active days | | Busiest day | 91 calls | | End-to-end latency p50 | 635 ms | | End-to-end latency p90 | 784 ms | | End-to-end latency p99 | 1,013 ms | | Connector backend time (p50) | 547 ms | | SystemErrors | 0 | | Throttles | 0 | | UserErrors | 1 | Two things stand out. Sub-second p50 end to end, with zero system errors and zero throttles across every call — the managed path held up under bursty agent traffic without any tuning on my side. And the latency is dominated by the search itself: ~547 ms of the ~635 ms p50 is connector backend time, meaning the Gateway and signing overhead adds well under 100 ms. You are paying for the index doing real work, not for glue. ### Where these numbers come from Every figure above is emitted automatically — there is nothing to instrument. The Gateway publishes to the CloudWatch namespace `AWS/Bedrock-AgentCore`, dimensioned per tool, so you can slice latency and error rate for the WebSearch target specifically. `TargetExecutionTime` is the connector's own backend time, which is what let me separate search time from gateway overhead above. ### What it costs, from the actual bill The pricing claim is easy to verify because it shows up as its own line. In Cost Explorer and the Cost and Usage Report, WebSearch appears under the service `Amazon Bedrock AgentCore` with the usage type `USE1-WebSearchTool:Consumption-based:Queries`. On my bill, 144 queries in one month cost $1.008 and 152 the next cost $1.064 — exactly $0.007 per query, or the advertised $7 per 1,000, with no rounding surprises. The Gateway itself bills separately and trivially, as `USE1-Gateway:Consumption-based:API-Invocations` (fractions of a cent for the same traffic) plus an even smaller `Gateway:Consumption-based:Tool-Indexing` line — a fraction of a tenth of a cent, and it scales with the number of tools registered on the gateway rather than with search volume, which fits a per-schema indexing cost for the Gateway's semantic tool discovery. So the cost model is legible: one metered line for searches, one negligible line for gateway invocations, and nothing for standing infrastructure. ## What's missing Three honest constraints. It is `us-east-1` only right now, so if your agents or data residency live elsewhere you are making a cross-region hop or waiting for the [regional rollout](https://aws.amazon.com/blogs/aws/announcing-web-search-on-amazon-bedrock-agentcore-ground-your-ai-agents-in-current-accurate-web-knowledge/). The query is capped at [200 characters](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-search-tool.html), which is fine for natural-language questions but forces you to decompose anything long. And the connector is semantic web search for grounding, not a data feed: the [acceptable-use terms](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-search-tool.html) require you to retain and display source citations on any result you surface, and prohibit bulk-extracting results or using them to build a competing index. The open thread I have not closed is per-user authorization. The external path itself is not in doubt: alongside my own IAM-authorized agents, I run a separate JWT-authorized gateway that fronts several tools, where callers present an OAuth token and carry no AWS credentials at all. That proves an external caller can reach a connector without a shared secret. But my gateway authorizes at the coarsest grain it can — it validates that the token comes from my issuer and carries my audience, and nothing more. Every caller behind that token is identical to the gateway. The capability to go finer is already there; I just have not wired it. A JWT-authorized Gateway [evaluates Cedar policies on every call](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-authorization-flow.html), constructing an authorization request whose principal is the token's `sub` claim, whose action is the tool name, and whose resource is the gateway — so you can write a rule that says *this user may call this tool* and have it enforced before the connector ever runs, with conditions that read claims like `scope` or `role` or even the tool's own arguments. Per-user scoping is a policy I have not authored, not a feature the platform is missing. And because a Gateway's authorizer is IAM *or* JWT, fixed at creation, mixing my own agents and external users still means two gateways in front of the same connector — which is exactly why I run them separately today. Authenticated external access works; per-user authorization behind it is the Cedar layer I would wire before I called the multi-user story done. ## So what If you are giving an agent web search, the question is not which search API to wrap. It is whether the search itself is good enough to ground the agent, and whether the data path is one you can defend. WebSearch answers both: an Amazon-operated index of tens of billions of documents, refreshed within minutes and paired with a knowledge graph, so the agent reasons over current, cited facts instead of stale training data — and every query stays inside your AWS boundary, with no egress to a third-party engine and nothing retained outside AWS. That last part is what turns it from a convenience into something you can put in front of a security review. The auth model is the tax you *don't* pay on top of that. Because the connector is IAM-authorized, the AWS credential you already manage becomes the credential for search — no new secret, no new parser, no new vendor bill, nothing to rotate. Good search results, a data path that stays where it belongs, and an integration with nothing left to leak: that is the combination worth choosing, and it is why running web search on AWS makes sense rather than bolting a search API wrapper onto the side of your agent.