Licensed to be used in conjunction with basebox, only.
// sicherheit
Websuche in basebox
Gilt für
Produkt: Cloud · Server · Zielgruppe: Administrator · Sicherheits- / Compliance-Prüfer · Entscheider
Einführung: Wie wir sie sicher halten
Worum es geht: Eine kurze, lesbare Einführung, wie die Websuche in basebox funktioniert und wie wir sie so sicher machen, wie es vernünftigerweise geht. Verstehen Sie diese Seite als Überblick; das vollständige Richtliniendokument ist die vertiefte Referenz dahinter.
Der ehrliche Ausgangspunkt
Die Websuche ist eines der nützlichsten Dinge, die ein KI-Assistent tun kann, und die Fähigkeit, nach der fast jeder Kunde zuerst fragt. Sie ist zugleich mit Abstand am schwersten sicher zu machen. Das wollen wir von Anfang an klar sagen: Sobald das offene Web Teil der Schleife ist, kann kein Anbieter – weder basebox noch irgendjemand sonst – die Sicherheit des Systems vollständig garantieren. Wir tun nicht so, als wäre es anders.
Das ist aber nur die halbe Geschichte, und die weniger wichtige Hälfte. Worauf es uns ankommt: die Websuche so sicher zu machen, wie es vernünftigerweise geht, genau zu benennen, wo die Grenzen liegen, jedes bekannte oder vermutete Risiko offen anzusprechen, und klar zu sagen, was wir bereits tun und was als Nächstes möglich ist. Diese Seite ist unsere ehrliche, schriftliche Grundlage für dieses Gespräch – dieselbe Grundlage, die wir mit jedem Kunden teilen.
Wie die Websuche in basebox funktioniert
Stellt ein Nutzer eine Frage, die das Web braucht, geht die Anfrage nicht von seinem Laptop oder Rechner nach außen. Sie wird durch basebox in Ihrer eigenen Umgebung geleitet, an einen einzigen, ausdrücklich konfigurierten Suchanbieter gesendet – standardmäßig Staan, der europäische Suchindex von Qwant und Ecosia, mit DuckDuckGo (oder einem anderen von Ihrem Admin freigegebenen Anbieter) als Alternative – und die Ergebnisse werden auf reinen Text reduziert, bevor die KI sie überhaupt sieht. Keine Skripte, kein aktiver Inhalt, keine anderen Websites, keine anderen Anbieter.
Einige Eigenschaften dieses Designs sind hervorzuheben, weil alles Weitere darauf aufbaut:
- Es läuft in Ihrer Umgebung. Anfragen verlassen das System über die eigene Verbindung von basebox, nicht von einzelnen Nutzergeräten. Die IP-Adressen Ihrer Nutzer werden dem Suchanbieter nie offengelegt.
- Ein Anbieter je Konnektor, und nichts sonst. Jeder Websuche-Konnektor erreicht genau einen Suchanbieter – keine Such-SDKs von Dritten, kein Abrufen beliebiger Seiten. Das gilt für jeden gewählten Anbieter: Staan (der Standard) ist ein EU-Unternehmen, das Anfragen in EU-Rechenzentren ohne Tracking oder Profiling verarbeitet, mit verfügbarem AVV; DuckDuckGo bildet keine Nutzerprofile und trackt keine Suchen; dieselbe Ein-Anbieter-Disziplin gilt für jeden weiteren Anbieter, den wir ergänzen. Die Grenze ist nicht nur Richtlinie: Eine am MCP-Gateway erzwungene Egress-Allowlist bedeutet, dass der Konnektor keinen anderen Host als seinen deklarierten Anbieter erreichen kann.
- Nur reiner Text. Bei einem API-basierten Anbieter wie Staan kommen Ergebnisse als strukturierte Daten an – basebox ruft oder rendert selbst nie Webseiten, sodass es von vornherein nichts zu entfernen gibt. Wo ein Anbieter das Lesen von Seiten erfordert, werden Skripte, Styles und jeder andere aktive Inhalt entfernt, bevor Text die KI erreicht. In beiden Fällen gibt es auf diesem Pfad keine Stelle, an der Code einer Website ausgeführt werden könnte, und die Textmenge je Treffer ist begrenzt.
- Jeder Aufruf wird festgehalten. Jeder Werkzeugaufruf wird in ein Audit-Log geschrieben (Organisation, Nutzer, welches Werkzeug, welcher Anbieter, Erfolg oder Fehlschlag und Zeitstempel), damit die Nutzung nachvollziehbar ist. Das Log hält nur diese Metadaten fest – den Text der Anfrage selbst speichert es bewusst nicht.
Was schiefgehen kann – in einfachen Worten
Wir fassen die realen Risiken in drei Gruppen, in einfacher Sprache.
1. Vertrauliche Informationen in einer Anfrage (das Alltagsrisiko). Tippt ein Nutzer vertrauliche Details in ein Suchfeld, werden diese an den Suchanbieter gesendet – sie verlassen Ihre Umgebung. Das ist das realistischste Alltagsrisiko, und es lässt sich am besten darüber steuern, wer das Werkzeug nutzen darf und über eine kurze Nutzungsregel (zum Beispiel: keine Patientennamen oder Falldetails in einer Websuche) – nicht durch Software, die zu erraten versucht, was vertraulich ist. Mit dem Standardanbieter Staan bleibt die Anfrage zumindest im EU-Rechtsraum (EU-Rechenzentren, AVV verfügbar), was die regulatorische Exposition dieses Risikos verringert – aber nicht beseitigt: Die Regel oben gilt bei jedem Anbieter. basebox zeigt zusätzlich jedes Mal eine sichtbare Bestätigung, wenn die Websuche in einer App aktiviert wird.
2. Eine Webseite, die versucht, mit der KI zu „sprechen" („Prompt-Injection"). Eine bösartige Seite kann versteckten Text enthalten, der der KI Anweisungen geben soll. Ein gut trainiertes Modell ignoriert das meist, aber kein Modell ist zu 100 % zuverlässig. Für sich genommen ist das schlimmste realistische Ergebnis eine irreführende Antwort.
3. Websuche kombiniert mit Werkzeugen für interne Daten in derselben App (das wichtigste). Diesen Fall nehmen wir am ernstesten. Sind Websuche und ein Werkzeug für interne Daten (z. B. Ihr Wiki oder Ihre Dateien) in derselben App eingeschaltet, könnte eine eingeschleuste Anweisung von einer Webseite versuchen, interne Daten zu lesen und sie über eine Folgesuche herauszuschmuggeln. Das ist der echte Exfiltrationspfad.
Die gute Nachricht: Dieses ernsteste Risiko hat eine saubere, architektonische Antwort, die nicht davon abhängt, wie klug das KI-Modell ist.
Wie wir sie so sicher machen, wie es vernünftigerweise geht
Unser Ansatz ist Defense in Depth: mehrere unabhängige Schichten, sodass kein einzelner Ausfall Sie exponiert. Einige Schichten sind heute im Einsatz; andere stehen auf unserer Roadmap, und wir sagen offen, welche welche sind.
Heute im Einsatz:
- Routing zu genau einem Anbieter innerhalb Ihrer basebox-Umgebung (Staan als Standard – EU-Index, EU-Verarbeitung; DuckDuckGo oder ein anderer freigegebener Anbieter, wo konfiguriert).
- Erzwungene Egress-Allowlist. Jeder Konnektor darf nur die Hosts seines deklarierten Anbieters erreichen (für Staan:
api.staan.aiund nichts sonst); das MCP-Gateway blockiert allen anderen ausgehenden Verkehr des Konnektors. - Nur-Text-Aufnahme – API-basierte Anbieter liefern strukturierte Daten (basebox ruft oder rendert nie eine Seite); bei Scraping-basierten Anbietern werden alle Skripte und aktiven Inhalte entfernt. Größenbegrenzung je Treffer in beiden Fällen.
- Audit-Logging je Aufruf (Metadaten, nicht der Inhalt der Anfrage).
- Anbieter-Begrenzung je App. Jede App ist mit genau den Konnektoren konfiguriert, die sie nutzen darf, und diese Grenze wird durchgesetzt: Ein in einer App aktivierter Konnektor schwappt nicht in eine andere. Sie können also eine App betreiben, deren einziger Konnektor die Websuche ist, vollständig getrennt von einer App, die Ihr internes Wiki nutzt.
- Zusätzlich Opt-in je Nutzer – innerhalb dessen, was eine App anbietet, aktiviert jeder Nutzer die Konnektoren, die er möchte.
- Standardmäßig aus, und aus in jeder neuen Unterhaltung – die Websuche zu aktivieren ist jedes Mal eine bewusste Entscheidung, und basebox fragt vor der ersten Suche nach der Zustimmung des Nutzers. Sie lässt sich außerdem für eine gesamte Installation ein- oder ausschalten.
- Inhaltsbewusste Rahmung, die Webergebnisse so verpackt, dass die KI sie als zu lesende Daten behandelt, nie als zu befolgende Anweisungen.
Die wirksamste einzelne Maßnahme ist zugleich die einfachste: Betreiben Sie die Websuche in einer eigenen App, deren einziger Konnektor die Websuche ist. Ohne Konnektor für interne Daten in dieser App existiert der Exfiltrationspfad (Risiko 3) schlicht nicht – unabhängig vom Verhalten des Modells. Weil App-Grenzen durchgesetzt werden, ist das eine Konfigurationsentscheidung je App, nicht etwas, das auf das gute Verhalten des Modells angewiesen ist.
Auf unserer Roadmap (offen, was als Nächstes kommt):
- Feinere Werkzeugauswahl innerhalb eines Konnektors und eine Ein-Klick-Vorlage „nur Websuche", damit das empfohlene Setup mit eigener App noch leichter aufzusetzen ist.
- Werkzeugsichtbarkeit je Gruppe und optionale Freigabe durch einen Menschen (Human-in-the-Loop).
Wir protokollieren den Inhalt von Anfragen bewusst nicht (Sie sind abgeschottet; wir halten Ihre Daten nicht), und wir werden keine Schlüsselwort- oder Ausgabefilter liefern, die als Sicherheitsgarantie verkleidet sind – weil sie falsche Sicherheit statt echten Schutz erzeugen.
Ihre Optionen – Sie entscheiden, mit vollständiger Information
Unser Ziel ist, Ihnen alles zu geben, was Sie für eine informierte, bewusste Entscheidung brauchen. Mit dieser Einführung (und der vollständigen Richtlinie dahinter) können Sie jeden dieser Wege wählen, und wir helfen bei jedem gern.
Die meisten Kunden – auch regulierte wie Kliniken – beginnen mit dem kontrollierten Pilot: eine eigene App, deren einziger Konnektor die Websuche ist, begrenzt auf eine definierte Gruppe, mit einer einzeiligen Nutzungsregel und einem Überprüfungstermin. Das ist ein vertretbarer, vernünftiger Standard statt einer Alles-oder-nichts-Entscheidung.
Das Fazit in einem Satz
Wir können die Websuche so sicher machen, wie es vernünftigerweise möglich ist, und über das verbleibende Risiko vollständig transparent sein. Das offene Web bedeutet, dass dieses Restrisiko nie exakt null ist – die endgültige Entscheidung treffen also Sie bewusst, und wir unterstützen sie ehrlich.
Sie wollen die Tiefe hinter dieser Seite?
Diese Einführung ist bewusst kurz. Die vollständige Web Search MCP – Security & Safety Policy behandelt alles in der Tiefe: das komplette Bedrohungsmodell und die Risikobewertung (Wahrscheinlichkeit × Auswirkung, Restrisiko, Zuordnung zu OWASP LLM Top 10 und DSGVO/HIPAA), jede bestehende und geplante Gegenmaßnahme, den Vergleich unseres Ansatzes mit den führenden KI-Labors, die gesamte Bandbreite alternativer Anbieter und ihre Abwägungen sowie das Modell geteilter Verantwortung. Wir stellen sie auf Anfrage bereit und empfehlen sie für Ihre Sicherheits- und Compliance-Verantwortlichen.