Decision takeaway: AWS’s November 11, 2026 direct AgentCore Web Search API removes the need to configure an AgentCore Gateway for a simple search call. It does not remove the need to govern which sources may influence decisions, what the application may disclose in queries, or how search evidence is verified before an agent acts.
What actually changed
According to AWS’s November 11 announcement, the new InvokeWebSearch operation accepts AWS SigV4-authenticated calls, checks bedrock-agentcore:InvokeWebSearch, and returns ranked extracts with URLs, titles and publication timestamps where available. Calls can include publication-date and domain filters. AWS says the direct API is billed at $7 per 1,000 queries, without Gateway charges; pricing and supported Regions should be rechecked at procurement time. The established Gateway remains AWS’s recommended path for most MCP-compatible agent workloads.
The architectural distinction is important. A gateway can centrally hold search-source rules that the calling agent cannot change. With the direct API, the application submits filters with each request. IAM authorizes the API operation; it does not independently guarantee that every result is suitable for the task. The control boundary therefore moves into application code and its deployment process.
Four separate decisions that search results cannot make
Source admission: Should a result from an unfamiliar domain be allowed into the agent’s working context? An allowlist may suit a regulated policy lookup, but not open-ended market research. Define source tiers and a documented exception process.
Evidence acceptance: A ranked extract is not a verified assertion. Require the original page URL, publication date when supplied, and a check that the cited passage actually supports the claim. A missing date should be recorded as unknown, not silently treated as current.
Data disclosure: Search queries can contain customer names, internal identifiers or unpublished plans. Review query construction, redaction and logging before permitting sensitive workloads. Network-private connectivity to an API does not itself establish the classification or retention rules for the submitted query.
Action authorization: Search can inform a recommendation, but cannot authorize a payment, policy change or production deployment. Keep tool permissions and approvals separate from retrieved content, consistent with the agent authorization boundary already examined on CPX.
An evidence pipeline for production agents
Store a compact evidence record for each material answer: query identifier, policy version, allowed domains, retrieval timestamp, result URL, source publication timestamp if available, claim supported, verification outcome and downstream decision ID. Do not confuse this record with proof that a page is true; it makes the decision auditable and challengeable.
Six acceptance tests before release
- Policy immutability: Try to make an untrusted document persuade the agent to remove domain exclusions. Confirm the enforcement code ignores it.
- Stale evidence: Ask a date-sensitive question with old and current sources. Confirm the system flags missing dates and rejects stale evidence under the task’s freshness rule.
- Conflicting sources: Supply two plausible but inconsistent statements. Confirm the answer surfaces the disagreement rather than selecting the highest-ranked result automatically.
- Query leakage: Seed a test prompt with synthetic sensitive identifiers. Verify they are redacted before the search request and absent from application logs.
- Cost controls: Simulate retries, repeated questions and a looping agent. Enforce query budgets, cache policy and alerting. Compare cost per accepted, verified answer rather than cost per query alone.
- Action separation: Insert a malicious instruction into a search extract. Verify it cannot expand tool scopes or bypass a human approval.
How to govern the search budget
Establish a monthly search-query ceiling per workload and a per-task maximum. A retry after a network failure should not create a fresh unbounded research chain. For every evaluation sample, record query count, successful evidence checks and unsupported claims. Separate searches that merely return results from searches that materially improve the answer. Finance should compare these measurements with the published API price and any additional orchestration, storage and verification expense. A cost ceiling without a quality floor can simply incentivize weaker sourcing.
For regulated tasks, have the information owner approve which domains and document types are admissible, the security owner approve query-data classification, and the application owner approve action boundaries. Record those approvals in versioned configuration and test a rollback. This is especially important when a direct API replaces a centrally administered gateway: configuration ownership is not automatically inherited.
When the gateway still earns its place
Choose the direct API when one application owns orchestration, caching, retry policy and source enforcement. Prefer a shared gateway when multiple MCP clients need centrally administered tool access and consistent source restrictions. For agents with broad delegated actions, review the workflow authorization tests; for claims drawn from enterprise documents, see knowledge freshness testing. Neither integration path replaces these controls.
Source and scope: AWS, November 11, 2026. API capabilities and quoted pricing are vendor statements; the six tests above are independent editorial recommendations, not AWS certification requirements.
Leave A Comment