Licensed to be used in conjunction with basebox, only.
// security
Web search
Applies to
Product: Demo · Cloud · Server · Audience: Security / Compliance reviewer
Security properties of the web search connector: routing to exactly one provider, enforced egress allowlist, results as plain text only, audit log with metadata only, off by default, consent per user. This page is the reviewers' short version; the readable introduction is under Web search in basebox, the full policy Web Search MCP – Security & Safety Policy is available on request.
The honest starting point
Web search is the only feature where content a user enters leaves the basebox environment by design – the text of the query goes to the search provider. As soon as the open web is part of the loop, no vendor can fully guarantee security. basebox makes web search as secure as is reasonably possible and names the residual risk – the decision to enable it is yours.
Controls
| Control | Implementation | Status |
|---|---|---|
| One provider per connector | Every web search connector reaches exactly one search provider; no third-party search SDKs, no fetching of arbitrary pages | In place |
| Egress allowlist at the MCP gateway | The connector may reach only its provider's hosts – for Staan api.staan.ai and nothing else; all other outbound traffic of the connector is blocked |
In place |
| No user identity, no user IP | Queries leave the environment via basebox's connection, not from the user device | In place |
| Plain text only | API providers deliver structured data; basebox fetches or renders no web pages; with scraping providers, scripts and active content are removed; size limit per hit | In place |
| Audit log per call – metadata only | Organization, user, tool, provider, result, timestamp; not the text of the query | In place |
| Off by default | For the installation, per app, per chat; off in every new conversation | In place |
| Consent before the first search | Visible dialog with warning; cannot be disabled | In place |
| Limitation per app | An app has exactly the connectors it is allowed; the boundary is enforced | In place |
| Content-aware framing | Web results are presented to the model as data to read, not as instructions | In place |
| Finer tool selection, "web search only" template, visibility per group, human-in-the-loop | – | Roadmap |
Providers
| Provider | Role | Data protection |
|---|---|---|
| Staan (default) | European search index (Qwant/Ecosia) | EU company, processing in EU data centers, no tracking/profiling, DPA available |
| DuckDuckGo (alternative) | Metasearch | No user profiles, no tracking of searches; US company |
| Others | After approval by the administrator | The same one-provider discipline |
The contract with the provider is part of your assessment: with Staan the query stays within the EU legal space and a DPA is available; with DuckDuckGo a US company processes it. Configuration: Web search.
The three risks
- Confidential information in a query – the everyday risk. Controlled via who may use the tool and a short usage rule ("no patient names in web searches"), not via software that guesses confidentiality.
- Prompt injection from a web page – worst realistic outcome on its own: a misleading answer.
- Web search + connector for internal data in the same app – the real exfiltration path. Architectural answer: a separate app whose only connector is web search. Without an internal connector in that app, the path does not exist – regardless of the model.
What the audit log shows
Every web search call is traceable as a metadata entry; the query text is deliberately not stored. That is a deliberate design decision against false security through keyword filters (Audit & logging).
Per deployment model
- Cloud: the path goes from the Noris data center to the provider; nothing to allow on your side. All switches sit with your administrators.
- Server: additionally your firewall – allow exactly the provider hosts or nothing at all. Air-gapped, web search is unavailable (Air-gapped environments).
- Demo: to try out the behaviour (consent dialog, notice) with test queries.
Recommended start
The controlled pilot: a separate app whose only connector is web search, limited to a defined group, with a one-line usage rule and a review date. Step by step: Policies → Implementing a requirement.
Next step: Connectors