AgentCore Web Search hit general availability at AWS Summit New York on June 17, 2026, and if you’ve been waiting for a managed, zero-data-egress web grounding tool for your Bedrock agents — congratulations, your patience has been rewarded. This is not another half-baked preview feature that demos beautifully and quietly rots in the console. Web Search is now GA, it’s SOC 1/2/3 compliant, and it integrates directly into the AgentCore harness as a first-class tool attachment. Let’s talk about how it actually works under the hood.
What “Zero Data Egress” Actually Means for AgentCore Web Search
The phrase “zero data egress” gets thrown around a lot by marketing teams who clearly haven’t met a network engineer. So let’s be precise about what AWS is claiming here — and what it means for your compliance posture.
When your AgentCore agent invokes the Web Search tool, the search request originates from within AWS-managed infrastructure that never touches your VPC or your data plane. Your prompts, your internal context, your retrieved Knowledge Base chunks — none of that leaves the AWS security boundary. The web search service acts as a one-way import valve: public web content comes in, gets sanitized and cited, and is returned to your agent’s context window. Your customer data never rides outbound on that request.
Concretely:
- What stays in your secured environment: Agent instructions, system prompts, retrieved Knowledge Base content, conversation history, tool outputs, model invocations.
- What crosses the AWS-managed search boundary: The search query string derived from the agent’s reasoning. That’s it.
- What never happens: Your VPC traffic routing through a public search endpoint, your IAM credentials getting attached to outbound web requests, your private data being embedded in search queries.
This architecture matters enormously for regulated industries. If you’re in healthcare, finance, or government, the traditional RAG-plus-web approach required you to either air-gap your agents (and accept stale knowledge) or build elaborate proxy setups with DLP controls. AgentCore Web Search collapses that to a single managed capability with a well-defined trust boundary.
The Citation Model
Web Search doesn’t just return text — it returns structured, cited results. Each result chunk includes a sourceUri, a title, and a relevance-ranked excerpt. Your agent’s response generation layer can use these to produce grounded answers with inline citations, which your application layer can then render however you like.
The retrieval model works like this: AgentCore issues a search, gets back N ranked results (configurable), each with its citation metadata intact. The model uses those results as context. If you’ve wired up response citation tracking at the invocation level, you get a citations array in the response payload mapping response text spans to source URIs. This is the difference between an agent that says “according to recent sources” (useless) and one that says “per the NIST SP 800-218A guidance published April 2025 at [url]” (actually useful).
IAM Permissions Required
Before you wire anything up, your agent execution role needs the right permissions. Web Search is a managed Bedrock capability, so the permissions are within the bedrock: namespace:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AgentCoreWebSearchAccess",
"Effect": "Allow",
"Action": [
"bedrock:InvokeAgent",
"bedrock:UseAgentCoreWebSearch"
],
"Resource": "*"
},
{
"Sid": "GuardrailsApply",
"Effect": "Allow",
"Action": [
"bedrock:ApplyGuardrail"
],
"Resource": "arn:aws:bedrock:us-east-1:123456789012:guardrail/YOUR_GUARDRAIL_ID"
}
]
}
Lock down the Resource ARN for UseAgentCoreWebSearch to the specific agent ARN in production — wildcard is fine for dev, not fine for anything that touches real data.
Attaching Web Search to the AgentCore Harness
Here’s where the rubber meets the road. The AgentCore harness config accepts tool definitions in a declarative JSON structure. Web Search is a managed tool, so you don’t define a Lambda function or schema — you reference it by its managed tool type. Here’s a minimal harness configuration with Web Search attached and Guardrails wired in:
{
"agentName": "market-intelligence-agent",
"foundationModel": "anthropic.claude-sonnet-4-5",
"instruction": "You are a market intelligence assistant. Use Web Search to ground your answers in current information. Always cite your sources. Never speculate beyond what sources support.",
"agentResourceRoleArn": "arn:aws:iam::123456789012:role/AgentCoreExecutionRole",
"guardrailConfiguration": {
"guardrailIdentifier": "arn:aws:bedrock:us-east-1:123456789012:guardrail/abc123xyz",
"guardrailVersion": "DRAFT"
},
"tools": [
{
"toolSpec": {
"managedToolType": "BEDROCK_WEB_SEARCH",
"webSearchToolConfiguration": {
"maxResults": 10,
"searchFilter": {
"excludeDomains": ["reddit.com", "twitter.com"],
"requireHttps": true
}
}
}
}
],
"idleSessionTTLInSeconds": 1800
}
A few notes on that config worth calling out. The managedToolType: BEDROCK_WEB_SEARCH is what tells the harness this is a first-party managed tool versus a custom Lambda tool or an MCP server attachment. The searchFilter block lets you whitelist or blacklist domains — handy when you want your agent grounding in authoritative sources only and not in whatever forum post happens to rank for your query. The requireHttps flag rejects any plain-HTTP sources, which you should probably always have on unless you enjoy surprises.
Combining Web Search with Bedrock Guardrails
The Guardrails integration here is tighter than you might expect — it’s not just a post-processing filter slapped on the response. Guardrails can intercept both the search query and the model’s generated response, applying content policies at both points in the pipeline.
What that means practically:
- Input guardrails can block or rewrite search queries that trip a topic policy (e.g., prevent the agent from searching for anything in a restricted topic category).
- Output guardrails screen the final response for PII, toxic content, or off-topic material before it ever reaches your application layer.
- Grounding checks — this one’s underrated — use Bedrock’s factual grounding evaluator to score how well the model’s response is actually supported by the retrieved web content. Low grounding score? You can configure the guardrail to block the response entirely or flag it for human review.
Here’s an SDK invocation example that puts it all together — creating an agent session and invoking with citation tracking enabled:
import boto3
bedrock_agent_runtime = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
response = bedrock_agent_runtime.invoke_agent(
agentId="AGENT_ID_HERE",
agentAliasId="TSTALIASID",
sessionId="session-001",
inputText="What are the latest DORA compliance requirements for financial institutions in the EU as of 2026?",
enableTrace=True,
sessionState={
"invocationId": "invocation-001"
}
)
# Stream the response chunks
event_stream = response["completion"]
citations = []
full_response = ""
for event in event_stream:
if "chunk" in event:
chunk = event["chunk"]
full_response += chunk["bytes"].decode("utf-8")
# Extract citations if present
if "attribution" in chunk:
for citation in chunk["attribution"].get("citations", []):
for ref in citation.get("retrievedReferences", []):
citations.append({
"text": ref.get("content", {}).get("text", ""),
"uri": ref.get("location", {}).get("webLocation", {}).get("url", ""),
"title": ref.get("metadata", {}).get("title", "")
})
print("Response:", full_response)
print("Citations:", citations)
Performance Characteristics Worth Knowing
Web Search adds latency — there’s no getting around it. In testing, you’re looking at roughly 800ms–2.5s of additional latency per search invocation, depending on query complexity and the number of results you’ve configured. For synchronous user-facing applications that’s noticeable. For async batch processing or background intelligence pipelines, it’s irrelevant.
A few latency-mitigation patterns that work well:
- Parallel tool invocation: If your agent needs both Web Search and a Knowledge Base lookup, configure the harness to allow parallel tool calling. The AgentCore orchestrator will fire both simultaneously and merge results.
- Result caching: Web Search results aren’t cached by default. For high-traffic agents searching similar queries, consider an ElastiCache layer in front of your invocation handler to cache search results by query hash with a short TTL (15–60 minutes for most use cases).
- maxResults tuning: More results = better grounding but more tokens and more latency. Start at 5, measure grounding scores, increase to 10 only if your factual accuracy numbers aren’t where you need them.
When Web Search Is the Right Tool (and When It Isn’t)
Web Search is built for agents that need current, publicly available knowledge — regulatory updates, market news, product documentation, published research. It’s the right tool when the answer exists on the public web and your internal Knowledge Base doesn’t have it or has a stale version.
It’s the wrong tool when you need proprietary, private, or structured enterprise data. For that, you want the Managed Knowledge Base. And it’s definitely the wrong tool when you need access to paywalled content, premium APIs, or data that requires authentication — that’s what AgentCore Payments handles. The three capabilities are designed as a stack, not as alternatives.
If you’re building a production agent and you’re only using Web Search, you’re leaving half the architecture on the table. The real power is layering Web Search (public knowledge), Managed KB (internal knowledge), and Payments (premium knowledge) into a single harness that lets your agent reason across all three.
At Enkompass (enkompass.net), this is our home turf. We’ve shipped production Bedrock and SageMaker workloads that actually move the needle, not just demo well. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.