Het 'wie kan wat zien'-probleem: gebruikersrechten toevoegen aan je met AI gebouwde app

Het moment waarop je met AI gebouwde app ophoudt alleen voor jou te zijn, is het moment waarop rechten een echt probleem worden. Tot dan toont elke pagina alles. Elke lijst toont elke rij. Elke knop werkt voor iedereen. Het is een singleplayer-app die doet alsof hij multiplayer is.

Dan voeg je je eerste teamgenoot toe, of je eerste klant, of je eerste betatester — en ze zien iets dat ze niet zouden moeten zien. Misschien is het het salaris van hun teamgenoot. Misschien is het een concept dat nog niet klaar was. Misschien zijn het de beheerdersinstellingen, per ongeluk blootgesteld.

Dit is het “wie kan wat zien”-probleem, en het is het allergrootste dat niet-technische bouwers verkeerd doen bij het lanceren van een AI-appbouwer-project. Het goede nieuws: je hoeft geen beveiligingsexpert te worden om het op te lossen. Je hebt gewoon een heldere manier nodig om er met je AI-bouwer over te praten.

Waarom je met AI gebouwde app permissief begint

Wanneer je een app beschrijft aan een AI-bouwer — “Ik wil een CRM waar ik klanten en notities kan toevoegen” — optimaliseert de bouwer voor één ding: hem laten werken voor de persoon die het beschrijft. De standaard-app is “iedereen die is ingelogd kan alles zien”. Dit is prima voor een persoonlijke tool. Het is een ramp op het moment dat een tweede gebruiker verschijnt.

Dit is geen bug in de AI-appbouwer. Het is het natuurlijke gevolg van het feit dat je hem niet vertelde wie wat mag zien. De bouwer heeft geen idee dat je klantenlijst gevoelig is, of dat “Notities” dingen kunnen bevatten die je klanten niet wilt laten zien. Je moet het zeggen.

De drie vragen om te stellen voordat je een tweede gebruiker toevoegt

Voordat je iemand uitnodigt, vraag jezelf drie dingen af. Schrijf de antwoorden op — je voert ze in de volgende stap aan je AI-bouwer.

1. Wat zijn de rollen?

Niet de mensen — de categorieën. De meeste apps hebben er ergens tussen de twee en vier. Voor een freelancerportaal: “Ik” en “Klant”. Voor een interne tool: “Beheerder”, “Manager”, “Teamlid”. Voor een community-app: “Moderator”, “Lid”, “Gast”. Verzet je tegen de drang om vroeg verder te gaan dan vier rollen. Elke rol verdubbelt de regels die je moet bijhouden.

2. Wat kan elke rol zien?

Loop mentaal door elke pagina in je app. Vraag voor elke: zou een Klant deze pagina überhaupt moeten zien? Zouden ze alle data erop moeten zien, of alleen die van henzelf? Zouden ze de pagina moeten zien maar met sommige velden verborgen?

Het simpelste patroon: eigenaren zien alles; iedereen anders ziet alleen wat ze expliciet toegang toe kregen. Dit werkt voor 80% van de apps zonder veel maatwerk.

3. Wat kan elke rol doen?

Dezelfde oefening, maar voor knoppen en acties. Kan een Lid een project verwijderen? Kan een Klant zijn profiel bewerken maar niet zijn plan? Kan een Manager nieuwe mensen uitnodigen? De meeste niet-technische bouwers vergeten deze stap volledig en eindigen met apps waar elke ingelogde gebruiker de hele database kan verwijderen met één knopdruk.

Met je AI-bouwer praten over rechten

Zodra je antwoorden hebt, schrijft de prompt aan je AI-bouwer zichzelf. Hij ziet er zo uit:

Werk deze app bij om twee rollen te ondersteunen: Eigenaar en Klant.

Eigenaren kunnen alle klanten, alle projecten en alle facturen zien. Eigenaren kunnen alles aanmaken, bewerken en verwijderen.

Klanten kunnen alleen hun eigen projecten en hun eigen facturen zien. Ze kunnen de klantenlijst, de teampagina of de instellingenpagina niet zien. Ze kunnen hun projecten bekijken maar niet bewerken. Ze kunnen hun eigen facturen bekijken en betalen.

Wanneer een Klant is ingelogd, verberg de navigatielinks naar Instellingen en Team. Als een Klant probeert die pagina’s via URL te bezoeken, leid ze om naar hun dashboard.

Drie dingen doen ertoe in die prompt:

Wees specifiek per pagina en actie. “Klanten kunnen hun projecten zien” is vaag. “Klanten kunnen hun eigen projecten op de /projects-pagina bekijken maar niet bewerken” is iets dat een AI-bouwer echt kan implementeren.
Zeg wat er met de navigatie gebeurt. De link verbergen is niet hetzelfde als de pagina blokkeren. Je wilt beide.
Dek het URL-typen-geval. Anders kan een nieuwsgierige gebruiker /admin in zijn browserbalk plakken en zo binnenlopen.

