Who Gets a Key

Every safeguard so far treats what is written — refuse this card, seal that change, photograph the drawers. This lesson turns to who. Walk into any real library and notice: visitors browse the reading room, staff go behind the desk, and the archive room key lives on exactly two keyrings. Nobody finds this insulting. It's how buildings full of valuable things stay valuable.

Permissions

Databases run the same building. Every person — and every app, because programs are visitors too — connects as some account, and each account holds permissions: an exact list of what it may do, checked by the database on every single request. The verbs should look familiar, because you've spent two units learning them: may this account SELECT from this table? INSERT into it? UPDATE it? DELETE from it? Change the schema itself?

Out of those verbs, two bundles cover most of life:

• Read-only — SELECT and nothing else. Can ask anything, change nothing. The reading room.
• Read-write — SELECT plus the pens: INSERT, UPDATE, DELETE, on the tables the job actually touches. Behind the desk.

And permissions are per-table, so the bundles can be shaped precisely: the accountant reads payments but never medical_notes; the app that sends newsletters reads member emails and can't touch loans. Ask for something outside your list and the librarian gives the same calm refusal you met at the door in lesson 2 — request denied, nothing happened, carry on.

Least privilege

Now the principle that decides who gets which keys, and it's the most misunderstood idea in security: least privilege — every account gets the smallest set of permissions its actual job requires, and nothing more. The summer intern shelving returns does not hold the archive key. Not because anyone suspects the intern — because a key that doesn't exist on their ring is a key that can't be lost with their bag, copied at a fake locksmith, or turned in the wrong lock during a distracted Tuesday.

That's the reframe worth keeping: least privilege isn't distrust of people. It's shrinking the blast radius of any bad day — and bad days come in flavors nobody chooses. A stolen password. A bug in an app. A typo with a pen. In every flavor, the damage is capped at exactly what that one account was allowed to do. A read-only key, stolen, is an information leak — bad. A do-anything key, stolen, is lesson 1's UPDATE-without-WHERE with a stranger's hand on the pen.

Here's the version of this you'll meet constantly as a builder: the classic beginner setup connects the app to the database as the all-powerful owner account, because it makes every error go away. It also hands the archive key to whichever bug ships on Friday. The professional habit is one sentence: apps get their own account, with the least it needs. The newsletter app can't drop tables. It never needed to.

The vault is now complete on paper: rules, transactions, backups, keys. Next lesson we test it against reality — the two famous ways data goes wrong anyway, and why the layers are built expecting it.