Principle of Least Privilege

In a team of ten, dividing up access looks like pure cost. Deciding who can do what takes time, and once it is decided somebody gets blocked and has to ask for it to be opened again. So most early teams give everyone an administrator account and let nobody be blocked.

That choice causes no trouble at all until the day one account is compromised. A marketer types a password into a fake login page that arrived by email, and whoever is on the other end now has the customer documents, the billing records, and the server settings. What determined the size of the incident was not how important that account was — it was how much access had been attached to it.

Mistakes scale the same way. If eight people can connect to the production database directly, the odds of one bad command are eight times higher, and the command that deletes the wrong table does not care whether the person typing it meant well.

Least privilege is the rule that comes out of this. It accepts that breaches and mistakes can't be driven to zero and shrinks in advance how much either one can reach.

It works by making the default no, then opening specific things one at a time. Rather than listing what to block, you start from a state where nothing is allowed and add only what the work needs.

Four questions settle a single grant.

1. Who — not only people. Deployment scripts, the payment integration server, the analytics collector: programs that run with nobody watching have accounts and permissions of their own.
2. To what — all customer documents, only this team's documents, or only documents this person created.
3. Which action — read, write and delete get decided separately. An analytics tool needs reads; there is no reason for delete to come with it.
4. Until when — database access opened to work an incident gets closed that evening. A grant with no expiry never gets revoked, because nobody is responsible for noticing it.

Settling those four per person becomes unmanageable in a company of forty-five. In practice, permissions are bundled into roles like administrator, editor and viewer, and people are given a role — role-based access control (RBAC). Change the role and everyone holding it changes with it.

Access gets checked at two different moments. Authentication confirms who is connecting; authorization decides whether that confirmed person may do the thing they just asked for. Least privilege lives in the second one. A service where being logged in opens every screen has authentication and no authorization.

None of it holds still, either. People change teams and projects end, so the need disappears while the access remains. That is why access review — periodically pulling up who can reach what — is the companion practice. Export the list once a quarter, ask whether each grant is still needed, and close the ones nobody claims.

Most of the day-to-day work is on people's access. A new hire gets one role that matches the job; someone changing teams gets the old role removed as well as the new one added. Skip the removal and you grow people who only accumulate. The principle comes up most often around offboarding, the process of handing over work and revoking access when someone leaves, because an account still open on the last day becomes the entrance to an incident months later.

Programs accumulate more quietly. Keys issued to connect an outside service usually get created with every permission turned on: wide open to make it work, never narrowed once it does. Unlike people, they never resign, and no quarterly list flags them, so they stay that way for years. A key that could only read what it was built to read would have made a leak an inconvenience instead of an incident.

It also sets the bar wherever customer data is handled. Someone answering support tickets either needs to open the body of a customer's document or needs only account status and billing history, and that gets decided rather than assumed. Enterprise buyers ask about this specific line before they sign, which is often what pushes a team to write the answer down for the first time.

The same thing shows up in security findings. In a penetration test report, where outside specialists probe the service the way a real attacker would, the hole itself usually gets less space than how far someone could travel once through it.

"Does this script really need write access? Read looks like enough."

Trim the permissions on an integration down to what it actually uses.

"Open it for one day for the incident. I'll revoke it tomorrow morning."

Grant the access, but fix an expiry on it up front.

"The way this is set up, one compromised account gets everything. We aren't doing least privilege."

A single incident wouldn't stay contained to the account it started in.

At Pagedeck the subject came up while filling out a security questionnaire from an enterprise customer. The form Sofia brought back had a section on per-employee access scope, and when Theo opened the actual settings, every engineer could connect to the production database directly.

Theo spent two weeks splitting that into three roles. Normally nobody touches production data; during an incident you write down the reason and get eight hours of access, after which it closes on its own. Grace worried the team would slow down, but the requests came in three times a month. Access that eight people had held permanently turned out to be access needed three times a month.

The most common objection is that tightening access slows the work down. Being blocked is visible and waiting for an approval is felt, so it seems obvious. Measured, though, the slowdown is usually small — as at Pagedeck, permanently open access tends to be used far less often than people assume. Leave it open and have an incident, and the cost is not one afternoon but weeks of investigation, customer notification, and cleanup.

The other mistake is treating this as a rule about people. Org charts and account lists come to mind first. But the incidents tend to start on the program side: a key sitting forgotten in a code repository, a test account created once and never deleted. People disappear from the list when they leave. These grants have no owner to ask for their removal, so they stay alive.