What permissions should my app actually have?

Permissions decide what each part of your app, and each person using it, is allowed to do. AI builders tend to grant broad permissions by default, because that makes things work without fuss. But broad permissions turn a small slip into a large disaster: one leaked key that can do everything is far worse than one that can do a little. This article is about giving out only what is needed.

What least privilege means and why it matters

Least privilege is a simple, powerful idea: every part of your system should have exactly the access it needs to do its job, and no more. A key that only needs to read should not be able to delete. A support login that only needs to see orders should not be able to change billing. A user account should reach its own data and nothing else. The reason this matters is that things get compromised, and when they do, the damage is bounded by what the compromised thing could do. A narrowly scoped key that leaks is a contained problem; an all-powerful key that leaks is a catastrophe. You cannot prevent every slip, but you can decide in advance how much a slip is allowed to cost.

Where over-broad permissions hide in AI-built apps

AI builders reach for broad permissions because they remove friction: an all-access key just works, so that is what gets generated. The result is predictable. A single database key that can read, write and delete everything, used for tasks that only ever need to read. API keys created with full account access when a narrow scope would do. Admin as the default role, so ordinary users quietly have more power than they should, or the reverse, where there is only one all-powerful account and no separation at all. Public or open access left switched on from the demo. Each of these is a case where the app works fine, so nothing prompts a second look, while the blast radius of any compromise stays needlessly enormous.

How to scope access down sensibly

Tightening permissions is a matter of going through each point of access and asking what it truly needs. For keys, most services let you create scoped keys limited to specific actions or resources: make a read-only key for read-only tasks, a payments key that only does payments, and so on, rather than reusing one master key everywhere. For users, define roles that match real needs, an admin who can manage, a staff role that can do less, a customer who reaches only their own data, and assign the least powerful role that lets each person do their job. For your database, the access rules from securing it are least privilege in action. The habit is to grant narrowly and widen only when a real need appears, which is the opposite of the default-broad approach but far safer.

The payoff when something goes wrong

The value of all this scoping shows up on the bad day. When a key leaks, and over enough time one will, least privilege is what decides whether you rotate a limited key and move on, or face someone with the power to read every record, drain every service and delete your data. When an account is phished, tight roles mean the attacker inherits only that account's narrow access, not the keys to everything. Least privilege does not stop breaches; it shrinks them, turning what could be an existential event into a manageable incident. It is quiet, unglamorous work that pays off precisely when things fail, which is the definition of a good security investment. If your app grew quickly and everything shares broad access, walking it back toward least privilege is one of the higher-value security jobs you can do.