Problemet med vem som ser vad: att lägga till användarbehörigheter i din AI-byggda app

Ögonblicket då din AI-byggda app slutar vara bara för dig är ögonblicket då behörigheter blir ett verkligt problem. Fram till dess visar varje sida allt. Varje lista visar varje rad. Varje knapp fungerar för alla. Det är en enspelarapp som låtsas vara flerspelar.

Sedan lägger du till din första kollega, eller din första kund, eller din första betatestare — och de ser något de inte borde se. Kanske är det en kollegas lön. Kanske ett utkast som inte var klart. Kanske admininställningarna, av misstag exponerade.

Det här är problemet med vem som ser vad, och det är det enskilt största som icke-tekniska byggare gör fel när de lanserar ett projekt från en AI-appbyggare. Den goda nyheten: du behöver inte bli säkerhetsexpert för att lösa det. Du behöver bara ett tydligt sätt att prata med din AI-byggare om det.

Varför din AI-byggda app börjar tillåtande

När du beskriver en app för en AI-byggare — “jag vill ha ett CRM där jag kan lägga till kunder och anteckningar” — optimerar byggaren för en sak: att få det att fungera för personen som beskriver det. Standardappen är “alla som är inloggade kan se allt”. Det är helt okej för ett personligt verktyg. Det är en katastrof i samma stund en andra användare dyker upp.

Det här är inte en bugg i AI-appbyggaren. Det är det naturliga resultatet av att du inte talat om för den vem som får se vad. Byggaren har ingen aning om att din kundlista är känslig, eller att “Anteckningar” kan innehålla saker du inte vill att kunder ser. Du måste säga det.

De tre frågorna att ställa innan du lägger till en andra användare

Innan du bjuder in någon, fråga dig själv tre saker. Skriv ner svaren — du matar dem till din AI-byggare i nästa steg.

1. Vilka är rollerna?

Inte personerna — kategorierna. De flesta appar har någonstans mellan två och fyra. För en frilansportal: “Jag” och “Kund”. För ett internt verktyg: “Admin”, “Chef”, “Teammedlem”. För en community-app: “Moderator”, “Medlem”, “Gäst”. Motstå frestelsen att gå förbi fyra roller tidigt. Varje roll fördubblar reglerna du måste hålla reda på.

2. För varje roll, vad kan de se?

Gå igenom varje sida i din app, i huvudet. För var och en, fråga: ska en Kund överhuvudtaget se den här sidan? Ska de se all data på den, eller bara sin egen? Ska de se sidan men med vissa fält dolda?

Det enklaste mönstret: ägare ser allt; alla andra ser bara det de uttryckligen fått tillgång till. Det fungerar för 80 % av apparna utan särskilt mycket anpassning.

3. För varje roll, vad kan de göra?

Samma övning, fast för knappar och handlingar. Kan en Medlem radera ett projekt? Kan en Kund redigera sin profil men inte sin plan? Kan en Chef bjuda in nya personer? De flesta icke-tekniska byggare glömmer det här steget helt och hamnar med appar där vilken inloggad användare som helst kan radera hela databasen med ett enda knapptryck.

Att prata med din AI-byggare om behörigheter

När du väl har svaren skriver sig prompten till din AI-byggare själv. Den ser ut så här:

Uppdatera den här appen så att den stöder två roller: Ägare och Kund.

Ägare kan se alla kunder, alla projekt och alla fakturor. Ägare kan skapa, redigera och radera vad som helst.

Kunder kan bara se sina egna projekt och sina egna fakturor. De kan inte se kundlistan, teamsidan eller inställningssidan. De kan se sina projekt men inte redigera dem. De kan se och betala sina egna fakturor.

När en Kund är inloggad, dölj navigeringslänkarna till Inställningar och Team. Om en Kund försöker besöka de sidorna via URL, omdirigera dem till sin instrumentpanel.

Tre saker spelar roll i den prompten:

