Security audit
Security checks for vulnerabilities and agentic risk
This appears to be a legitimate web search and URL extraction skill, with disclosed third-party provider use and local caching.
Install only if you are comfortable with search queries and extraction URLs being sent to the selected third-party providers. For sensitive work, choose a provider explicitly or use a self-hosted SearXNG instance, use --no-cache or WSP_DISABLE_CACHE=1 when needed, and protect any config.json or .env file containing API keys.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
cp .env.example .env
# fill in at least one key or SEARXNG_INSTANCE_URL
python3 scripts/search.py -q "latest OpenClaw release"
The declared description presents the skill as operational search functionality: searching the web, routing across providers, extracting URLs/page text, and returning ranked results. The actual code chunk does not perform web searches or extraction at all. Its primary purpose is setup and configuration management. It prompts the user for provider enablement, API keys, default routing settings, and result-count preferences; validates and tests a SearXNG URL; and saves configuration locally. While this setup behavior is related to the broader search skill, it is materially different from the declared purpose of executing searches and returning results. Therefore this code chunk does not accurately represent the declared behavior.
The declared description says the skill searches across multiple web providers and returns ranked sources and page text. The actual code does none of that. Instead, it is a security utility for validating outbound URLs to prevent SSRF, including scheme checks, hostname resolution, metadata endpoint blocking, and private IP rejection. While such validation could be a supporting component inside a web-search skill, this code chunk itself has a materially different primary purpose from the declared behavior, so this is a clear description-behavior mismatch.
The supplied code is infrastructure for executing provider calls safely and consistently: it manages retries, Retry-After handling, budgets, deadlines, circuit state, and receipts for success/failure/skip/cancel outcomes. While this could support a search system, this chunk does not actually implement the declared functionality of searching the web across Serper/Brave/Tavily/etc., extracting URLs, ranking sources, or retrieving page text. Its primary purpose is operational control of provider attempts, not search or content retrieval. Therefore the description does not accurately represent this code chunk.
The declared description suggests a runtime search capability: searching the web across many providers, extracting URLs/page text, and supporting freshness filters and research workflows. This code chunk instead implements an internal provider bakeoff tool. It selects eligible providers, directly calls provider search functions, captures errors, computes performance/quality metrics, sorts providers by score, and formats a benchmarking report with a configuration recommendation. While it touches search providers, that is in service of benchmarking and routing-priority recommendation, not fulfilling the declared end-user search/extraction behavior. Therefore the code’s primary purpose is materially different from the declared description.
The declared description promises a multi-provider web search and URL/page-text extraction capability. This code chunk instead is a policy/storage module for already-produced extraction responses. It prepares bounded extract requests, limits max URLs and max context characters, truncates result text, optionally computes spans, records warnings and degraded status, and stores full text locally on disk with TTL and size-based eviction. These are materially different from the declared primary purpose and include an undeclared local persistence capability. While some behavior is adjacent to extraction support, the advertised provider-search/routing functionality is absent from this code.
The supplied code does not perform any web search, provider routing, URL extraction, page retrieval, or ranking. It contains only budget/preflight decision logic that evaluates limits such as provider-call caps, daily quotas, timeout budgets, and context budgets, then returns a deterministic action (proceed, degrade, abort). This is a materially different primary purpose from the declared description. No search-provider integrations or external I/O are present in this chunk.
This code chunk is a cache identity and hashing utility for extraction requests, not an implementation of a multi-provider web search skill. Its primary function is to validate request parameters, canonicalize them, and derive deterministic cache keys. There is no network access, no calls to Serper/Brave/Tavily/etc., no search logic, no result ranking, and no page text extraction. The declared description therefore materially misrepresents the behavior of the supplied code.
The declared description presents an active web search/extraction capability across many external providers. The code shown does not perform searches, call providers, fetch URLs, or extract page text from the web. Its primary purpose is response caching: serializing normalized payloads, deriving cache keys, reading/writing JSON cache entries on disk, reconstructing responses from cached material, handling freshness/staleness, and quarantining corrupt cache files. While caching could support a search tool internally, this chunk’s actual behavior is materially different from the declared end-user functionality, so this is a description-behavior mismatch.
This is a clear description-behavior mismatch. The description claims an operational search/extraction skill with multi-provider routing and research/freshness functionality. The supplied code is a compatibility layer: it normalizes payload fields, constructs RequestV3 objects with routing/cache/options metadata, and projects ExecutedV3 responses back into legacy formats. While it references concepts like provider, search mode, freshness, and extraction options, these are only passed through as data fields. No network access, provider invocation, ranking, crawling, searching, or text extraction is implemented in this chunk. Therefore the declared primary purpose is materially broader and different from the actual behavior.
This is a strong description-behavior mismatch. The declared purpose advertises an operational search/extraction skill with multi-provider routing and returned ranked sources/page text. The supplied code chunk is a provider-agnostic contract module (contract_v3.py) that models requests/responses and rigorously validates payload structure, routing receipts, provenance, spans, budget preflight receipts, stored-content metadata, and related DTOs. While the schema includes concepts like SEARCH and EXTRACT capabilities, provider attempts, routing, freshness options, and results, those are only data definitions and validators. There is no networking, no API client logic, no web querying, no provider selection implementation, no URL fetching, and no content extraction. So the code supports the broader system as an internal contract layer, but it does not actually do what the skill description claims as its main behavior.
The declared description is about multi-provider web search, URL extraction, ranking sources, and page text retrieval. The supplied code chunk does none of that directly: it contains only infrastructure for running arbitrary callables on daemon threads with Future-like result(timeout) behavior. While this could be a supporting internal utility for a search tool, the chunk itself does not implement search providers, web access, URL extraction, ranking, freshness filters, or research logic. Its primary purpose is concurrent task management, which is materially different from the declared user-facing functionality.
The declared description presents the skill as a broad web-search/research capability spanning multiple providers and returning search results plus extracted page text. The supplied code does something much narrower and different: it only normalizes publication date fields from an already-available result item. While this helper could support a larger search system, this code chunk itself has no search, provider integration, result ranking, URL handling, content extraction, or routing behavior. That is a material description/behavior mismatch, not merely an implementation detail.
This is a clear description-behavior mismatch. The declared purpose promises an external search aggregation capability across many named providers, with ranked sources, extracted page text, and freshness-aware research behavior. The supplied code is an internal analytics utility for evaluating diversity within a list of results that has already been produced elsewhere. It operates purely on in-memory inputs, using URL normalization helpers, domain counting, snippet trigram similarity, entropy-based provider-mix scoring, and optional duplicate-tail reranking. There is no network access, no provider integration, no query handling, no crawling, and no freshness logic. While the code mentions 'provider' fields and 'research-mode opt-in' in comments/docstrings, those are only metadata used in scoring/reranking and do not implement the declared search functionality.
The declared description presents a multi-provider web search capability, but the supplied code chunk is purely configuration support code for loading credentials and flags from .env files. This is not merely an internal implementation detail of search behavior; the chunk itself does not perform any of the claimed search, extraction, ranking, or content retrieval functions. Its primary behavior is local environment/file handling, which materially differs from the declared purpose.
The declared description presents an end-user search capability across many providers. However, this code chunk does not perform any searching, routing, extraction, or content retrieval. Its primary purpose is internal error handling: classifying provider exceptions, generating privacy-safe messages, and returning structured ErrorV3 objects with setup guidance for missing credentials. While this may support a larger search system, the supplied code itself materially differs from the declared purpose.
The declared description is for a web search and URL extraction skill spanning many search providers. The code shown is not a search tool; it assumes URLs are already provided, validates them, invokes extraction adapters directly, measures success/latency/content volume, computes provider scores, and recommends provider priority. It also includes formatting and bounded local persistence of aggregate benchmark history. While it does touch extraction providers, its primary purpose is benchmarking provider extraction performance, not searching the web or returning research results. This is a material description/behavior mismatch.
The description claims a search aggregation capability over Serper, Brave, Tavily, Querit, Linkup, Exa, Firecrawl, You.com, SearXNG, SerpBase, and Keenable, including extraction of URLs, ranked sources, page text, and freshness filters. The actual code chunk is a pure-stdlib intent classification module with no network access, no provider integrations, no HTTP requests, no scraping, no URL handling, and no result retrieval. Its sole functional purpose is to classify user queries into intent categories using regex/rule-based scoring so another module can choose an initial provider. That is a materially different primary purpose from the declared behavior, so this is a clear mismatch.
The declared description promises a multi-provider web search and extraction skill. This code chunk instead implements optional decision helpers for an existing pipeline: configuration parsing, API key loading, heuristic/LLM-based search-type selection, extraction-quality filtering, and language filling. It neither calls any of the named search providers nor performs web search, result aggregation, ranking, or freshness/research workflows. Additionally, it introduces an external dependency on a Typesafe/Jev model for classification, which is not reflected in the description. This is a material description-behavior mismatch.
The declared description says this skill searches the web across many providers and returns ranked sources and extracted page text. The supplied code does something materially different: it is an operator/admin snapshot module for inspecting previously stored local state. Functions like build_receipts, build_benchmark_history, build_provider_health, and build_overview read owned JSONL files, provider health JSON, Markdown cache files, and a SQLite database in read-only mode. The code summarizes provider configuration, benchmark runs, adaptive samples, cache sizes, and circuit states. Although provider names and capabilities appear in metadata, there are no outbound API calls, no search requests, no URL collection from the web, and no extraction of page text from live sources. This is a strong description-behavior mismatch because the primary purpose is operational monitoring/snapshotting, not web search and extraction.
The declared description says this skill searches the web via multiple providers and returns ranked URLs/page text. The supplied code does none of that. It contains no provider-calling logic, network access, search orchestration, extraction, ranking, or freshness filtering. Instead, its primary purpose is enforcing a fail-closed privacy boundary for operator payloads by validating allowed schema values and rejecting sensitive fields, credentials, URLs, file paths, and secrets. This is a materially different purpose, so the description does not accurately represent the code.
This code chunk is not a web search or extraction implementation. Its primary purpose is persistent local logging of operator routing receipts/responses in a privacy-safe JSONL journal. It creates and locks directories/files, validates ownership, appends or rewrites receipt records, enforces TTL/max-record/max-byte limits, and loads recent records. None of the declared search-provider integrations (Serper, Brave, Tavily, Querit, Linkup, Exa, Firecrawl, You.com, SearXNG, SerpBase, Keenable), ranking, freshness filtering, URL extraction, or page text retrieval appear in this code. The behavior is materially different from the declared purpose, so this is a clear mismatch.
The declared description presents the skill as a concrete web-search capability spanning named providers and returning ranked sources/page text. The supplied code chunk is instead the central orchestration boundary around such capabilities. It delegates provider-specific behavior to adapters and contains no direct calls to Serper, Brave, Tavily, Querit, Linkup, Exa, Firecrawl, You.com, SearXNG, SerpBase, or Keenable, nor logic for extracting URLs or page text. Its primary behaviors are request normalization, policy enforcement, budget preflight, cache handling, response normalization, state-store access, and operator receipt journaling. Those are materially different from the declared end-user purpose, so this chunk does not accurately represent the described skill behavior on its own.
The supplied code is infrastructure for adapter protocol enforcement, not a web search/extraction implementation. It declares callable signatures for search/extract adapters, detects missing/unexpected providers in dispatch tables, raises initialization errors when registry and adapters diverge, and validates returned payload schemas. It does not contact Serper, Brave, Tavily, or any provider; does not issue searches; does not retrieve page text; and does not rank or filter results. This is a materially different primary purpose from the declared description, so the description does not accurately represent the code chunk.
The description presents an end-user web search/extraction skill. This code chunk instead provides internal infrastructure for managing search/extract providers: built-in provider specs, plugin discovery via local Python files, validation of provider interfaces, duplicate detection, registration, default routing priorities, setup presets, and metadata catalogs. While the registry references the same providers named in the description and supports routing-related metadata, it does not itself perform search queries, fetch URLs, extract page text, or return ranked sources. Thus the supplied code’s primary purpose is materially different from the declared behavior.