📝 **Frage:** **Schreiben Sie die Funktion** \`safe_search(query, filter)\`, die ein mandantenfähiges RAG vor der Leak-Klasse Nr. 1 schützt – einem fehlenden \`tenant_id\`-Filter. Regeln: - Wenn \`filter\` kein Diktat ist → \`ValueError("filter muss ein Diktat sein")\` auslösen. – Wenn „tenant_id“ fehlt ODER leer/falsch ist → „ValueError(“SICHERHEIT: Der Filter „mieter_id“ ist obligatorisch und nicht leer“)“ auslösen. - Andernfalls geben Sie \`f"OK | {query!r} mit Gültigkeitsbereich für den Mandanten {filter['tenant_id']!r}"\` zurück. Führen Sie es dann gegen vier Anforderungsformen aus (zwei echte, zwei unsichere): \`\`\` OK | „Rückerstattungsrichtlinie“ gilt für Mieter „acme“ GESPERRT | 'Gehaltstabelle' | SICHERHEIT: Der Filter „mieter_id“ ist obligatorisch und nicht leer OK | „Bestellverlauf“ auf Mandant „Globex“ beschränkt GESPERRT | 'API-Schlüssel' | SICHERHEIT: Der Filter „mieter_id“ ist obligatorisch und nicht leer \`\`\` Der Fall mit leeren Zeichenfolgen ist heimtückisch – \`"tenant_id" in filter\` würde passieren, aber \`filter.get("tenant_id")\` gibt einen falschen Wert zurück. **Überprüfen Sie immer die Wahrheit, niemals nur das Vorhandensein des Schlüssels.** Ein falsch konfiguriertes Frontend, das standardmäßig \`tenant_id\` auf \`""\` setzt, hat in der Praxis zu mandantenübergreifenden Lecks geführt. 📋 Wählen Sie die richtige Antwort. 💡 **Hinweis:** Lesen Sie die obige Theorie noch einmal, wenn Sie sich nicht sicher sind.