I loathe working places where they just give you all the permissions because it's "easier". One risk is if something does happen, and they don't have exceptional tracing and logging, (and let's be honest, at an organization sloppy enough to hand out privileges like candy, what's the chance of that?) it's difficult or impossible to pin down the source to any individual. As a result, both responsibility and suspicion is diffuse.

The appropriate restrictions are relative to the size and momentum of the organization. It's easy to spend months setting up safeguards rather than working on product development that won't proportionally return.

Of course, this involves being honest with yourself about risk and reward, and we all have implicit incentives to disregard the risk until we get burned and learn to factor that in.

I have so many horror stories from there.

When they did decide to lock down the database, the DB admin only locked in down in the sql server client most people used. If you used some other client, you still had access. _sigh_

It's not just about the risk. It signifies that you're not dealing with an experienced database administration staff. (At a startup that might just mean one guy, but that's better than zero.

A second thought. It leads to lazy application development. Whenever you have production intervention that happens more than a few times, you should just make a feature that does it safely via application code.

I agree. Good access controls and being prevented from accessing things that I don't need access to protect me as an employee just as much as the data itself.

Meta completely restricted graph data access to requiring a specific business purpose and managerial approval tied an articulable, concrete task need.