Var specifik per sida och handling. “Kunder kan se sina projekt” är vagt. “Kunder kan se men inte redigera sina egna projekt på sidan /projects” är något en AI-byggare faktiskt kan implementera.
Säg vad som händer med navigeringen. Att dölja länken är inte samma sak som att blockera sidan. Du vill ha båda.
Täck fallet där man skriver in URL:en. Annars kan en nyfiken användare klistra in /admin i webbläsarfältet och gå rakt in.

De fyra misstagen jag ser varje vecka

Efter att ha sett många byggare lansera sin första flerspelarapp dyker samma misstag upp:

Att dölja knappen är inte att dölja datan. Om du ber din AI-byggare att “dölja raderingsknappen för Kunder” försvinner knappen från skärmen. Men den underliggande raderingsoperationen fungerar fortfarande om någon listar ut hur den anropas. Lösningen: be också byggaren att “avvisa raderingsförfrågningar från icke-Ägar-konton i backend”. Om byggaren inte vet vad “backend” betyder i din app, be den att “blockera handlingen på serversidan, inte bara dölja knappen”.

En roll för två jobb. Folk blandar ihop “de som betalar” med “de som använder appen”. En Kund som betalar dig för arbete och en Kund-anställd som använder instrumentpanelen du byggde för den kunden är inte samma roll. Om du blandar ihop dem lägger du nästa månad på att lappa engångsregler. Två roller. Alltid.

Att låta användare bjuda in användare från dag ett. Det är frestande att lägga till “Bjud in en kollega” direkt. Låt bli. För dina första 10 användare, bjud in dem själv, för hand, från en adminpanel bara du kan se. Självbetjäningsinbjudningar är en hel kategori av behörighetsregler (vem kan bjuda in vem? vilken roll får de inbjudna? kan de bjuda in andra?). Vänta tills du faktiskt behöver det.

Att lita på vad AI-byggaren säger utan att kontrollera. AI-byggare säger dig, med självförtroende, att behörigheterna är uppsatta. Det kanske de är. Det kanske de inte är. Testa alltid genom att logga in som någon annan än ägaren och försöka göra dåliga saker: klicka på raderingsknappar, klistra in admin-URL:er, redigera fält du inte borde kunna redigera. Om något fungerar som inte borde göra det, be byggaren fixa det specifikt.

En snabb checklista innan du bjuder in någon

Innan du skickar den första inbjudan till en andra användare, gå igenom det här:

Jag kan räkna upp rollerna i min app på en hand.
För varje roll vet jag vilka sidor de ska se och vilka de inte ska se.
Jag har loggat in som någon annan än ägaren och bekräftat att fel sidor är dolda.
Jag har försökt klistra in en admin-URL i webbläsaren som icke-ägare och blivit blockerad.
Jag har försökt klicka på raderings- eller redigeringsknappar som borde vara förbjudna och blivit blockerad.
Om något går fel har jag ett sätt att snabbt ta bort en användares åtkomst.

Om någon av de punkterna inte går igenom är det nästa samtal med din AI-byggare — innan du skickar inbjudan, inte efteråt.

Den enda tankemässiga förändringen som hjälper

Att bygga behörigheter för en flerspelarapp handlar mest om att föreställa dig att du är en lätt nyfiken version av din värst beteende användare. Inte illvillig — bara nyfiken. De kommer att klicka på saker. De kommer att klistra in URL:er. De kommer att försöka se vad som finns på “Inställningar”-sidan de la märke till i din skärmdump.

Ditt jobb — och din AI-byggares jobb — är att se till att när de tittar är svaret konsekvent: antingen kan de se det för att det är deras data, eller så kan de inte se det för att det inte är det. Inga kantfall. Inga oavsiktligt exponerade adminsidor. Inget “jag glömde att den sidan fanns”.

De flesta byggare tänker inte på behörigheter förrän något pinsamt händer. Den goda nyheten: att lägga 20 minuter på att tänka på roller innan du lanserar sparar dig de 20 timmarna att fixa det senare, plus mejlet du inte vill skriva till kunden som såg fel sak.

Bygger du något med en flerspelar-sida? Nästa gång du sätter dig med din AI-appbyggare, börja sessionen med att högt räkna upp rollerna i din app. Det är den enklaste femminutersvanan att skaffa, och den fångar de flesta av de värsta misstagen innan de händer.