One rule in my community app said staff could read a group’s private notes. It sounded reasonable. Staff is the people running things: a handful.
Then I counted. In the church testing the app, “staff” meant 17 of 31 people.
That’s a majority. The rule wasn’t wrong as written. It was wrong about who it meant. And the AI that built it had no way to know, because “staff” is just a word to an agent, and agents take words literally.
Three times the word wasn’t the audience
Permissions are where AI-built apps hurt people, and they rarely fail loudly. Here’s how they went wrong for me, all in the same few weeks:
The late-night page. A rule said that if a group had no leader, “admins and leadership” would answer its questions. When a question came in late one night, 16 people’s phones lit up, twice. I was one of them, and my first thought was, “Why am I getting this?”
The inbox that wasn’t private. Members could send feedback, and “admins” could manage it. Admins turned out to mean 17 people, all of whom could read, reply to and delete every ticket. I found out when a leader texted me a screenshot of my own product backlog sitting in their inbox.
The lock that was really a hidden button. The app kept people out of private chats by only showing a Join button on open ones. But a hidden button isn’t a lock. The server would have let any signed-in member add themselves to any private chat, in a few steps, by talking to it directly. It was fixed the day I found it.
Each of these was discoverable in a single question asked before launch: how many people is that, by name?
Why AI gets permissions wrong
It isn’t careless. It’s literal. When you say “only admins,” it builds exactly that, without asking how many admins there are or whether the person you’re thinking of is one. When the app hides a button, the agent may treat the button as the rule, because in your description it was.
And permission bugs don’t look like bugs. The screen works. Nobody sees an error. The only symptom is that the wrong person can see something, and the wrong person rarely reports it.
Five habits that catch it early
1. Count, by name
Before any feature that shows or sends something to people, don’t ask “who is this for?” Ask “how many people is that, and who?” If the number surprises you, the rule is wrong.
For this feature, list exactly which users can see it, change it or delete it, as a count by role, with an example name from my test data for each. Flag anything that reaches more people than its name suggests.
2. Rules live on the server, not in the screen
Hiding a button, a page or a menu is design, not security. Every “who’s allowed” rule has to be checked on the server, where nobody can skip it.
For every private piece of data and every admin action, show me where the server enforces who’s allowed. List anything that’s only protected by hiding it in the interface.
3. Check it as the person, not as yourself
You’re usually the admin, so the app looks right to you. Sign in as the least-trusted user you have, like a guest or a brand-new member, and try to see what you shouldn’t. When I did this for one worry, the guest could see that a chat existed but couldn’t read a single message, which settled it. Don’t say “no leak” until you’ve checked as them.
4. Notifications are permissions too
A push notification shows part of a message to whoever receives it. If the notification rule and the viewing rule disagree, the notification leaks. I found one where mentioning someone in a private chat sent them a preview of the message, even if they weren’t in the chat.
For every notification this app sends, who receives it, and could any of them receive a preview of something they’re not allowed to open?
5. When rules disagree, choose the quiet failure
Sometimes your data will be slightly wrong: someone in a chat they shouldn’t be in, a leftover membership. Decide in advance which way the app fails. I chose silence. If the system isn’t sure someone should see something, it doesn’t notify them. A missed notification is annoying. A leaked one can’t be taken back.
The design lesson
Who can see what is the most human question in any product, and it’s design work, not just engineering. It’s about the people in the room, what they’d expect, and what would embarrass them. AI can build any rule you describe. It can’t tell you that your description includes 17 people when you meant 5.
The habit I’d give any design team is the boring one: count the audience. It has caught more real problems in my work than any automated test.
Want to check your own app? Permissions and database rules are items 3 and 4 of the Vibe Coding Checklist. The free Fix Kit has a prompt to list who can see what, and a way to confirm it yourself as a different user.
Stuck on a fix? I do a few 1:1 sessions where you share your screen and I teach you how to check and fix it yourself.