Licensed to be used in conjunction with basebox, only.
// security
Web search
Applies to
Product: 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.
Starting point
With web search, 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 limits web search with the controls below 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 | Off by default; enabled per app by the administrator, switched on per chat by the person; 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 |
Web search runs via Staan.ai in the EU
Web search runs via Staan.ai in the EU and only if you enable it. Staan.ai operates a European search index (Qwant/Ecosia). Only the search term is transmitted, without the person's identity or IP address. Staan is a sub-processor of basebox; basebox has a DPA with Staan, and training on search queries is excluded. 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 path through which internal data can be exfiltrated. We recommend not combining web search and internal connectors in the same app: 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 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).
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