De vier fouten die ik elke week zie

Na een hoop bouwers hun eerste multi-user-app te hebben zien lanceren, duiken dezelfde fouten op:

De knop verbergen is niet de data verbergen. Als je je AI-bouwer vertelt om “de verwijderknop voor Klanten te verbergen”, verdwijnt de knop van het scherm. Maar de onderliggende verwijderoperatie werkt nog steeds als iemand uitvogelt hoe hij hem moet aanroepen. De fix: vertel de bouwer ook om “verwijderverzoeken van niet-Eigenaar-accounts op de backend te weigeren”. Als de bouwer niet weet wat “backend” in je app betekent, vraag hem om “de actie server-side te blokkeren, niet alleen de knop te verbergen”.

Eén rol voor twee taken. Mensen verwarren “de mensen die betalen” met “de mensen die de app gebruiken”. Een Klant die je betaalt voor werk en een Klant-werknemer die het dashboard gebruikt dat je voor die klant bouwde, zijn niet dezelfde rol. Als je ze mengt, besteed je de volgende maand aan het lappen van eenmalige regels. Twee rollen. Altijd.

Gebruikers gebruikers laten uitnodigen vanaf dag één. Het is verleidelijk om meteen “Nodig een teamgenoot uit” toe te voegen. Doe het niet. Voor je eerste 10 gebruikers, nodig ze zelf uit, met de hand, vanuit een beheerderspaneel dat alleen jij kunt zien. Selfservice-uitnodigingen zijn een hele categorie rechtenregels (wie kan wie uitnodigen? welke rol krijgen genodigden? kunnen zij anderen uitnodigen?). Wacht tot je het echt nodig hebt.

Vertrouwen op wat de AI-bouwer zegt zonder te checken. AI-bouwers vertellen je, zelfverzekerd, dat de rechten zijn opgezet. Misschien zijn ze dat. Misschien niet. Test altijd door in te loggen als een niet-eigenaar en slechte dingen te proberen: klik op verwijderknoppen, plak beheerders-URL’s, bewerk velden die je niet zou moeten kunnen bewerken. Als er iets werkt dat niet zou moeten, vraag de bouwer om het specifiek te repareren.

Een snelle checklist voordat je iemand uitnodigt

Voordat je die eerste uitnodiging naar een tweede gebruiker stuurt, loop dit door:

Ik kan de rollen in mijn app op één hand opnoemen.
Voor elke rol weet ik welke pagina’s ze zouden moeten zien en welke niet.
Ik heb ingelogd als een niet-eigenaar en bevestigd dat de verkeerde pagina’s verborgen zijn.
Ik heb geprobeerd een beheerders-URL in de browser te plakken als een niet-eigenaar en werd geblokkeerd.
Ik heb geprobeerd op verwijder- of bewerkknoppen te klikken die verboden terrein zouden moeten zijn en werd geblokkeerd.
Als er iets misgaat, heb ik een manier om de toegang van een gebruiker snel te verwijderen.

Als een van die punten niet slaagt, is dat het volgende gesprek met je AI-bouwer — voordat je de uitnodiging stuurt, niet erna.

De ene mentaliteitsverandering die helpt

Rechten bouwen voor een multi-user-app draait grotendeels om je voorstellen dat je een ietwat nieuwsgierige versie bent van je slechtst-gedragende gebruiker. Niet kwaadaardig — gewoon nieuwsgierig. Ze klikken op dingen. Ze plakken URL’s. Ze proberen te zien wat er op de “Instellingen”-pagina staat die ze opmerkten in je screenshot.

Jouw taak — en de taak van je AI-bouwer — is ervoor zorgen dat wanneer ze kijken, het antwoord consistent is: óf ze kunnen het zien omdat het hun data is, óf ze kunnen het niet zien omdat het dat niet is. Geen randen. Geen per ongeluk blootgestelde beheerderspagina’s. Geen “ik vergat dat die pagina bestond”.

De meeste bouwers denken niet aan rechten totdat er iets gênants gebeurt. Het goede nieuws: 20 minuten besteden aan nadenken over rollen voordat je lanceert, bespaart je de 20 uur om het later te repareren, plus de e-mail die je niet wilt schrijven aan de klant die het verkeerde ding zag.

Iets aan het bouwen met een multi-user-kant? De volgende keer dat je met je AI-appbouwer gaat zitten, begin de sessie door de rollen in je app hardop op te noemen. Het is de makkelijkste vijf-minuten-gewoonte om aan te leren, en het vangt de meeste van de ergste fouten voordat ze gebeuren.