One config for every task is the original sin

You would not give the new intern and the office manager the same set of keys. The intern needs the supply cupboard. The office manager needs the client files and the company card. Nobody thinks this is complicated.

Most AI systems give every job the same keys anyway. One setup, one toolkit, one set of permissions, handed to every task the system ever does. It is the easy thing to build. It is also how these systems become dangerous.

Three kinds of job

Deciding

Look at the situation, work out the right move, write it down. Chasing an invoice. Choosing what to do next on a case. Screening a candidate.

These run at near-zero creativity on purpose. The same overdue invoice with the same history should not get a gentle nudge on Tuesday and a final warning on Wednesday. That is not judgement, that is a coin flip.

Building

Writing a website, changing code, producing something and proving it works. Big toolkit, long leash, plenty of time.

And no ability to contact anyone. At all.

A job that writes code never gets the key that sends email. Not even if someone configures it to. This is the one setting a customer cannot override.

The reason is simple once you say it out loud. Something that can write code can write code that sends email. So every safety check you put on sending is a lock on a door with no wall next to it. If a service genuinely needs both, that is two jobs, and splitting them is the point — not the inconvenience.

Looking things up

Research, background checks, summarising. Reads things. Changes nothing.

Asking is not the same as getting

A service can ask for a bigger budget, a smarter model, more time, more tools. None of those requests are simply granted. Each one gets checked against what that customer's plan actually allows.

And when a request is too big, it gets trimmed — never refused. A service asking for more than its plan allows gets what the plan allows. It does not blow up at three in the morning because someone wrote an ambitious number in a settings file.

Why keys matter more than tools

Taking away a tool is a soft barrier. Something running in a sandbox with a command line can usually find another route. Removing a tool mostly costs it convenience.

Keys are a hard barrier. If the job never receives a key to a customer's mailbox, then no amount of cleverness gets it into that mailbox. There is nothing to be clever with.

So our safety does not rest on which tools a job has. It rests on which keys get handed out, for which job, for how long, and to which specific accounts.

In practice, a job never touches a real password or key at all. It gets a temporary pass, valid only for this job, only for the accounts this service was allowed to use, and cancelled the moment the job ends. The real credentials sit behind a door the job cannot open — and that door is where a human gets asked before anything irreversible happens.

The point

Someone writing a new service writes one word — which kind of job this is — and inherits a whole set of sensible decisions somebody thought carefully about once.

They are not assembling safety out of parts. That is the thing nobody does properly when they are in a hurry, and everybody is always in a hurry.