📝 **Vraag:** **Schrijf de functie** \`safe_search(query, filter)\` die een multi-tenant RAG beschermt tegen de nr. 1 lekklasse: een ontbrekend \`tenant_id\` filter. Regels: - Als \`filter\` geen dictaat is → raise \`ValueError("filter moet een dictaat zijn")\`. - Als \`tenant_id\` afwezig is OF leeg/onwaar is → raise \`ValueError("BEVEILIGING: filter tenant_id is verplicht en niet leeg")\`. - Retourneer anders \`f"OK | {query!r} gericht op tenant {filter['tenant_id']!r}"\`. Voer het vervolgens uit tegen vier verzoekvormen (twee echte, twee onveilig): \`\`\` Oké | 'restitutiebeleid' gericht op huurder 'acme' GEBLOKKEERD | 'salaristabel' | BEVEILIGING: het filter tenant_id is verplicht en niet leeg Oké | 'bestelgeschiedenis' gericht op tenant 'globex' GEBLOKKEERD | 'API-sleutels' | BEVEILIGING: het filter tenant_id is verplicht en niet leeg \`\`\` De lege tekenreeks is een stiekem geval: \`"tenant_id" in filter\` zou passeren, maar \`filter.get("tenant_id")\` retourneert vals. **Controleer altijd op waarheidsgetrouwheid, nooit alleen op de aanwezigheid van de sleutel.** Een verkeerd geconfigureerde frontend die de \`tenant_id\` standaard instelt op \`""\` heeft in de praktijk tot cross-tenant-lekken geleid. 📋 Kies het juiste antwoord. 💡 **Hint:** Herlees de bovenstaande theorie als je het niet zeker weet.