What a permission model actually needs

Ella is a permission-based agent that carries out real tasks on a person's machine. The pitch is a single sentence — it asks before it acts — and that sentence hides most of the engineering. Here is what it took to make it true.

Scopes have to be nameable

A permission is only meaningful if the person granting it can understand what they are granting. 'Access your files' is not a scope; it is a blank cheque. Ella requests scopes per task, in plain language — files:read on this folder, sheets:write on this document — and shows them before anything runs.

That forces a design constraint upstream: the agent's plan has to be decomposed into steps whose side effects are known in advance. You cannot request a scope you cannot predict needing. An agent that plans open-endedly cannot have a permission model at all.

The default has to be interruption

Any step that changes state pauses for confirmation unless that class of action has been pre-approved for that scope. The tempting design is the other way round — proceed unless told to stop — and it is the fastest way to lose a person's trust. People do not object to being asked. They object to discovering something happened.

Every action needs a ledger

Permission without a record is theatre. Ella writes every read, write and tool call to a sealed, ordered ledger with the inputs it saw. That is what lets a user open a run weeks later and see exactly what happened. It is also what makes the next property possible.

Reversibility is a property of the ledger, not the action

Ella's actions are reversible for thirty days. That does not mean every action is inherently undoable — it means each one is journaled with enough state to reverse it. Reversibility falls out of the ledger design; it cannot be bolted on afterwards. This is the property we see most often missing in agents that claim to be 'safe'.

All four are the standard we hold every client agent to. They started as Labs questions.